Maximum NI-XNET Queue Size; .tdms to CAN stream

[Scotty96]

I am attempting to stream a .tdms file containing approx. 38,000 CAN frames to a vehicle network. I am using the "Replay CAN frames from TDMS logfile.vi"  XNET example to get started.  After the VI runs for several seconds I receive the following error:

Error -1074384727 occurred at XNET Write (Frame CAN).vi

You tried to set a queue size that is bigger than the maximum allowed. Solution: Specify an in-range queue size.

I understand the default queue size is 96000 (4000x24bytes/frame) which I am certainly exceeding, but I cannot find any information on the actual max allowed queue size.  What is the max queue size and what are my options so I do not exceed it?  My goal is to record vehicle network activity over the course of 3-60mins and replay that network activity to analyze failures. Hence the many frames. Thank you for your help, I don't know where I would be without all of you brilliant people in these forums.

Attached are the VI I am using and the .tdms file I am attempting to stream.
Info on queue sizes: http://zone.ni.com/reference/en-XX/help/372841L-01/nixnet/propertysessionqueuesize/

[Hooovahh]

So reading and logging 38,000 CAN frames is no problem at all.  Just don't try to read all 38,000 at once.  Instead maybe read frames every 100ms, and log however many came in.  If no frames came in those 100ms, then don't log any.  If 5 frames came in, log those 5, and then wait 100ms and read some more.  The hardware buffer is limited in size and has to have a limit, but you can read from it, and clear that buffer periodically.

Edit: And actually there is an NI example that already does this for you.  Open the CAN Input Stream to TDMS Logfile example from the Help >> Find Examples. From here specify the port, and baud rate, and the log will be made.

[Scotty96]

Hi Hooovahh,

Thanks so much for your swift response.  I don't think I explained myself well enough though.  I've already recorded the frames (using a modified version of the CAN input Stream to TDMS Logfile VI).  The problem arises when I am attempting to replay that TDMS file to the network.  I can replay tdms log files of up to about 8,000 frames without issue. More than that and I receive an "exceeding maximum queue" error.  I'm fairly certain I need to implement a buffer like you suggested for reading frames, to the write function, but am struggling to create a functional one.  Thanks again.

[Hooovahh · Accepted solution]

Oh I understand, sorry I was assuming you were reading frames not writing them.  Well the reverse is still true.  You can read N frames at a time, then periodically check how many frames are waiting to be sent in the queue.  This is the Number of Values Pending property.  Once this number gets lower, add on a few more frames using the write again and again until all your frames have been written.  Some experimenting could figure it out what the maximum queue size is but I don't have hardware to test with at the moment.  I posted this demo code a while ago showing the concept of filling the bucket of the queue before it runs out.

https://forums.ni.com/t5/Automotive-and-Embedded-Networks/Queue-size-for-XNET-Write-Signal-Waveform/...

[Scotty96]

Thank you so much, that example is a huge help.

[Scotty96]

Implementing the suggested code solved my queue over run issues but now my VI runs indefinitely.  This is more of a LabView basics issue than Automotive Embedded, but any pointers as to where I am going wrong? Why is my array never emptying? Thanks again for all of your help.  Screenshot and VI attached.

[Hooovahh]

Well  if the array is never empty my next question is, are frames actually going out?  Does the Number Of Values Pending just stay at 1000? (use a probe to find out while it is running).  If it does then that means the frames aren't actually going out, and this can be a sign of having no devices on the bus read the frames that are attempting to be written.  I'd add a stop button on the UI, replace the OR with a Compound Arithmetic which can be an OR with three terminals.  Also if you do press the stop button you probably don't want to perform the Transmit Complete function, so put a case structure around that.

Another option might be to put another CAN device on the bus to listen and see if you can read the frames you are supposed to be writing.

Also the way it is written the frames won't have timing in the same way the log was created.  By default the interface works in Immediate mode where it will try to write all frames as fast as possible, so you put 1000 frames in on the write, and those 1000 frames will go out in probably something like 10-100ms which isn't what I think you want.  Look at the Replay CAN Frames from TDMS Logfile.vi example (Help >> Find Examples) and you'll see the interface is configured in Reply mode which tells the interface to space out the timing of the frames depending on the timestamps from the frame.

Also you don't need to set the Baud Rate inside the while loop, setting it once outside is enough.