Issues with write and read LIN XNET sequence

[TeraEngineer]

Hello,

Device: TRC-8546 with NI-9860 plugged on cDAQ-9189 

Software: use of NI-XNET and database.

Context: I am working on project on which I have 44 slave devices which have same LIN address (they come like that and I cannot change it before or during the run). To communicate with them, I use a driven multiplexer to talk with them one after the other.

For this, I put the drive of the multiplexer and the writing+reading of LIN Frame in a loop.

It works pretty well but I have 2 issues:

1. sometimes, for a reason, after a write, it waits a lot more time (here 100ms as shown on oscilloscope screenshot) than it should before sending the header frame to get the slave response. As a consequence, the slave does not reply and I do not receive any response.
   Note: in database, MasterReq and SlaveReq schedule are configured as unconditionnal with a 20ms period each. So it should send the header 20 ms after the masterReq sent.
   Do you have any explanation and way to fix this ?
   
   
   

   Screenshot 1: yellow trace is LIN bus on slave 1 / pink trace is LIN bus on slave 2 (and green trace is just mulxiplexer input to know when it changes from slave 1 to slave 2)
   
   

   

   screenshot 2: zoom on second frame: everything is fine on both slaves, we can see 20ms delay between the master frame and the header+slave reponse. (we also see then a second header.. surely due to the time taken in my vi to change from slave to master diagnostic scheduler, which was higher than 20 ms.)
   
   

   

   screenshot 3: zoom on the third frame: I didn't receive anything on slave 1... and it seems it's because the vi (or XNET or the hardware ?) waited too long (here 100ms) before sending the first header.. which was too long for the slave which didn't reply to it ..

2. the execution time of the loop is too slow. As a consequence, If I want to use all the 44 slaves, after the wake up (made by the send of the first frame), the slaves go back directly in sleep mode before I talk to them again, then I can not use all my slaves (I do not receive any reply since they are not awaken each time I send a frame)
   
   

To sum up what does my VI.

The bigger loop allows to send differents frames (I am trying 4 at the moment).

Each frames are sent to all slaves (it should be 44 but as it doesn't work, I am working with only 30 at the moment) and I try to get the slaves responses. Before then write and read, I drive the multiplexer thanks to DAQ use into the sub-vi, to make the link with the sensor to talk with.

I use the Signal XY to get the timestamp to check if data read has been updated. 

Note 1: I have used one loop for the write and read to allow me some retries I don't receive the data. I think I don't need it anymore, that's why the stop condition is at first iteration (0).

Note 2: I have also used one loop for the read to allow me some retries if for some reason, I didn't receive the response. It is fixed to 1 (retry, meaning 2 iterations) here

Note 3: for the purpose, I am talking with all the slaves using diagnostic mode (ID = 60).

Note 4: To track the delays taken by blocks, I have put time indicators a bit everywhere..
There is for example a timeline for each slave response ("TimeLine") and time measured between each read loop outpout ("TimeLoop"), either we got a response or not

[TeraEngineer]

To add some extra information/precision:

• the driven multiplexer is a kind of a switch with allows routing the master to one slave at a time
• Below is the screenshot linked to the previous oscilloscope screenshot 2, it is the "Gestion_COM_LIN.vi" front pannel when I stop after the first 2 replies from the first 2 slaves, so when it works

=> we can see by checking the 2 first "TimeLoop" that it's kind of coherent: it is the sum of the time taken between the 2 diag change and the reading. Theorically, it should be less but it is kind of OK.

• Below is the screenshot linked to the previous oscilloscope screenshot 3, when I stop after the first 2 expected replies from the first 2 slaves, and the data is missing for the first slave..

=> we can see here that oddly (but this is coherent with the oscilloscope screenshot) the TimeLoop for first slave is higher than the others. I guess the labview program stop working for a brief moment !?

We can see same behaviour on the penultimate (but as there is only 2 slaves plugged during this run on first and second position, it is not a big deal for this run)