Tags: attached, board, labview, mark, measure, pci-mio-16e-4, programming, proximity, rotor, rpm, screw, serve, timing, unbalance

How to measure rotor rpm's?

On Programmer » LabVIEW

6,538 words with 4 Comments; publish: Wed, 07 May 2008 01:10:00 GMT; (20063.48, « »)

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.

Thanks,

Rich

All Comments

Leave a comment...

  • 4 Comments
    • I suggest that you need to condition the signal from the sensor into the 16E

      4 board.

      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

      eysurprised:

      The picture is from a really old presentation (Credit - Doug Norman, Na

      utical Inclinations, Circa 1998) hope it helps.

      cntr-info.jpg:

      http://forums.ni.com/attachments/ni...1/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

      rotation frequency.)

      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.

      Nick

      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
    • 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

      problems.

      Thanks Again,

      Rich

      #4; Wed, 07 May 2008 01:14:00 GMT