Multi-frame LIN Diagnostic Responses not Receiving all Frames

[blackburnite]

A client has an issue with multi frame LIN diagnostic responses where only the first few response frames are received when running at a baud rate of 10.4k but apparently does not have this issue when connected to a different UUT which uses a higher baud rate.

They have provided a CANalyzer log showing the correct response so apparently the UUT is responding correctly but capturing the same data with the XNET bus monitor shows the missing frames so it seems to be something specific to the XNET sw/hw, assuming the data I've been provided and what I've been told about this so far is accurate.

I haven't gotten access to their system yet so I'm still early in debug and don't have much more information yet but I'm wondering if anyone has any idea off the top of their head as to what could be going on?

[JefeL]

Do you know the specific hardware being used? Are we sure that it is XNET hardware and not NI-CAN?

I would be interested in seeing the logs if they are available and trying to reproduce the issue on our end. 

[blackburnite]

The hardware is a PXI-8516.

The response frame in question is RSID 0x62 containing 14 bytes of data over 3 frames.

In the CANalyzer log screenshot I've been sent, this appears to be working.  In the trace from the XNET monitor, you'll see the first frame is received but not always the two consecutive frames, sometimes the second but never all three.

However, the CANalyzer trace I know they obtained by manually sending/receiving the diagnostics messages outside of an actual running test process and I know the XNET bus monitor only does manual transmits over CAN so the conditions could be different.

[JefeL]

I did some checking and we have tests in our testing framework that explicitly exercise multi-frame responses from slaves and we are not aware of any issues. Can you provide me with additional details about the schedule being run? The slave responses will be interleaved between normal cycles of the schedule. With a slower baud rate and a full schedule it could mean we aren't allowing enough time for the full 3x response frames to be returned before writing another master request.

Can you post code examples that you are working with?

[blackburnite]

I agree that this is not an XNET issue, I tested it out on a USB-8506 and can receive all diagnostics frames at 10.4k with no issue when the LDF file is properly set up.

I think the issue is the client's LDF file which includes both the request and response frames in the diagnostic master request schedule.  

The code provided by the client attempts to call the XNET Write (State LIN Diagnostic Schedule Change) VI to set the schedule to Master Request resulting in an error because XNET does not believe a diagnostic schedule exists in this database.  

[JefeL]

For the diagnostic schedule change master request to work, they have to have a master request schedule with only one slot that contains the master request frame.

For diagnostic schedule change slave response to work, they have to have a slave response schedule with only one slot that contains a slave response frame.

We can also have master request and slave response frames mixed and mingled in a normal schedule, but that is a normal schedule and has to use the normal schedule change write.

[blackburnite]

That's what I told them, I'm having them test with the fixed LDF file but I suspect this was their issue.

[blackburnite]

Update to this:  I was onsite at the customer and found out that the code an information provided to me was initially not completely correct.  A different LDF file was being used and a different version of XNET (they had 15, I had 17.5)

This LDF file did not have the improper schedules.  Using that LDF file and their LabVIEW code, I was able to communicate with the UUT without issue from my PC using a USB-8506.  However, the same could not be done when moving to a PXI running PharLap and using the PXI-8516 interface.

The only differences between these two cases were:

• Windows vs Pharlap
• USB-8506 vs PXI-8516
• XNET 17.5 vs 15

They also only saw the issue in the specific case where they were running at 10.4k baud and now additionally when expecting multi-frame messages of 3 or more frames.  They were able to receive multi-frame responses containing 2 frames.

[JefeL]

Are you able to share any sample code and/or test database that reproduces the issue? If so I would like to try reproducing it on our end.

[JefeL]

Some additional research has given us a hypothesis to test/rule out.

At 20K an 8-Byte frame like a Master Request (MR) or Slave Response (SR) nominally takes 6.2 milliseconds to transmit. Per the LIN spec, the slot delay should allow for a max frame transfer time of nominal + 40% which would be 6.8 ms. The slot delay for our diagnostic schedules in the XNET examples are set to 10 ms which is longer than 6.8 which is OK.

At 10.4K a MR or SR frame has a nominal transfer time of 11.923 so the slot delay should be at least 16.693 ms. We can try setting the slot delay to 20 ms as an experiment to rule it out. 

Can you tell me if you are setting the slot delay via the LDF file or overriding it through a property node?