Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

CAN input overflow

Hi, All!
I'm using PXI-8186 CAN card to read and write CAN messages. To do this i use the channel API, it works quite perfectly, but i still can't find the solution for two problems :

1) I initialized my CAN task to work in input mode, and i read the values of the channels every 1 ms. When i make a stop and a start i got this message: Error 1074388952, i.e. overflow in the lower read level read queue of the CAN card ... Well, the message is clear: my buffer is full . But how can i prevent this message to appear ??? How can i set the buffer size with channel API ?? Is there an option to set in order to read the last value ? I don't want to bufferize anything...

2) My other problem is with the writting. When i transmitt frame and no device is listening, i have a error message and it stops my application.. How can i ignore this error and continue to transmitt my frames??? Always with the channel API ???

Thanks a lot for your answer.. euuhhh i hope someone will answer !
0 Kudos
Message 1 of 8
(5,527 Views)
For Question #1, 1 mSec is about the fastest you can handle in Labview and still be able to run without buffers, because of the fact that it uses a Windows Operating System. You will have to either switch to Labview RT, (it functions without Windows OS) or start using the buffers. My suggestion is to use the buffers, they are efficent for this application, and if you use buffers, you can slow down your application to give more time to processing other tasks.

Question 2. The CAN specification REQUIRES at least 1 receiving node on the bus for a successful transmission of a message. The CAN transmitter relies on a receiver to inform if the message was sent without errors. If there is no receiving node, the transmitter will get stuck in a loop transmitting the message over and over again until it generates an error. You can usually get around this problem by having 1 passive node (configured for receive only) on the bus whenever you run your VI. That is why many people use 2 port CAN cards.
Message 2 of 8
(5,514 Views)
Hi dhuff! Thanks for your quick answer ...

Euhh... in fact i'm using labview RT, To be more specific about my application, i use a cadenced loop (1Khz), and every cycle i read all channels! As i said, that's seems to work, but when i make a CAN stop / start i got this strange error telling me my buffer is full! Idealy i don't want to use any buffer, i just want to read the last value of the channels! But ok, if i have to use these buffers that's ok.. the problem is i don't know how to use them and i didn't find any exemple with channel API and buffer, could you send me an exemple or a link ???

For my second problem, I knew CAN require at least one receiver.. I use a 2 ports CAN card, but i need these two ports and i don't want to buy a new card only for this error! I was just wondering if it's possible to clear this error, i mean continue to transmitt message even if there is no listener... Is there no special mode or configuration ?

Thanks again for your answer!
0 Kudos
Message 3 of 8
(5,511 Views)
It sounds like you have a few things left you can try.
1. Tighten the CAN receive filters to only allow the messages you need
2. OR switch to NI CAN frame API's. These will give you better control over the configuration, including the ability to set custom buffer sizes, better filter options and faster response times. The big downside of NI CAN frame API's is that they require you the programmer to do all the work, so they are harder to learn.
Check out the example code link for the example code NI CAN example using Frame APIs, it is submitted under third pary examples.
NI CAN example using Frame APIs
The example was written to use CAN buffers (at the speed you need, you will probably need to use buffers) You can probably get response times down into the 1 to 2 mSec range if you do it right.

For the second problem, whenever you get that error about CAN comm warnings, try doing a CAN close and CAN reset, most of the CAN reads and writes will not work if there are errors.
0 Kudos
Message 4 of 8
(5,500 Views)
Ok ...

I will try to set the filter as you said, till now i didn't set any filter that's maybe a solution ... but i can't switch to frame API, my project is almost finished, and i think there's a lot of work to switch from channel API to frame API! Anyway, i don't understand why you can't set the buffer size with channel API, or why you can't say you don't want to use any buffer, this API can't overwrite the last value ???? Again this problem only appear when i stop and restart the communication...


For my second problem, i think (euhh ... i hope) it will not happen! Normally another CAN device will be connected, and therefore one device will always listen !

Thanks again for your advice, i will try to set these filters, and i hope it helps !
0 Kudos
Message 5 of 8
(5,490 Views)
Since the loss of messages due to the overflow of the CAN read buffer is not a problem in your case, I suggest you to filter the error cluster.

The best is to create a VI. See attached example.

1) Check if there is an error in the error cluster
2) If there is an error then check if it is a CAN read buffer overflow error (compare error code)
3) If yes, then flush the read buffer and reset the error cluster


Put this VI in the place where the error dialog box appears.
0 Kudos
Message 6 of 8
(5,478 Views)
Thanks for your message JB, and sorry to be so long to answer...

That's exactly what i wanted to do, the problem is i don't know how to flush the read buffer, in my knowledge there is no way to do that using channel API!!And that's the problem, but maybe i miss something! The only way is to read all sample, and that's exactly what i want to avoid ....

Well i contacted NI, i hope someone will help me,
0 Kudos
Message 7 of 8
(5,462 Views)
What I do in the Frame API is to read the number of messages in the queue (ncGetAttr.vi) and then I read them all at once (ncReadNetMult.vi for the whole CAN bus or ncReadObjMult.vi for a CAN object). Because ncGetAttr.vi will generate an error, it is important to not connect the error cluster between both VIs. See attached picture.

I have never used the Channel API and unfortunately I don't have the time to investigate in detail right now. But it really seems that you can do exactly the same with the Channel API. Read the number of messages in the queue with CAN Get Property.vi (right-click on the VI --> Select type --> Number of Samples Pending) and then use CAN Read.vi to read them all at once.

What's the difference between flushing the queue and reading and ignoring all messages at once ?
0 Kudos
Message 8 of 8
(5,451 Views)