Make XNET internal queue lossy

[iwane]

Hi all,

 Is there any option to make an internal XNET (CAN) queue lossy? I'd like to have an input queue that hold only n latest messages (running history) without throwing errors. Is it possible inside XNET or do I have to work around it in software?

 Thank you in advance!

[Hooovahh · Accepted solution]

Your only option for doing this is going to be to write software to handle this queue on your own as far as I know.  There are some options but it will all boil down to reading all CAN frames, then keeping track of them throwing away some as you go.

How long of a buffer are you looking for?  I've created a system where when a test ends, we have a CAN log of all CAN traffic from the last 10 minutes.  I have a toolkit that logs to TDMS data, and it can be setup to log only the last N minutes of data.  In my case it makes a new TDMS session every minute, then after there are 11 sessions it closes the oldest.  Once it stops it combines the last 10 sessions into a single file.  NI has a standard for logging CAN frames to TDMS files so I just combined the two features so it runs, logging all data, then when it stops it only has the last time minutes.

I don't have a full setup of this working but I have the TDMS toolkit posted here, and here is a video showing how to use it.

But if the buffer you want to keep is much smaller, you can probably get away with just having an array, appending to it, then throw away the old frames once the array gets too large.

[iwane]

Thank you for the suggestion! I feared that, to be honest 😉 

TDMS logging will be the next step. Currently we're doing 2000-frame buffer to be checked during the test, sorted by IDs. I've done it before with use of limited-size queues and Lossy Enqueue Element, but I hoped to offload it to the HW... Well. Back to Lossy Enqueue, it seems.

The reason I asked is that with double buffering (both HW and SW) I encountered some strange situations - clearing the buffer queue and receiving stale data (because the HW buffer has been transferred to SW a while later). It seems that offline data evaluation would save us some bugs... but that's for future.