Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Counter/Timer Waveform

I would like to convert period measurements (RPM data) received from my counter/timer board into waveform data type so that I would be able to conduct frequency analysis on the data (e.g. FFT). Have tried with limited success interpolation & decimation techniques. Would be grateful for any suggestions.
0 Kudos
Message 1 of 7
(4,554 Views)
Sounds like you've got the right start. You're doing the right thing to interpolate a new dataset with samples that are equally spaced in time. What's the nature of your "limited success?"

Also, FYI, you definitely can get good results this way. I did something similar a few years back and got very good freq & amplitude correlation with the function generator I used to generate the modulated pulse train. Post back with the specifics that you're having trouble with and I'll help if I can.

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 7
(4,549 Views)
I am trying to make a virtual tachometer instrument using VI. I have attached a file regarding the physical setup for measuring the RPM of a rotating wheel. The PINS for my DAQ 6025E card is also attached. Can you help me by making a simple tachometer VI?
0 Kudos
Message 3 of 7
(4,544 Views)
Please find attached the VI used to interpolate the period measurements data. Works fairly well with high speed pulses. However, method fails when applied to slow speed pulses as truncation error in region becomes big multiple of counter timebase value.
0 Kudos
Message 4 of 7
(4,532 Views)
Malfesto,

I had a look and can offer up a few comments:

1. I don't understand your comment about "truncation error" in the slow speed pulses case. Perhaps your are remarking about the "glitches" in the slow data embedded in the block diagram array? More on this a bit later...

2. At least at a quick glance, the interpolation seems a little funky. I didn't spend a ton of time wrapping my head around it so maybe it's actually ok, but I saw a finite difference that would act like a derivative of the period, and a scaling factor based on the average period -- things that make me go hmmmm.
Also, if you zoom on the graphs for the Slow Data, you can kinda see that the "Post Processing Graph" looks like a derivative of the "Pre Processing Graph". I suspect you need to rework your interpolation method.

3. When I did a similar project, I think I first converted all the periods to frequencies and also generated a "sample time" array that was the cumulative sum of the periods. (I toyed with tweaking the time array so that the timestamp would correspond to the midpoint of the interval that I had converted to a frequency. I don't recall now whether that tweak proved useful enough to bother with).
Once I had laid out arrays for frequencies and (unequally-spaced) sample times for those frequencies, I could generate an equally-spaced time array at a desired "virtual sampling rate" and interpolate to create new "virtual frequency" values. Since I was merely post-processing data, I think I also used the native LabVIEW array functions 'Threshold 1D Array' and 'Interpolate 1D Array' in the interpolation process.
Now, before going into an FFT you'll want to remove the huge DC offset. This may be as simple as subtracting the mean or median frequency from all entries if you are nominally at constant speed.

4. Your raw dataset for Slow Data has suspiciously periodic glitches in the periods. There is a very strong and dominating pattern that repeats every 16 intervals. Your typical period is registering about 10 million timebase cycles. However, in every set of 16 periods, you get one period around 27 million and another around 35 million.
I don't know how you gathered your "Slow Data" values, but there seems to be a systemic error in the measurement. That sort of one-sample discrepancy looks very suspicious. I'd urge you to determine the source of those glitches and try to eliminate them. They don't appear to be telling the truth about the motion you wish to characterize. The device you measure doesn't by chance start and stop or go back-and-forth during your measurement, does it?

Hope this helps.

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 5 of 7
(4,524 Views)
I am trying to make a virtual tachometer instrument using VI. I have attached a file regarding the physical setup for measuring the RPM of a rotating wheel on an earlier post. The PINS for my DAQ 6025E card is also attached. Can you help me by making a simple tachometer VI?
0 Kudos
Message 6 of 7
(4,508 Views)
I have just made a simple tachometer VI. I have attached the file concerned. Can anyone give some comments to improve it?
0 Kudos
Message 7 of 7
(4,378 Views)