Counter buffer overflow error -200141

[NickNZ]

I am upgrading my software from Traditional DAQ to DAQ-mx. It the first time I am using DAQ-mx. I am having some problems with the counter on the 6024E DAQ Card dealing with the buffer overflow error -200141.

I am trying to measure the RPM of a motor using an optical encoder. It outputs 60 pluses per revolution.

When I wrote the software for Traditional DAQ a couple of years ago when I was still learning LabVIEW, I configured it so it did a buffered continuous period measurement, with a buffer size of 30,000 and the 20MHz Internal Time base.
I would read the counter as often as possible, using Read Buffer with number to read the greatest of 30 or the backlog from the previous read. This ran OK with minimal CPU usage. If the buffer overflowed (error -10920) the software ignored it and carried on. There was no need to stop the task and restart.

Since looking at upgrading the software to DAQmx I have decided it would be OK to measure speeds from 50 to 10,000 RPM. So I could divide the input signal by 4. I also only require an update every 100ms to be graphed for the UI.

I can get it to run, based on the sample code, but the buffer occasionally overflows (Error -200141) (usually when another task executes i.e. change the active window to another program). It also tends to overflow (depending on the method I use) when it is started while a motor is running at 4,500RPM. I don’t care if I lose a few samples.

I have tried Setting the Overwrite buffer to true.
After a Buffer overflow error I have also tried stopping the task and starting it again -no errors occur, but no samples are returned either… If I use the Clear Task and reconfigure the task it does return samples after a buffer overrun, but there is quite a bit of overhead to do this (15 - 30 ms).
I have also tried running Read in the data acquisition thread with a time critical priority.

For best performance I am not sure if I should use the timeout to timeout every 100ms and read all available samples, or specify a maximum number of samples to read, or just wire 0 to timeout so Read returns all available samples.

Unfortunately DMA is not available on the DAQ Cards.

Attached is the Meas Pulse Width-Buffered-Cont example I have modified. Also if someone could please post the original example it would be great as I modified the example and I don’t know how to restore it without reinstalling LabVIEW. One problem I have with the example is that it uses 100% CPU. I would like to swap between programs as another program controls the motor.

I have a 3GHz P4, WinXP, LabVIEW7.0 and NIDAQmx 7.1.0f1.

Since the traditional DAQ version runs on my computer with the DAQ Card OK I assummed that DAQmx would be able to do the job as well.

Any suggestions would be greatly appreciated.

Regards
Nicholas

[gus]

Hello Nicholas-

I haven't had a chance to verify the behavior you are seeing, but I thought I'd mention some other options that might work for you. In your traditional DAQ application you mentioned you were using period measurement rather than pulse width measurement and also that you only need to sample every 100 ms. You might try looking at one of the new period measurement examples that ships with DAQmx called "Meas Dig Periods-Buffered-Continuous-High Freq 2 Ctr.vi". This example measures period using both counters. You can read more about this method in DAQmx Help under "Key NI-DAQmx Concepts->Counters->High-Frequency Measurement Method". One of the benefits of using this programming method is that you don't have to return every single data point (which can also be a negative, depending on your application). With this method, you will receive one data point which is an average of the period on the interval specified by the "measurement time".

Additionally, you might consider using the 2 Ctr Large Range Method, which is described in "Key NI-DAQmx Concepts->Counters->Large-Range Measurement Method". This method uses a second counter to divide the signal being sent to the period measurement and then scales the resulting data accordingly. Though there is no period measurement example for this, there is a frequency measurement example that ships with NI-DAQmx. With this method, you can divide your signal by "divisor" amount and then measure the divided signal.

Let me know if you have any questions about this.
I hope this helps!
gus....

[NickNZ]

Hi Gus,

thanks for your suggestions. The problem with the 2 counters measuring (Meas Dig Periods-Buffered-Continuous-High Freq 2 Ctr.vi) is that at 50RPM I will get 50 pluses per second from the encoder -> 5 pulses per 100ms - plus minus a pulse I believe. So it is not very accuate! The external hardware I am using has a divide option so I have already tried dividing by 4.

Sorry I didn't notice my example had pulse width rather than period. I haven't worried about converting the data back to RPM until I can get it off the DAQ Card.

I still don't fully understand the hardware but I think the problem is that for each period there is an interrupt and if the CPU is busy it is missed and the next sample is measured and overflows the buffer. I don't mind if I lose one or two samples, but I would like the software to cleanly recover if it does happen. But the only way I have found to do this is to clear the task and re initalise the Counter - which is quite CPU intensive and takes around 15-30ms on my Laptop.

Regards
Nichaols

[LA 75]

Hello Nichaols,

I have seen that you were asking some questions and wondered if you have everything working now. If you have any further questions or if you are still getting the overflow error, please let me know and I will be happy to assist you.

Thank you,

LA

[NickNZ]

Hi LA,

No I still haven't sorted the buffer overflow problem... It got to to the point where I had tried everything I could think of so I think I may just stick to Traditional DAQ. Still I think it is weird that the buffer overflow error cannot be cleared without clearing the task and re-initialising the task, and that the ignore buffer overflow property seems to have no effect for the counter.

Regards
Nicholas

[LA 75]

Hello Nick,

Maybe NI-DAQmx does this on purpose to avoid buffer overflow from happening. Let me take a closer look to what you wanted to do and then I'll let you know what I find out.

Thanks,

LA

[Kevin_Price]

Nick,

I also encountered some non-intuitive behavior when setting up continuous acquisition under DAQmx. It does seem that the task disregards my attempt to set the property for ignoring buffer overwrite errors. I found a workaround for my app, where I only need to read the most recent samples on request and can afford to lose an arbitrary amount of data to overwrites between requests.

Immediately prior to calling DAQmx Read, I call the DAQmx Read Property node to setup the read position. I believe the settings I used are:
- relative to = most recent sample
- offset = (-1) * # of samples to be read

I do not know if that property setting is "sticky", i.e., will it be remembered for multiple calls to DAQmx Read? In my app, I may ask for varying amounts of data so I setup the read position before every read.

-Kevin P.

[NickNZ]

Kevin,

I tried your suggestion and it didn't work. Were you using a PCMCIA DAQCard?
Cheers
Nick

[Kevin_Price]

Nick,
No, sorry, I wasn't using a PCMCIA card. I've only been using PCI cards. (For anyone else reading this, my earlier suggestion has worked on an E-series MIO, and M-series MIO, and a 6602 counter/timer). When you say it "didn't work", what happened exactly? Can you post some sample code -- maybe someone can try it on a PCMCIA card?

-Kevin P.

[NickNZ]

Hi everyone thanks for your help.

Sorry about the delay but I decided to get something working with Traditional DAQ rather than DAQmx. Since I wrote the software with the intention of using DAQmx, it will be easy to upgrade the software later if a good solution to my counter problem is found.

So the challenge is to create in DAQmx a continuous period measurement of the RPM of a motor using an optical encoder (Or simulated RPM of a motor). The encoder outputs 60 pluses per revolution. Minimum RPM is 50RPM and maximum is 5000RPM (If it can go higher it’s good). I have a DAQCard so using DMA is not allowed!

I am aware that there are performance gains in dividing down the input signal. From my experience dividing by 4 is OK. (I have the option of making the encoder divide by 4 so I can just multiply the resulting RPM by 4.) However if the divisor is too big then the minimum measurable RPM increases.

Attached is my Traditional DAQ version that does the job OK. (It has no dividing down). Note with this you can change tasks (eg check email... etc) and it keeps on working. At higher speeds I don't care if I loose a few samples due to buffer overflows. Also note that I just ignore the buffer overflow error.

Also attached is my DAQmx attempt. The problem with DAQmx is that it does not continue taking measurements after the buffer has overflowed. You have to clear and reinitialise the task before continuing which as I said before has a big performance hit.

Regards
Nicholas