High speed CAN cyclic time varies with Arbitration Id

[swathik]

Hi,

     I am using NI 9862 high speed CAN module to transmit 6 cyclic data, each of different transmit time. The first 3 cyclic data is transmitted for every 100ms, 4 and 5 cyclic data is transmitted for every 500ms and 6 cyclic data is transmitted for every 1 sec.

I have used NI X-NET Data Base Editor to create frames. Initially i created a cluster under that cluster i have create  6 frames with different transmit time. The Arbitration Id i kept for each frame is 2A, 2B, 2C, 2D, 2E and 2F in hexadecimal (refer attachment - Frame creation.png).

When i tried to transmit these frames with the above mentioned Arbitration Id, i was able to get proper timing (refer attachment - correct timing.png). You can see the proper timing in Rel TS Column.

I changed the Arbitration Id to 12C, 136, 140, 154, 15E, 168 for all the 6 frames. which resulted in the improper transmit time. (refer attachment - Incorrect timing.png). You can see the improper timing in Rel TS Column.

When changing the Arbitration Id  from 1 bytes to 2 bytes (i.e from 2A, 2B, 2C, 2D, 2E and 2F to 12C, 136, 140, 154, 15E, 168)  the transmit time gets affected. I am not sure what is the relationship between transmit time and Arbitration Id. 

Please help me with this issue.

[Hooovahh]

That doesn't sound right, but we are still missing some key pieces of information like the source code. What kind of sessions were created?  What does the code look like?  I think you want a single point Frame Out session type, and only write the values when the payload changes, initializing once before a loop, and closing once after.

[JefeL]

I'm not sure what application you are using to monitor the bus so it is difficult for me to say how they calculate their timestamps. Using the XNET bus monitor to gather a similar log trace would be helpful since I will how it works under the hood.

That being said, there is a relationship between frame ID and when said frame is initially transmitted. For cyclic frames, XNET uses a pseudo-random load balancing algorithm that used the frame ID as a seed. The first cyclic frame of a specific ID will transmit at a random time between the call to XNET write (T0) and XNET write + the Transmit time (T0 + Ts). This range can be controlled with the Frame:Start Time Offset property.

Aside from that property, Cyclic frame timing is handled in hardware and is very precise assuming there are no arbitration losses due to other traffic.

If in the event we are looking at a bug, we will also need to know what version of XNET you are using in addition to the relevant source code requested by Hooovahh.

[Minions]

Having not used XNET, is this still based on the DBC, A2L,... files where the cycle data is defined in the Header Raster statements as seen in an A2L file?  If such is the case, can you provide your database file (lite) for review, or at least the header information as these files tend to be quite large?

[swathik]

Hi,

        I tried using  Frame start time offset property. but it doesn't work as expected. I have attached my VI and the .xml file.

[JefeL]

There are a couple of problems we are running into here. In your Test.vi the start time offset is not being set properly and only applies to a single frame in the session. The correct way to set the property would be like so:

The second and larger problem is that this property does not appear to be working as expected. The snippet of code would be expected to transmit frames 1 through 5 in that order but on my machine frame 3 is transmitted first. That being said, the frame to frame timing does match with the configured Transmit time in the database. Frame 1 is always transmitted 100 ms appart, frame 5 with 500 ms etc. 

I will file a bug report to investigate the Start Time Offset property.

[swathik]

Is there any other possible ways to achieve the proper timing?

[JefeL · Accepted solution]

The Transmit Time of a frame is not affected by the bug. Cyclic frames will be transmitted automatically as close to the minimum transmit time as bus traffic and ID contentions allow. I modified the example a bit to read back the frames we transmit and view the timestamps on each frame. The timestamps are derived from a on-board hardware clock and are highly accurate with regards to relative (frame to frame) timing.

We can see that each frame is being transmitted at almost exactly the correct interval based on the Transmit Time property.

The bug does prevent us from having the expected control of which frame is transmitted first. In this case, I would expect frame 1 with ID 0x122 to transmit first since I provided the lowest StartTimeOffset. Instead frame 3 is transmitted first and violates the programmed start time offset of 27 milliseconds.

[swathik]

Thank you so much for your help. my problem is solved.

[GPIB_Guru]

I do not believe there is a bug in NI-XNET. Instead, I think the bug is in the test VI. In LabVIEW, the active frame property is valid for a single property node. In the loop, where you are setting the Active Frame in one property node and the Start Time Offset in a different property node isn't doing what you anticipate. Instead, the first property node is a no-op and the second one is ALWAYS acting on the first frame.

So, your VI is setting the start time offset of the first frame N time, with the last one winning. Since that is the latest time to start, the first frame is delayed. The other frames (frame2-frame6) are using the default value of 'magic number', so they are dependent on the ID and are likely running before Frame1.

The solution - merge the property nodes into a single one. Put the Frm.Active on top and Frm.CAN.StartTimeOff on the bottom and voila, magic (the good kind) should commence.