Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

CAN input buffer overflow due to RTSI frame?

Hello,

I'm reading a continuous stream of CAN-messages with a CAN-Object. I'm creating occurences and reading multiple samples in a while loop.

A second (asynchronuous) task generates a RTSI trigger at specified intervals. I use this trigger to write a RTSI fram to the CAN buffer. However, I get buffer overrun errors frequently. I've set the read queue to 100 and I read 20 frames each time (on occurrence). I only seem to get these overrun errors when using RTSI!

Does someone know what my problem might be?

Thanks a lot!
0 Kudos
Message 1 of 4
(3,616 Views)
Hi Koektrommel

Yes you can get buffer overflows because of RTSI pulses. A timestamped RTSI frame is the same amount of data as a 'real' CAN Frame. If you configure your CAN card to timestamp RTSI events (in LabVIEW: On RTSI Input - Timestamp RTSI event), each single pulse on the RTSI line will generate a 'CAN frame'.
What is the frequency of the RTSI signal?

You can set up the CAN card to count every nth RTSI pulse, thus reducing the number of frames generated. For that, set 'RTSI Skip' to the number of RTSI pulses you want to skip.

-B2k
0 Kudos
Message 2 of 4
(3,609 Views)
Hello Biker2000,

Thanks for your answer! Currently, I'm having a lot of problems when I receive CAN-messages every 10 ms and generate a RTSI trigger with the same interval. The CAN-messages I receive have an extended ID, 250 kB/s, and 8 data bytes. I want to be able to read CAN-messages with an interval of 1 ms, and generating a RSTI time stamp every 1 ms. Skipping RTSI pulses is not allowed for my application!

How can I improve this all? Does it make a difference if I define a custom RTSI frame (less data bytes)?

Thanks again!
0 Kudos
Message 3 of 4
(3,596 Views)
Hi Koektrommel

If “…and generating a RSTI time stamp every 1 ms” means that you have a 1 kHz signal on the RTSI port and you want to timestamp this, then it could be very tight. Every RTSI pulse generates an interrupt on the CAN card that the processor needs to execute in addition to the interrupts coming from the CAN controller and the communication with the Windows OS.
Two things I can think of, that potentially could make things a little faster:
  1. Do not use any CAN Objects. Due to their own queues, the CPU needs more processing time to handle to additional queues compared to just using the Network Interface Object.

  2. Use the CAN controllers filters to filter out as many (unwanted) frames as possible. If you have a Series 1 card, you would use the regular Mask/Comparator settings for ncConfig, for Series 2 hardware you need to use the Series 2 specific filter attributes.
-B2k
0 Kudos
Message 4 of 4
(3,555 Views)