J1939 ECU Simulation Fails when also Reading Signals from Real ECU

[NathanJD]

Ok, I got your suggested changes (assigning an ECU to the read session).

I tested your changes with ECUs 1, 2, and 3 to be simulated and to read from ECU4.  Now, ECUs 2, 3, and 4, respond to the address claim request.  So, I'm still not getting a response from ECU1.

Even worse though is that ECU4 is responding.  I can't have this happen in my system because ECU4 is the real ECU on the bus.  In fact there will be several real ECUs on the bus and I simply want to read all messages from all of them.

---

So, the original intent was to have an impartial observer reading all the CAN messages so that I could get any signal sent by any real controller.  According to the "Node Addresses in NI-XNET" NI-XNET help document, "A receiving XNET session without address can read all frames from the bus."  Is this the way that it is supposed to work?

Now, it almost seems like I need to do reading as if I were one of the already simulated ECUs (connect my Signal input session to a simulated ECU).  However, this will only work reliably if all messages on the bus are either global PGNs or are sent to the global destination.

---

Also, to clarify, there is no actual arbitration having to occur because all ECUs in my system have unique names and addresses.  When I had previously asked about "when arbitration occurs" I simply meant "when does the address claim procedure (send address claim, wait for someone to complain or not, then start transmitting) occur".

[JefeL]

I would expect that a session without an address would match the documentation and read all the frames on the bus. My understanding is that this is currently working correctly and the incorrect behavior pertains to sessions not sending out their expected address claim messages or arbitrating.

The address claim procedure occurs when the J1939 Address property or J1939 ECU property is written to so long as the write occurs after the interface has been started. In our case, we want ECU 1,2, and 3 to properly claim and retain their respective addresses while leaving the input session with a null address to read. While working around the bug(s) isn't pretty, I think I have found a way to achieve this. I override the preferred address of ECU4 in with a property node to 254 and serialized the Start Simulation VI to set the ECU for the input sessions after the interface is started and before the output sessions have their ECUs set. Probing the addresses just before Start Simulation exits shows all nodes having the proper address with the input session having 254. My testing also showed that the output nodes responded appropriately to node contentions even though these shouldn't occur in your setup.

We went over the issue with the developers in great detail this morning. They also performed some experiments in trying to isolate the bug. They found that setting the ECU seemed to work properly when it is done prior to starting the session. They modified the Initialization VI to set all ECUs right after session creation but noted that it still breaks if the ECUs are set again in Start Simulation.vi. I will try to send you the modified files through the SR.