Tags: attached, board, labview, mark, measure, pci-mio-16e-4, programming, proximity, rotor, rpm, screw, serve, timing, unbalance
How to measure rotor rpm's?
I am using LabView 7 with a PCI-MIO-16E-4 board. I have a rotor with a
n unbalance screw attached to serve as a timing mark. I'm using proxim
ity probes (output voltage as a function of distance) to measure the distanc
e to the rotor. I nee
d this system to calculate the rpm's of the rotor. I fully understand
conceptually how to accomplish this but I need some help with LabView.
I tried searching LV examples and could not find anything. The output
signal would look somethin
g like a saw-tooth. I thought that maybe edge counting would work but
I wasn't sure considering that the signal is not a square wave. I also
was not sure about the physical connections to my SCB-68 junction box becau
se I've never done anything
with timing or frequency capture.
Any help or thoughtful suggestions would be greatly appreciated.
Leave a comment...
- 4 Comments
- I suggest that you need to condition the signal from the sensor into the 16E
To do this you need to limit the voltage from the proximity probe and then a
mplify it into a square wave (cause the amplifier gain to be very high or us
e a comparator, I have seen logic buffers used as amplifers; a bit amateuris
h if you ask me), if you ad
d a monostable function in the hardware set to the maximum shaft frequency y
ou will reduce false triggering from noise or other pick up issues. A f
ilter on the amplifier might be a good ideas as well, after all its only a c
ouple or resistors and capa
citors. The output from a magnetic proximity probe can be very high as
the shaft RPM increases and you can also get nasty spikes induced into the i
nput line. With the suggested configuration you measure the period of t
he signal, that is rising e
dge to rising edge. Watch the minimum distance setting for the sensor and be
aware of shaft run out as it might smash your sensor off at high speed.
The timer counter system is a really flexible system and the connection depe
nds on the way you want to do the measurement, in the suggestion above a fai
ly straightforward implementation is assumed i.e. one pulse measurement on d
emand rather than buffered.
The DAQ wizard takes you through configuring a counter system and also detai
ls the connection that you need. You should get the sticker that's provided
for the SCB68 with the connection details and stick it to the box (Take a co
py first so you can keep a
record of the connections you make). The connections are also in the PDF fil
e for the hardware card concerned and are available also on the web site if
you get stuck.
For a simple pulse width measurement you just need to connect the GATE
pin of the timer counter that you have decided to use. I think that mea
ns on an SCB68 for the PCI-MIO-16E-4 one of pins 10 (gate 0) or 41
(gate 1) or 5 (gate 3)&nbs
p;depending on the exact timer configuration you select (but you should chec
k the connections!!!). Don't forget to use the Digital ground connections 44
, 9, 7, 39, 4, 36 etc....
Connecting the sensor directly to the input would be realy a bad idea. :smil
The picture is from a really old presentation (Credit - Doug Norman, Na
utical Inclinations, Circa 1998) hope it helps.
cntr-info.jpg:#1; Wed, 07 May 2008 01:11:00 GMT
- Hi Rich,
I don't know much about your specific hardware, but I think I can help
you with the programming issues. How you might proceed will
probably depend on what hardware sample rate you have, and what
analysis rate you need to acheive with the software. There are
certainly many ways to accomplish what you want to do, and if you want
to analyze your rotor speed REALLY fast, you may want to consider some
other ideas... but here is what I would personally consider:
1) Sample your data as a discrete "burst." For instance take,
say, 25 voltage samples from your proximity detector over a period of
0.5 sec. (I'm just picking some numbers at random here. I
don't assume any values for your actual rotor speed. You'll
obviously have to sample the voltage at a rate of at least half your
2) Analyze the burst. Suppose your data is a simple 1-D array of
DBLs that are evenly spaced in time. In this case, you might use
some simple peak detection routine. I'm attaching a very simple
example for this (which I haven't tested). I chose the peak
detector function since it's simple and it'll work for any sort of
waveform (sine, sawtooth, square) as long as your peaks and troughs
have fairly consistent heights and depths over time.
3) Determine the frequency from the analysis of that burst. How
many peaks did you find? Over what time period? Now you
know your frequency.
4) Repeat. Take another burst.
I can think of all kinds of fancy variations. Maybe you could
consider a producer/consumer paradigm. Perhaps you have noisy
data and need to apply some sort of filtering before your peak
detector. But I suspect that what I've described above will more
or less do the trick for you.
Get number of peaks.vi:
http://forums.ni.com/attachments/ni/170/157200/1/Get number of peaks.vi#2; Wed, 07 May 2008 01:12:00 GMT
- Here you go now. Complete with a VI to test it. How cocky
am I getting that I think I don't have to debug my own code?
Sorry about that.
Get number of peaks.vi:
http://forums.ni.com/attachments/ni/170/157214/1/Get number of peaks.vi
Peak counter test.vi:
http://forums.ni.com/attachments/ni/170/157214/2/Peak counter test.vi#3; Wed, 07 May 2008 01:13:00 GMT
- Thanks for everybody's help. I will try out the various suggestions ov
er the next couple days. I may post other questions in case I run into
Rich#4; Wed, 07 May 2008 01:14:00 GMT