How do I clear CAN frames out of the kernel level queue?

[rothloup]

I am programming a CAN application, and I keep getting an error -1074388710. This error says that the kernel level queue is filling up and overflowing. The "solution" tells me to read out the frames faster - but I already read them out as fast as I can! In fact, whenever I run the application, I get old CAN data from as far back as the last time I started labview, even if I've already read those data frames when I ran my VI earlier. In order to deal with this, I have a VI I call right after opening a comm session which reads out CAN samples until their timestamp matches the current time. It seems that the "Read" VI doesn't flush the sample it reads out of the CAN buffer. How do I clear samples out of this buffer?

Thank you,

[DirkW]

Hi Rothloup,

It seems you are not reading fast enough, so you will have a backlog of messages in the memory which causes the queue overflow over time.

The only way to overcome this problem is to read more messages at the time or to filter the incoming messages on controller level to receive only particular IDs.

Sometimes it is useful to monitor  the messages pending attribute to see the backlog of messages.

In any case the memory should be cleared if the ncclose is called. If not in case the programm has crashed or the close is not executed properly it can happen that the memory has old messages available. Take care in your programming flow to execute the ncclose in any case.

Hope that helps

DirkW

[rothloup]

Dirk,

Thank you for your response.

My inputs are setup as Time-stamped inputs, so the Channel API GET Property method returns an error when I try to request the number of pending samples.  Even when I read as fast as I can, I still get an overflow. 

I don't think it's a simple matter of reading the data out faster, because when I re-run the same VI without exiting labview, OLD DATA is still in the queue and is read in as new data!  So, even tho it has already been read by my application before, it is still there.  I had to write a VI to skip over old data until the timestamp matches the current time. 

I also do make sure to close the comm session before my VI stops, but the VI doesn't call that if I have to press the Stop button at the top.  So it doesn't close the session it if I do that.  But I still have this problem even the first time I run the VI, so it doesn't just have to do with closing the session. 

[DirkW]

Hi Rothloup,

Yes thats true, the samples pending attribute doesn't work with timestamp mode. available.

It seems there is a very high busload and you still don't read fast enough.

In this case try to configure the samples to read with 10000 and read all samples available.

If this don't help, try to use the busmonitor within max to read the traffic, to get an idea how many message/Sec. you get.

Then try to adjust your while loop timing and the samples to read, to match the traffic on the bus.

DirkW

[Bert]

Hi Rothloup,

still have the problem? I also fighted with buffer overflow messages. At least for my application the solution was easy. It strongly depends on the order of initilizing hardware if you get the CAN reading working or not. Imagine you have DAQ and CAN IO processes. To empty the CAN buffer it is recommended to initialize all other hardware first and start the CAN imediately before your continous (CAN) data aquisition begins. Maybe this helps.

Bert

[rothloup]

My read loops run far faster than my the bus traffic.  I read every millisecond - my messages are transmitted, at fastest, every 3 ms.  Processing time is faster than 2ms, so I'm reading in faster than the packets are coming in.

Is it possible that if there is traffic on other channels which my program does not read and are not part of the read task which I have initialized, that these samples are the ones which are filling up the buffer?  If so, can I filter those messages somehow so they don't get put in the buffer in the first place?  Or does every CAN message that comes over the bus have to be read by my program, whether my program is interested in them or not?

[Bert]

Hi Rothloup,

No, you don't have to read all CAN traffic (I'm sure with this). Important is, that any kind of hardware listens to your sender, otherwise the sender can go busoff after a certain time. I don't think that other meassages that you don't have specified  can fill up the buffer. But this question can be answered from a NI CAN expert (Dirk).

What type of system do you have? "Normal" Labview (plus Windows) or Labview-RT? Do you have other hardware running than the CAN card? Have you any other hardware to monitor the bus traffic (e.g. canalyzer)? When does the error message pop up, immediatly after the CAN initializing or after a few samples read? Does your application runs without timestamps? Can you post a screen shot of your application?

Bert