J1939 ECU Simulation Fails when also Reading Signals from Real ECU

[NathanJD]

Is there some sort of limitation when simulating ECUs with XNET?  I am currently trying to simulate several different ECUs while reading the signals from a real ECU.  I currently have the simulated ECUs setup with 1 session (Signal Output Single-Point) per ECU with all of it's transmitted signals.  To read signals, I create a Signal Input Single-Point session for all the signals that are transmitted by the real ECU as defined in the same database.

They all address claim the first time when I set the ECU object and wait for J1939.Address to be equal to J1939.PreferredAddress (effectively the Address Claim example VI).  But after that, not all of them will respond to an address claim request.  Strangely, the only one that responds to the request is the last simulated ECU alphabetically.

If I skip creating the input session, all simulated ECUs respond properly to the address claim request.

LabVIEW 2014 w/ XNET 16.0

[JefeL]

How many interfaces are you using? Does each Simulated ECU use it's own interface or are all of them on the same interface i.e. CAN1?

Can you provide some example code or a snippet to get a better picture of how your application works? 

[NathanJD]

It's on a single interface, CAN1 on a cRIO using NI 9862.  Here is how I generate the sessions but will be attempting to switch to a frame grouped signals setup soon so that I can disable specific frames.

Strange that the VI Snippet functionality got worse in LabVIEW 2014...

[NathanJD]

If it is relevant, note that I'm in the process of following your advice in this thread for this project.

[JefeL]

I believe I have figured out why the node addresses are not returning properly in the screenshot posted above.

The key lies in the way the node address property works. 

If a J1939 ECU is assigned to multiple sessions, changing the address in one session also changes the address in all other sessions with the same assigned ECU.

Since the output session was using signals from multiple ECUs, it ties them all together. 

While researching, I did notice some other anomalous behavior with node addresses. The first issue involves clicking a ECU in the DB editor. Setting a ECU name in one ECU will change the name of all other ECUs. If you save the file it will overwrite the names. Important for the second issue which is that address claiming is not working properly unless each ECU in the cluster has a unique name. I have filed bug reports for both.

[NathanJD]

---

@JefeL wrote:

I believe I have figured out why the node addresses are not returning properly in the screenshot posted above.

The key lies in the way the node address property works. 

If a J1939 ECU is assigned to multiple sessions, changing the address in one session also changes the address in all other sessions with the same assigned ECU.

Since the output session was using signals from multiple ECUs, it ties them all together. 

---

Wow, the info in that properly is much higher level than I would expect for a property. I would expect that type of high-level info to be in the help document as an article under the “J1939 Sessions” section for “working with J1939 nodes” or something like that (which is where I was looking for this type of info).

However, I believe that this response is for the issue I had in the other thread.

[NathanJD]

I'm not really sure how this addresses the issue:  creating a session to read signals causes my simulated (transmitting) ECUs to stop responding to address claim requests.

I've bypassed the issue with the database editor regarding the node names being corrupted by editing the XML file directly prior to running my application.  After doing this, all of the ECUs appear to arbitrate properly (i.e. they address claim when their node address is set via property node and it uses the correct node name).  However, on subsequent address claim requests, only the last one of the transmitting nodes responds to the request (and it happens to be the one that is last alphabetically).

If I never create the session for reading signals, all nodes respond every time.  The node address for the session for reading signals is never assigned a value and defaults to 254.  The read session works just fine, I'm able to get data from the bus.

[JefeL]

I'm running the test VI that you have provided and it is proving to be extremely helpful. There is definitely some incorrect behavior that I am trying to isolate and scope.

I setup the test VI so that "ECUs to Read" is an empty array while "ECUs to Simulate" contains ECUs 1, 2, and 3. I run the test VI and see the three expected address claims performed successfully. I then run a ClaimAddress.vi on a 3rd port that simulates an external ECU claiming an address. I set the node name property to 0xFFFFFFFFFFFFFFFF to ensure that ECU 1, 2, and 3 should win the claiming procedure and generate a contention message. When I cycle my ClaimAddress.vi from address 5 down to 1, the address claim succeeds every time where I would expect to see a contending address claim message on all three ECUs but I do not see any contention messages.

In a similar setup, I run the test VI with ECU4 in the "ECUs to Read" array. I obtain similar results with no contention messages being sent. I also performed some other testing with my VI that I used before and saw similar results. Can you confirm that you are able to see a contention message in any of your setups?

[JefeL]

We took a closer look at the example code and it appears to happen because the ECU4 input session does not get assigned an ECU. It remains unclear why that would cause the input sessions to fail to negotiate so we will continue to investigate and file a bug report when needed.

In our tests, we were able to get the ECU 1, 2, and 3 to respond correctly to node address contentions by adding ECU4 to the input session. I'm not sure if you were comfortable with me posting screen captures of the code we modified since it came through the AE channel. If so, let me know and I will post our modifications and continue to work with you via the forums. In case the code is sensitive, I will also have the AE send you the modified code via the SR. Let me know which channel you prefer to work through for future correspondence.

[NathanJD]

I'm glad to hear that there might be some sort of workaround.  Please use the service request to send me the code or screenshots.