J1939 ECU Race Condition

[NathanJD]

I think I've found a race condition when dealing with signal sessions with J1939 ECUs.

When I disable AutoStart and want to control starting of the session and the interface independently, there is a situation where we might be sending frames with a source address that some other ECU might have already claimed.

I've attached my test VI that shows this behavior with comments (along with the database I used; you'll need to change the extension back to xml).

The fact that this can happen makes me confused as to why the ECU concept was implemented the way it was (i.e. setting the identity of the ECU, a property, causes the address arbitration process to occur instead of being able to trigger that operation after sessions have been assigned to the ECU object).

Please let me know if I've misunderstood something.

Note:  I'm not entirely sure if this relates to a bug that was found in one of my other recent topics.

[SaileshK]

Hi Nathan,

I believe this is a bug we have seen in the past and something that we are working on. I do think the best location to post your question and any other J1939 questions would be on this thread (linked below) which is dedicated to it!

https://forums.ni.com/t5/Real-Time-and-Control/J1939-Transport-Protocol/td-p/961531

[JefeL]

I will be taking a closer look at this today.

[JefeL]

I have been running through several iterations of your test code and I want to make sure what I am seeing matches your results.

I setup a bus monitor and an claim address example to act as a dummy ECU already on the bus with a claimed address of 0x04. Testing both a high and low name value, I was unable to reproduce a data frame being transmitted prior to an address claim.

I was able to produce a conflict that resulted in behavior I consider incorrect and I am trying to scope it properly. In the test case with two calls to Claim by ECU a conflict resulted in the session receiving a null address and then transmitting data frames with a source address that didn't match. I get different results depending on which version of your code is enabled, which version of claim is used, and name value of the existing ECU. I need to work through the different permutations to figure out what is and isn't working as expected which I hope to do tomorrow. In the mean time, the following screen cap appears to work correctly:

This version will not send out any data frames at all after a conflict. Assuming an existing ECU is on the bus the address claim will fail as expected and isn't checked afterward. The test code session will then receive a null address and when the write is attempted it will also fail with a warning. No data frames will be transmitted unless the address claim was successful.