daq 6024e + IR encoder

[tmdar]

Hi,
I am using IR sensor to calculate the rpm of my wheel-- my problem is when I am using "low freq with one counter" initially it gives me rpm but then as I increase the rpm it gives me message that "data was overwritten before it could be read try using DMA or divide the signal before measurement" now I can not divide the signal in this method I assume-- now when I change the counter to other method like "high range or large range with with 2 ctr" it tells me immediately your signal is too slow for this type of method and increase the measurement time-- I even did that increased the time to upto 50.0 but same problem
My Vi is attached -- How should I resolve this issue. As my wheel will move from rest and will gain some rpm and then stop-- so it will go from low to high to low.
Thanks

[gus]

I wanted to get some clarification on your range. So do you ever expect it to measure 0 Hz? How high do you expect the frequency to go?

gus....

[tmdar]

Hi,

As you know I am infact counting the number of stripes on disc which is attached to the wheel and my IR encoder is placed in front of wheel disc. So when wheel rotates my encoder counts black and white strips.

it counts from as slow as 1count per sec to 40 counts persec -- since VI is counting frequence so I believe 40 cps is maximum.

but as soon I increase rpm that is even from 4or5 counts persec to next step it displays message "data was overwritten before it could be read by the system"

I have to move robot from rest so zero count initially but it is like hitting button of simulation first and then making robot to move.
Now encoder is programmed through basic stamp micocontroller and I am picking up the signal from output of the encoder which is going into basic stamp aswelas into DAQ card. So I am counting in both programs in my VI and in basic stamp environment which gives me confirmation that I am counting correct.
My basic stamp continues counting as speed increases but labview generates error message.
I am counting upto maximum of 4o counts per sec or you can say 40 cycles per sec.
Thanks

[LYu]

Hi tmdar,

Using your program, I was definitely able to measure a frequency higher than 40 counts per second without encountering a buffer overflow error. This could be due to the system you're running the program with, or other applications you're running taking up system bandwidth. One thing you can try is setting a larger buffer such that less data transfers take place (see code attached). The measurement time input you mentioned is only applicable when counting high frequency with 2 counters (see Help file for more details).

Thanks,
Lesley Y.

[LYu]

Here's a screenshot of my measurement.

[tmdar]

Hi,
You are very much right, I have set the data sample in implicit vi and it has atleast started working and now it is stopping after I cross like 8/9 counts per sec. giving me rpm of around 200 rpm. but still I feel either it is malfunctioning due to my machine computer or since I am picking up signal from micro controller basic stamp 2 which is capturing data every 2 micro sec and lab view along with data is also picking up some noise.
I can see some noise very little in volage acq graph sample example vi.
I need to get rid of that which may be creatin trouble.
How to go for it use some low pass filter Vi.
Or what.
Thanks for the idea and help

[LYu]

Hi tmdar,

Were you able to see any changes upon changing the "samples per channel" parameter? You're right, it is possible that noise in the signal is being picked up as an event as well. Also, avoid running any unnecessary applcations on your computer while running this, or try running on a different machine to see if the results vary.

LabVIEW comes with a Filter Express VI (Express >> Analysis >> Filter) which you can experiment with to perform different types of filtering. However, since this filtering is performed after the data has been acquired, it may not help with the data acquisition issue. You may need an external filter. Before taking this step, you should verify if the problem is in fact signal noise. Since you're using one counter for "Low Frequency with 1 Counter", you can use the other counter to generate a pulse train, which you can feed as the input for your counting, to see if you can get up to a higher frequency. If this works, the problem is likely with the signal source. Otherwise, the issue would likely be the system or the code (please verify that you're using the shipping example, "Measure Dig Frequency - Low Freq 1 Ctr")

Thanks,
Lesley Y.