LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem measuring RPM using USB 6229 at higher frequencies

Hello everyone... i am using USB 6229 to measure RPM using PFI 9 pin (ctr 0). i am using a low frequency counter (as given in the example Meas Dig Freq-Low Freq 1Ctr.vi)...

I am taking frequency input with 1 pulse per rotation.

 

the problem i face is weird...

i get reliable data up to 800 rpm (800/60 = 13.33Hz) , however, if i go above it... i observe rpms up to 5000 - 6000 even when the actual rpm is approximately 2000-2500 (2000/60= 33.33Hz ) which was measured using TACHO.

 

can anyone please help me?

 

thanks

Now on LabVIEW 10.0 on Win7
0 Kudos
Message 1 of 15
(2,709 Views)

My guess would be that the sampling rate is set too low, resulting in aliasing. Aliasing is when your data isn't sampled at at least 2X the data rate.

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 2 of 15
(2,700 Views)

so, that means i have to change the clock rate on the sample clock?? if aliasing wuold be an issue, how can it reliably detect up to 700 rpm?

Now on LabVIEW 10.0 on Win7
0 Kudos
Message 3 of 15
(2,686 Views)

You have said that you are getting reliable data up to 800 RPM, so 700 should be ok. Since 800RPM = 13.33Hz, if you mean 7000 RPM then I would say you have to sample at a clock rate of at least 240 S/sec.

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 4 of 15
(2,680 Views)

i am sorry.. its 800 RPM and not 700 RPM. sorry! 

Now on LabVIEW 10.0 on Win7
0 Kudos
Message 5 of 15
(2,673 Views)

I guess I don't understand then, your first post says you are measuring reliably up to 800RPM. You do have it set up for low frequency, and since, as you point out 800RPM corresponds to 13.33.... Hz, the sampling rate must be >26Hz to avoid aliasing problems.

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 6 of 15
(2,669 Views)

It might help you to feed in values to the min and max value inputs to set the lower and upper bounds of the sampling rate. Those would be frequency values corresponding to the highest RPM and lowest. The problem you have, accuracy wise, is that your sampling window has to be long enough for the lower frequency, and the clock rate has to be high enough for the higher frequency.

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 7 of 15
(2,664 Views)

ok... vl try that, what i observed was when my source of RPM(pump) was fluctuating; the readings seemed to be wayward. --By wayward , i mean showing 5000-6000 or odd RPMs

when the source of RPM(a variable speed DC Motor) was not fluctuating, the readings seemed to be bang on target. 

 

Could it be a possibility that there would be a modulation being created because of the fluctations? 

 

 

Now on LabVIEW 10.0 on Win7
0 Kudos
Message 8 of 15
(2,640 Views)

You have a DC motor driving a pump. You are measuring the RPM of the pump and it appears to be varying? You have a means to measure the RPM of both the motor and the pump and that is what is leading you to determine the fluctuation of the pump's RPM? How much "fluctuation" are you getting, we still could have the case of the high end RPM being above what the Niquist number (sampling at 2X the data variation rate).

Putnam
Certified LabVIEW Developer

Senior Test Engineer North Shore Technology, Inc.
Currently using LV 2012-LabVIEW 2018, RT8.5


LabVIEW Champion



0 Kudos
Message 9 of 15
(2,629 Views)

I had a similar problem once and it was actually the sensor, the RPM sensor on the shaft was vibrating on the shaft at higher frequencies causing multiple pluses per rev.  A tach had digital filtering so it was not noted on the tach module.  I spent hours trying to find the "Bug" in the code when it was a mechanical (poor shaft slignment on the axel) the whole time.  Just a different view if the code/counter is functioning correctly.

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
Message 10 of 15
(2,620 Views)