08-04-2017 12:52 PM
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
08-04-2017 02:05 PM
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.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
08-08-2017 07:51 PM
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
08-11-2017 12:21 PM
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.
08-28-2017 03:15 PM
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:
In ‘Block Diagram’ section of the image:
Note: Setting the queue size to ‘500000’ is what we did to improve the performance.
Evaluation:
Results:
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.
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.
10-17-2017 08:30 AM
Theres an XNET API function called 'flush queue' under the advanced pallet.
have you tried that?