Frequency acquisition yielding inconsistent results

[Ralph@NES]

Hello all.

I'm using a PCI-6602's counters to measure frequency from three separate places on a bearing test rig.  Two are the bearing cage, one is the shaft.

The sensors I'm using are magnetic/prox in nature and are reading two magnets on each cage at about 180hz and one screw on the shaft at about 190hz.

I'm taking the frequency and multiplying it by either 30 or 60 to attain an RPM reading.

With a handheld digital tach, we have verified that the shaft is holding steady speed within 3-4 RPM, however my RPM readings are fluctuating by what seems to be the multiplier I'm using.  Almost as if the system's period of count isn't consistent and it's adding or subtracting a pulse from the frequency.

Can someone look at this simple VI and recommend what I could do to filter or 'average' the count so that it's steady rather than fluctuating so much?  I've tried the 'filter' express VI to no avail, I can't get it to even start to work.  Maybe a different approach in the DAQ assistant and timing?

Thanks in advance.

Message Edited by Ralph@NES on 08-21-2007 12:32 PM

[johnsold]

It is not unusual to have a +/-1 count fluctuation due to the fact that the signal being counted and the timebase are not synchronized. Another possibility is that your signals have some noise which results in spurious counts. Have you looked at the signals with an oscilloscope?

Lynn

[Ralph@NES]

No scope handy so I haven't been able to.  I think the problem is that I'm measuring a small period of time as 'frequency' and then multiplying it by an amount to get RPM so the error is magnified.

Is there any way to extend that measurement period so that my multiplier can be smaller?

[johnsold]

Extending the measurement time will improve the resolution at the expense of longer intervals between readings. You, or your customer, need to determine what is best for that.

Period measurement is another approach. If you measure the period of each cycle (~5.5 ms), you may be able to average several readings to get smoothed results. With a sliding window averager you could update after each pulse.

How often do you need updates? How much fluctuation can your system tolerate?

Lynn

[Ralph@NES]

I need an accurate RPM calculation roughly once every 5-10 seconds.  Not really a strenuous timeframe.  I'm more than willing to extend the measurement period in order to get a more uniform reading.

[johnsold]

The DAQ Assistant is not availble on my platform, so I cannot comment on your code or how you might be able to modify it. Perhaps you could configure it to count for 0.5 seconds and average 10 or 20 counts before updating the display.

Lynn

[Ralph@NES]

I did a DAQ assistant to count for .9999-1.0001 seconds to acquire 'period' data.  I'm getting a number out of it, but unsure what that number is and how to average it and convert it to an RPM measurement.

Message Edited by Ralph@NES on 08-21-2007 02:17 PM

[Ralph@NES]

I modified it so that I'm taking 20 samples at 499-501msec.  Dividing 60 and 30 (depending on whether it was the cage at two pulses per rev or shaft at one pulse per rev) by this number and getting what appears to be a valid RPM, although my fluctuations are the same or very similar as before.  Is there some kind of filtering that I need to do?  What am I missing here?

[johnsold]

I need a picture or an updated VI. I am not sure what you mean when you say you are taking 20 samples .. and then dividing by "this number." Twenty samples should be twenty numbers. What is the "this number?" My suggestion was to average the twenty numbers. I would expect the fluctuations to be much smaller than the fluctuations from sample to sample.

To get more frequent updates while maintaining the smoothing effects you could use a moving window averager.

Lynn

[Alex A.]

Lynn is on the right track.  I too don't fully understand your reason for dividing.  Please update with a VI or screenshot.