J1939 address table/register

[pvkarthikk]

Thinking of having the j1939 address dict/tabel/register in the ECU class where it reads all the address claim messages and keeps with name {int: Name}

[grant-allan-ctct]

That's an interesting question - thank you for posting.

My initial reactions is to wonder if we might not need to go down this road if #44 (subscriber not being notified of incoming address claims) could be resolved. If that issue were fixed, then a user could put in place a subscriber that creates a J1939 table suitable for their own needs.

If we were to go ahead and try to add this handling to the ElectronicControlUnit base class, it might make that class quite complicated.

It also might be difficult to come up with an approach that is configurable to the extent that it produces exactly the behavior that suits the needs of multiple potential users.

I think that there are likely to be a few corner-cases to consider if making a table of devices - e.g.

• cater to a device that changes address after another one comes onto the bus and "steals" its original address
• a device might be disconnected from the bus, and then the table becomes out of date
• threading issues around updates to the table, versus reading of its contents
• what to do if someone puts multiple devices on the bus that have same J1939 name (which violates the J1939 spec but there are still such devices out there in the real world)

Some of these corner cases might be interesting to some users, but not interesting to others. If we give users the means to create a subscriber that creates a J1939 address table, then we give them the power to focus on just the items they care about.

Thoughts...?

[pvkarthikk]

I missed to post my problem. Actually, I need to know the list of ECU connected in the network. So, I thought of having table to look into it.

I agree with you. If we go with table, it may complicate. I think, we can fix the subscriber(#44) issue.

Regards corner case, Interesting to know multiple device with same Name. But, if those devices are get connected in the network. Will it not create race condition?

One more thought, is it fine to request 0xEE00 (Address Claim) via 0xEA00 (Request) while ControllerApplication.start() ? So, whenever ControllerApplication starts, it will request Address Claim PGN to all the ECU in the network. By requesting, all the ecu will send their address. So, subscriber can be notified to maintain their address table.

    def start(self):
        # TODO: how to determine if the CA is already started?
        # raise RuntimeError("Can't start CA. Seems to be already running.")
        self._ecu.add_timer(0.500, self._process_claim_async)
        # Send Request to all ECU for Address Claim
        self._ecu.send_pgn(
            data_page=0,
            pdu_format=0xEA, 
            pdu_specific= ParameterGroupNumber.Address.GLOBAL,
            priority=6,
            src_address= ParameterGroupNumber.Address.NULL,
            data=[00,0xEE,0x00]
        )

[grant-allan-ctct]

This is just my own opinion, but I feel that it would be better to avoid putting more actions into the start function. The start function seems to be trying to simulate the first address claim that a CA will make when the ECU is powered up.

Your idea of broadcasting a global request for address claims feels like a different thing to me, and may not be universally appropriate during start-up of a CA.

However, you are still free to write some client code that calls public method ElectronicControlUnit.send_pgn in order to transmit that same "request for address claims" message.

One thing that I have realized recently (maybe it might be useful to you, depending on your circumstances) is that it is possible to use a CA without going through the process of address arbitration (the state-machine that is invoked when calling start on the CA). To skip arbitration and just take the address of your choosing, pass extra arguments to the ControllerApplication constructor: device_address_preferred and bypass_address_claim. I.e. if your goal is to just get the names and addresses of devices on the bus, you might be able to use this technique and then simply call ElectronicControlUnit.send_pgn instead of calling ControllerApplication.start once #44 is fixed.

Even more simple (again, depending on your circumstances), you might be able to avoid using a CA altogether, by calling ElectronicControlUnit.subscribe function directly, and then calling ElectronicControlUnit.send_pgn (and again, once #44 is fixed).

Regarding the corner case of multiple devices with the same name, I think that people who make such devices hope that there will only ever be one such device on a given CAN bus. I'm not sure what will happen if two were put onto the same bus - hopefully at least one of them will go silent 😎 .