07-01-2010 06:08 PM
I am using XNET hardware and seem to be getting spurious CAN frames, even after flushing the queue first before reading. The documentation wasn't clear about whether or not the session had to be stopped for the flush to work, and so I was wondering if that was the case?
07-02-2010 10:12 AM
Hi Borgel,
The following is from the NI-XNET Hardware and Software Manual (which is a great resource for XNET questions):
"With the exception of single-point modes, all sessions use queues to store frames. For input
modes, the queues store frame values (or corresponding signal values) that have been
received, but not obtained by calling nxRead. For output sessions, the queues store frame
values provided to nxWrite, but not transmitted successfully.
nxStart and nxStop have no effect on these queues. Use nxFlush to discard all values in
the session’s queues.
For example, if you call nxWrite to write three frames, then immediately call nxStop, then
call nxStart a few seconds later, the three frames transmit. If you call nxFlush between
nxStop and nxStart, no frames transmit.
As another example, if you receive three frames, then call nxStop, the three frames remains
in the queue. If you call nxStart a few seconds later, then call nxRead, you obtain the three
frames received earlier, potentially followed by other frames received after calling nxStart.
If you call nxFlush between nxStop and nxStart, nxRead returns only frames received
after the calling nxStart."
In these examples, the calls to nxFlush are when the session is stopped so I recommend trying that.
07-02-2010 01:11 PM
Ah yes, thanks for pointing that out, Im not sure how I missed it.
My problem seems to change then. Even after a flush the session I am reading from, there still seem to be packets that build up in it at an impossible rate. For instance, the following situation.
I use another CAN tool to both send one frame per second, and watch the bus for traffic. It sees nothing besides its one packet, which it sends for, say three seconds. I run my program, and after waiting (much) less then a second after flushing, the buffer contains those three frames, and their timestamps report a frequency of (much) less then one second.
So I think I am seeing two problems.
1: The XNET hardware seems to be collecting packets even when it isnt initialized. And nxFlush does not seem to be flushing out this buffer.
2: The XNET hardware is recording time stamps incorrectly.
07-02-2010 01:56 PM
I figured it out.
My external tool (a PCAN-USB dongle) had a hardware output buffer which was undocumented. And the XNET hardware wont respond when it is off (which makes sense). So what was happening was that I would send messages while the XNET hardware was off and the dongle would realize that they were not being recieved and buffer them in lieu of transmission. So the next time I ran my program, the XNET hardware would begin responding and the dongle would send all the frames out as fast as possible.
So all is well, and the XNET hardware was working correctly. I apologize for the false accusation.
07-07-2010 11:15 AM
Hi Borgel,
Nice troubleshooting! Your explanation certainly makes sense. If you have a moment, please post again with the part number and/or model number of the USB dongle. That way others searching for a solution to the same problem in the future may more easily find this thread. Thanks!
07-12-2010 02:01 PM
Good idea.
It was a PCAN-USB dongle (Part #: IPEH-002021, Found at http://www.peak-system.com/Produktdetails.49+M578cbdb898b.0.html?&L=1&tx_commerce_pi1[catUid]=6&tx_c...), by Peak System.
Borgel