Recovering from XNET Read Queue Overflowed Error

[mpanganiban]

Hi,

I did some evaluation in forcing XNET read queue overflowed error (-1074384885). I am using NI USB-8502 and I just did a loop back between ports CAN1 and CAN2.

I created two asynchronous VIs in which one is writing a CAN Frame(every ~500ms) and the other VI is reading(using XNET Frame In Stream session and calling XNET Frame read every ~50ms) it. In the VI where I am reading it, I added a mean(checkbox - boolean logic) to skip calling XNET Read VI to force the overflow.

After skipping the call of XNET Frame Read for a couple of seconds by enabling the logic and disabling it again, I am seeing error -1074384885 which is expected but only once and then on the next iteration(every ~50ms), there is no more read queue overflowed and I am getting the expected data thus I can say it can recover from the read queue overflowed error.

On the other hand, I have this big application where I have multiple Frame In and Out Sessions, Frame In Queued session, Signal Output in multiple asynchronous VIs and the behavior is not the same. When I first encountered the read queue overflowed error (-1074384885), XNET Frame Read VI is continuously returning this error on the succeeding iterations. I know it would be easier if I can share the code here but is there a quick explanation what could be the possible cause of this?

Thanks,

Michael

[Hooovahh]

I've not seen this behavior.  As you described I would see the overflow on the first read, and then any reads after (if I were able to keep up, and didn't keep the error around by keeping it in a shift register) don't have the error.  I'm guessing a clear, and re initializing the session will clear the error, but that seems excessive.  Is it possible that the error is being kept around in a shift register?  Or that the overflow is continuous, meaning the time to process all those frames, is more than the time to fill the buffer again?  Seems weird and I'm not sure what else to suggest.

[mpanganiban]

Thanks for your opinion Hooovahh. I am pretty sure that the error is not propagating to the next XNET Frame Read VI call. I am now leaning more to the fact that the overflow is continuous but I will do further investigation for this.

Best,

Michael

[Minions]

It does sound as if this is an issue with reading the buffered data.  Any loop that uses a shift register or especially if it is building an array will slow down some over time.  Make sure that the loop for reading the data is separate from the one saving the data.  You may need to increase the frequency at which you are reading the buffered data or if possible, increase the size of the buffer.

[mpanganiban]

Thanks for all of the replies in this thread. Increasing the buffer does help and that is what we did to improve the performance. However,

I performed further evaluation on the XNET Read Overflow issue last week and was able to reproduce and narrow it a bit.

Unfortunately, I was not able to strip down the LabVIEW code to share it with you but I captured some FP and BD screenshots(Please see attached image) to explain what the code does.

Looking at the ‘Front Panel’ section of the image, I added four checkbox controls to be able to disable/enable cases that:

• Set the session’s queue size to a specific value(500000) or ‘Default’ value
• Calling/not calling the ‘XNET Read.vi’ to build up the frames in the queue and force the ‘Error -1074384885 - NI-XNET:  (Hex 0xBFF6300B) A read queue overflowed. Solution: reduce your data rate or call Read more frequently.’

In ‘Block Diagram’ section of the image:

• In ‘Init’ cases, I am creating ‘Frame In Stream’ sessions with ‘standard’ and ‘J1939’ types.

Note: Setting the queue size to ‘500000’ is what we did to improve the performance.

• Calling ‘XNET Read.vi’ every 50ms
• Calling ‘XNET Write.vi’ every 1000ms

Evaluation:

1. I use default queue size for the ‘Frame In Stream’ sessions (by enabling ‘Use Default Queue Size for Frame In Stream’ and ‘Use Default Queue Size for Frame In Stream(J1939)’ checkboxes) and run the VI.
2. In normal condition, the ‘XNET Read.vi’(Standard CAN) is reading ~15 frames each 50ms call while ‘XNET Read.vi’(J1939) is reading ~10 frames each 50ms call.
3. After it finishes the initialization, I tried enabling the ‘Do not call Frame Read?(J1939)’ checkbox for a few seconds ~5 to ~10seconds and disable it again.

Results:

1. No error is being reported
2. The ‘data’ output of ‘XNET Read.vi’(J1939) spiked to array of 1000 right after I disable the ‘Do not call Frame Read?(J1939)’ checkbox control (which is normal because of the queued frames) and went back to ~10 frames.
3. I kept doing this and no error is being reported.
4. I disabled the ‘Do not call Frame Read?(J1939)’ to test the next step.

4. I enabled ‘Do not call Frame Read?’ (for the standard CAN) and waited ~5seconds. After disabling it again, I can see one Error -1074384885 reported in ‘XNET Read.vi’(standard CAN) and it goes away. I did this at least three times and the result is the same.

One of the things I noticed here is that whenever I enable ‘Do not call Frame Read?’ to skip calling the ‘XNET Read.vi’(standard CAN), after ~2seconds, I can see that the data returned by the ‘XNET Read.vi’(J1939) between each call(every 50ms) is an empty array – probably when it starts filling up the queue.

5. After doing step#4 more and longer (~15seconds of waiting), then all API calls(XNET Read.vi, XNET Write.vi) for the J1939 are returning Error -1074384885 at each call and can only go away by restarting the application.

Please take note that even the ‘XNET Read.vi’(J1939) is returning ‘Error -1074384885’, it is still able to return the frame that has been read.

One of my colleagues told me that there is something in J1939 that it cannot clear its buffer? If this is this true, could it be the reason why?

Looking forward to your inputs. Thanks.

[dhaugen92]

Theres an XNET API function called 'flush queue' under the advanced pallet.

have you tried that?

[frank.wen]

Hi Friend,

Thanks you for your investigation about CAN read queue overflowed issue

I checked your verification process carefully and I have some questions to ask you, please share your details with me if you are free,

1. the description mentioned queue size default and specific value, you you know what is the default number?

2. what is the diference between  Frame In Stream(J1939) and Standard CAN stream?

Thanks