Ignoring FIFO Overflow Error -200141

[FTI_Newton]

A common error experienced by many: the internal 1 sample (or 2 sample) FIFO on a counter gets overwritten before your call to the DAQmx driver can read it out.

Here are the usual suggested 'fixes' which do not work:

Ignoring the error in software is not a solution; the DAQmx task stops and must be restarted.

Overwrite Mode = ON for the the buffer configured is not a solution: doesn't address the problem.

Reduce bus activity. ALready minimized.

Lower the update rate of the signal (or divide down). That signal may be required as-is.

The core question:

Can you configure the device (an MIO card for example) to overwrite its own internal FIFO without generating an error/interrupt/etc?

All it would do is continually overwrite that FIFO whether it was read or not.

[Raajit_Lall]

Hi,

You have a good question, and the reason for this kind of behavior is explained by the way buffered counter operations work.  This is explained in the article linked below, incase you want some details on how buffered counting works.

How are Buffers Read in Finite vs. Continuous Buffer Mode for Counter Operations?

As far as your question is concerned, I understand that you have tried a lot of different solutions, and it seems like none of them have worked for you yet.  However, I am curious about how you have tried to minimize the bus activity.  Are you using DMA transfers right now, and how many counters are you currently reading on?

One option that you might not have tried is using a producer consumer architecture.  You can do all your readings (hardware) in your producer loop and all of your analysis in a consumer loop.  If you have LabVIEW, you can use a template for the producer consumer loop.

You can also monitor the number of samples that are available in the buffer using the available samples per channel property node.  Here is another forum that talks about a similar issue.  You can monitor the buffer and read it only when its empty for example.

Hope some of this helps.

Regards,




Message Edited by Raajit L on 04-07-2008 10:30 PM

[FTI_Newton]

I am using a very basic test program for the purposes of trying to figure this out. I have turned off all operations that write to disk. I do have a parallel task that generates a waveform, but that is required for the system to operate. There is not much else happening on the bus. I took out all unnecessary PCI cards (NIC, sound card).

The counter task is running in it's own loop. All it does is display the value.

This is my understanding of it; correct me if I'm mistaken:

During a continuous read operation, the driver is reading the FIFO to fill the buffer in the background. How the program is written to read out of that buffer is irrelevant. If the software buffer overruns, that is a totally different error than when the FIFO doesn't get read in time. The only thing that would interfere with the FIFO transfer is if the DAQmx task that transfers the data is too slow (and since it's in the background, there's not a lot that can be done about it), or if there is too much bus activity, not allowing the transfer to occur in time.

If the above is correct, all of the suggestions about changing programming style will only address software uffer overruns, not FIFO overruns. That's why I simple want to suppress (or ignore) the FIFO overrun error. .

Back to the original question:

Is it possible to configuer the device or the task to allow FIFO overwrites without generating an error?

[J_Thomas]

Hi FTI Newton,

I have a couple of thoughts about your question.

First, if you are not concerned with losing samples (FIFO samples getting continuously overwritten), why not reduce your sampling clock rate and avoid the error in the first place? Reducing the sample clock rate may also cause you to lose samples (depending on how fast your input signal is), but it would prevent the hardware FIFO from getting overwritten and sending an error.

Second, a few benchmarks have been completed for some of the M-Series devices to determine the maximum sampling rate for counter operations on various devices.  These benchmarks are system dependent, but they may give you some guidelines for your own application.  One thing to note is that not all M-Series devices have the same counter FIFO size.  The USB-621x series for example have a counter FIFO of 1024 samples.  If another solution can’t be found, switching to a device with a larger counter FIFO would eliminate the issue.

Third, after checking several resources, I don’t think it may be possible to configure a device at the hardware level to overwrite FIFO samples without generating an error or interrupt.  If a solution does exist, it most likely will be complicated.

Fourth, you have not mentioned very much about your actual application.  Here are a couple of questions:

• What type of measurement are you trying to make and what parameters are you using (input signal rate, sample clock rate, etc..)?
• What device are you using?
• Are you using DMA (Direct Memory Access) transfers?

[FTI_Newton]

It's a counter operation on an Eseries card. FIFO = 1 sample only. (M series = 2 samples BTW).
To be more specific, frequency measurement (gated pulse counts).

I specifically set it to use DMA. For a single sample FIFO, I'm honestly not sure if it matters -- are DMA transfers initiated with an interrupt?

Message Edited by FTI Newton on 04-09-2008 11:21 AM

[Kevin_Price]

To my knowledge, there's no way to suppress or ignore the FIFO overflow error.  The suggestion to consider the USB M-series board with a much larger on-board counter FIFO seems like a good one.  But if you're stuck with your available E-series board, then all you can do is try to *avoid* the error.

1. You mention freq measurement.  How is this measurement used?  What does it mean?  What range of frequencies do you need to measure?  What kind of precision do you need?  How frequently must you update your measurement?

2.  I'm not sure which method of freq measurement you're using with your reference to "gated pulse counts." 

2A. Are you using an internal timebase to measure the interval time between edges of your external signal?   Is your nominal freq in the realm of 100's of kHz?  If so, this method is probably a dead end.  If not, then perhaps part of the problem is due to a noisy input signal.

2B. Or are you counting edges of your external signal while using an on-board sample clock?  This gives you control over the sample rate and you should be able to experiment and find a rate that works without FIFO errors.  Naturally, with this method you tend to trade off precision (best with low sample rates) with measurement update rate.

3.  Maybe you can do this measurement in a non-buffered mode?  There'll be more overhead to each measurement, but I would expect it to prevent any FIFO errors.

-Kevin P.

[FTI_Newton]

Using method 2A.

Frequency range is approximately 50 - 500Hz from a 60-toothed gear/HES on a rotating shaft to measure speed (position is unimportant). Resolution to .5 RPM is all I really need. I'm also averaging over an integral number of rotations of the shaft (multiple of 60). Losing a tooth measurement every so often is not too significant. The velocity is relatively constant over a test. The main reason for the average is to get rid of mechanical noise.

The signal is clean. I've checked it with a scope, and injected noise on purpose just to see how badly it behaves. With a glitchy signal you'll see the RPM jump all over the place as the square wave output of the HES retriggers repeatedly (this also generates errors as you might expect). However, in this case, it just seems to eventually 'catch up' and overrun the FIFO as the frequency increases.

2B method sounds like it might work for me, by counting every n*60 pulses as a single revolution.

I'd still like to be able to allow FIFO overwrites as a general principle, something to keep in the back pocket. And, the M series does not have a much bigger FIFO for the counters. It may sound that way if described as...
     "FIFO on the Mseries is doubled that of the E series! Get yours today!"

However, 2 * 1 = 2. No doubt that it would make the problem less likely (or at least raise the frequency at which it occurs), but that's no good - I need it gone 100%.

I think I'm just going to have to use the drive controllers to give me my speed and do it all without NI Hardware. That's always worked fine before someone insisted we try using this darned thing.

Message Edited by FTI Newton on 04-09-2008 02:14 PM

Message Edited by FTI Newton on 04-09-2008 02:23 PM

[Kevin_Price]

FWIW, seeing FIFO errors at a rate of only ~500 Hz *really* makes me suspect noise in the signal.  I've used E-series boards to measure frequencies up into the 10's of kHz without FIFO errors.

I'm no expert at tracking down and fixing noise problems, but have encountered issues from time to time where the counter was seeing edges that I couldn't observe on the scope.   Try out method B -- then fast bursts of apparent HES edges will appear as an overestimate of speed rather than a FIFO error.

-Kevin P.

[FTI_Newton]

Already ruled that out.  It's a clean signal - not only observed on a scope, and look for noise by reading it with AI, but I've already tried using a funcgen into the counter inputs instead of the tooth sensor, I get the same issues - errors with higher speed.

I'm 99% sure it's the continuous DAC outputs taking up too much bus time. No way around that - I need it to control my system. Another reason to go back to programming the motor drives - the E series card goes away entirely.