Unfortunately, most of the "interesting" stuff will be down inside those various special-purpose toolkit vi's. You mentioned Sound & Vibration, but I see a bunch of "O.A.T." icons that I suspect relate to the Order Analysis toolkit.
I don't have either one, nor do I have any familiarity with those functions. I'm also not at all experienced in the seemingly specialized field of monitoring vibrations on rotating machinery and performing order analysis. I just have excellent knowledge of counters under DAQmx, rudimentary knowledge of frequency domain analysis, and beginner-level knowledge of producing a 3D waterfall graph (to map out a 2D spectral response through slices of time).
Maybe someone else that knows the field and the DAQ hardware will join in and give more detailed help?
Meanwhile, here are a few thoughts based on fundamentals.
- Is the rotational speed nearly constant? Then the vibration data alone would probably allow you to generate a useful waterfall graph. Not *perfect*, but at least useful.
- If the speed is nearly constant, it seems like you could do a very simple speed measurement with the counter task, and use that nominal speed to scale your frequency domain data from Hz to unitless "order numbers".
- Several challenges arise if the counter measurements are meant to compensate for significant changes in rotational speed during your measurements. I expect those toolkit vi's do a nice job of handling all this stuff for you.
If I had to deal with this, I would resample the vibration data to make it equally spaced in *rotation angle* rather than in time. I would use a quadrature encoder and configure an angle measurement task. I would export the DSA device's sample clock and use it as the sample clock for my encoder task. I would then be able to capture vibration vs. time and angular position vs. time. In post-processing, I could resample to figure out vibration vs. angular position. (It would probably be necessary to compensate for the signal path delay of the DSA device during this post-processing.)
So now I could have a pseudo-waveform where the "dt" value is really a "delta position". For order analysis, I imagine I'd use "# rotations" as the position unit to feed into the "dt" field of the waveform. From there, I would split up all this measurement data into slices that each contain some integer # of rotations worth of data. I'd do freq domain spectral analysis on each slice, accumulate all the results, and display them in a 3D Waterfall Graph.
It seems to me that this kind of approach ought to be a decent starting point at least.
Now after all that, let me try to answer a couple specific questions.
Counters are very flexible. One can often exchange which counter input receives which signal in order to approach a measurement differently. In your example, the encoder signal is being treated like a sample clock. You'll take one sample at each tooth. So the question is, *what* are you sampling? Well, you're sampling a count value. The count value is being incremented at 20 MHz. The effect you get is to capture a *timestamp* of the instant when each tooth first registered its presence. This is just another way to get a relationship between time and position. This one captures counts at equal angles while measuring the variable time between them. Other methods capture counts at equal time spacing while measuring the variable distance between them.
The sample rate input value to DAQmx Timing should be set to the max expected encoder frequency. The main (maybe only?) reason is that DAQmx uses the sample rate value to auto-size its task buffer. (And please consider my Idea Exchange post here if you agree that it would be helpful if the DAQmx API made some of this stuff more clear).
-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.
