losing CAN frames sometimes with XNET

[pgraebel]

I am sending CAN frames with the XNET interface in CAN out stream mode. Sometimes I am losing CAN messages if they get too close together. The messages are only known at runtime, so I have to setup a message (id, data length) manually (no database).

The screenshots are showing my CAN VIs. Is there something I forgot in my CAN initialization?

[GPIB_Guru]

Immediately after your write you are calling flush to flush the queue (erase all pending frames to be sent). Is there a reason for that?

[pgraebel]

My intention was to transmit the message immediately by calling flush. Does it work like a file flush (like fflush in C)? I want to send immediately but without losing CAN messages.

[GPIB_Guru · Accepted solution]

Flush in XNET has a different meaning than in file I/O - it means to erase all pending messags. When you call XNET Write it will immediately send the message to the hardware - in other words the file I/O flush is automatically implied.

[pgraebel]

Thanks. It was just a misunderstanding with the Flush VI. Removing the VI seems to resolve my problems.

[Paul M.]

One of the nice things about the new architecture is that thanks to the device-driven DMA back-end, frames sent out in stream mode are nearly instantly put on the bus, so you don't have to worry about buffers backing up unless you're saturating the CAN bus itself.  Most other CAN interfaces (including Series 2 CAN) use memory-mapped functions which can limit your throughput and response times.

[GPIB_Guru]

I think you have exposed a hole in our documentation. I have filed a report to have the online (Ctrl-H especially) documentation updated to be explicit on the role of Flush. Thank you.