Counter buffer overflow error -200141

[NickNZ]

Attached is the DAQmx version.

The reason being able to switch tasks is important is that I will have two LabVIEW executables running, one to send commands to the motor controller and another that is running the user interface showing the speed and torque of the motor. And in parallel to the UI is a vi that is measuring the speed, torque and controlling the hysteresis brake on the motor shaft.

The user interface can log the data to Excel so the user will be switching between 3 applications. When switching I cannot afford to lose the RPM measurement or it will screw up the PID control of the brake.

Regards
Nicholas

[NickNZ]

Hi Everyone,

Just a follow up to my problem of overflowing counters with DAQmx and how I got around the problem.

First I upgraded to DAQmx 7.5.
Second I updated my hardware so the RPM pulses from the encoder go to the gate on Counter 0. I also use a HEF4526 to clock down the encoder pulses by 16 and connected it to the gate of counter 1.

I then wrote a VI where I read Counter 0 if the RPM falls less than 1000 RPM, and Read Counter 1 if the RPM is greater than 1500RPM. This works really well, with low CPU usage and can measure down to 10RPM and over 25000RPM. This method reduced the number of samples required for high speeds by 16, and yet keeps the loop running quickly at slower speeds when reading the raw counter.

I set counter 0 to auto start and I stop it if the RPM goes over 1500RPM. I set counter 1 to be running all the time.
I am still using measure pulse period on both counters.

Thanks to everyone who helped with my problem. I can now task switch and have other applications running without stuffing up the RPM measurement.

Nick

[Inpriser]

Hello,

I also encounter the same buffer overflow problem while performing buffered semiperiod measurement on a PXI 6602 card with LabVIEW Real Time 8 and DAQmx 8 drivers.

I normally expect to measure a 1kHz PWM signal and retrieve its duty cycle with roundabout 1% resolution.

I observed this overflow very easily by testing my cabling : using a mechanical switch as an input for the counter quickly produces an overflow. Since the board has a 80MHz timebase, I understood the counter measured all bounces on my switch. I hoped this phenomenon would not appear with my real system, unfortunaltely it also occured has the sensor may be plugged while the application is running...

The solution I found to avoid the problem was to use a 10µs numeric filter on all 6602 inputs. This also enables my 1% resolution over 1kHz signal. I also tried to use this technique with E-series DAQ board, but unfortunately this option is not supported. M-series support that but only with discrete values.

Now we are working on bigger systems (>200 I/Os of other types) and I again observe this -200141 error randomly. This is very annoying.

Since I only need the "current" PWM value, I am only interested in the last 2 values, so I tried to configure the task to ignore buffer overflows, but this seems not to be taken into account by the driver. Stopping and starting the task again as proposed by other user do not give any new measurements, indeed.

Going through the forum, I found many posts with users having problems with buffer overflow on buffered semiperiod measurements, but no solution seems to be available to make this kind of card doing these simple measurements with reliability.

As I know the card buffer is limited to 2 samples and as I am interested only for the last 2 measurements, is there really no way to work without DAQmx buffer to overcome this error ?

Thanks for your help.

[NickNZ]

Hi,

"I observed this overflow very easily by testing my cabling : using a mechanical switch as an input for the counter quickly produces an overflow. Since the board has a 80MHz timebase, I understood the counter measured all bounces on my switch. I hoped this phenomenon would not appear with my real system, unfortunaltely it also occured has the sensor may be plugged while the application is running..."

Is it measuring the widths of the bounces OK, but producing an error when the counter overflows when the new switch state is stable? A 24 bit counter counting 80MHz clocks will overflow in 209ms. Can you divide down the clock to 20MHz?  

"Now we are working on bigger systems (>200 I/Os of other types) and I again observe this -200141 error randomly. This is very annoying."

My app hasn't had a buffer overflow that has been noticable, in the last 3 months or so it has been in use. I don't have a RC filter on my signal from the optocoupler, just a 10nF cap to get rid of HF noise. Do you have dodgy grounding? On my old hardware when I switched a relay that would screw up the counter measurment when I was using traditional DAQ. So it random or is there something in your system that happens occasionally that could cause this?

"Since I only need the "current" PWM value, I am only interested in the last 2 values, so I tried to configure the task to ignore buffer overflows, but this seems not to be taken into account by the driver. Stopping and starting the task again as proposed by other user do not give any new measurements, indeed."

I didn't like stopping and starting the task since it took ages and used a lot of CPU power. It would be nice if there was a pause measurment function. I was in the same posistion with measuring the RPM of the motor. I was only interested in the current measurment, so I didn't care if the buffer overflowed. Also if the buffer overflowed, it would mean the motor was going very fast and I would more than enough samples to average.

"As I know the card buffer is limited to 2 samples and as I am interested only for the last 2 measurements, is there really no way to work without DAQmx buffer to overcome this error ?"

? I am only familar with E series counters, but with it I can select the number of samples in the buffer. But there are only 2 counters so you can only measure 2 PWM signals at once. Or you can use one counter to clock down the signals for the other counter. But for your 1kHz app you shouldn't need to do that.

Thanks for your help.

OK, but not sure if I have....

Nick

[Inpriser]

Hello Nick, and thank you for your reply,

I was using the PXI 6602 card for a couple of applications right now, but all were running on workstations with Windows OS. The problem of buffer overflow also occured on these systems if I did not take the precaution of using a digital filter on each counter. Now with a real-time controller the situation is even worse.

"Is it measuring the widths of the bounces OK, but producing an error when the counter overflows when the new switch state is stable? A 24 bit counter counting 80MHz clocks will overflow in 209ms. Can you divide down the clock to 20MHz?"

Actually, the overflow that is produced is not related to count overflow, but buffer overflow : semiperiod measurement actually stores tick count of each signal state, say an array of 4ms/6ms ticks for a 1kHz signal with 40% duty cycle.

So each time the input signal goes from one state to the other, it stores the counter value in the card FIFO.

I believe the problem is related to data transfer mechanism between the card and the controller. As the card has only 2 samples in its buffer, it request data transfer very often to put the data into the driver buffer, which is large enough to store thousands of measurements. Using DMA, it is "normally" fast enough to transfer measurement of a several kHz signal to central memory. But what happens if the counter needs to store new values while the card is being transferring these 2 samples ? Simply a buffer overflow that completely stops the measurement...

When I have a more important PXI bus traffic because I am doing other DAQ measurements in parallel, I guess that overflow may happen more easily, as the 6602 would have to share its resources.

I think this kind of measurement is really basic, but in practice I believe we cannot perform reliable buffered semiperiod measurements using NI timers as the task would stop suddenly in some situations.

I use a clean setup, but if someone wants to re-produce this phenomenon quickly, it is very easy : using a TBX68 for example, connect a wire on +5V and "touch" the GATE terminal of the timer with the other end of the wire. If no digital filter was set to the buffered semiperiod measurement task, you will see the error after a couple of tries.

Please note that I ask for counter measurements very often : roundabout every 10ms (the DAQmx read is run every 10ms)

Before having a look on other hardware solutions (FPGA...), it would be nice if some NI person could investigate this issue and ideally propose within DAQmx driver a mode to continue the measurement even if the system was not able to transfer all samples due to HW limitations.