Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

Does nxFlush work without nxStop?

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?

0 Kudos
Message 1 of 6
(10,487 Views)

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.

 

 

 

 

0 Kudos
Message 2 of 6
(10,476 Views)

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.

0 Kudos
Message 3 of 6
(10,471 Views)

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. 

0 Kudos
Message 4 of 6
(10,469 Views)

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!

0 Kudos
Message 5 of 6
(10,436 Views)

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

0 Kudos
Message 6 of 6
(10,413 Views)