Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

USB-9233 Vibration Measurement

Hi all,

Looking for some help, primarily with units I believe.  I own a USB-9233 and there aren't too many posts on it, nor am I by any means an expert with vibration terminology or theory.

I have an application where I need to take the output of an accelerometer, and after the data capture, display the highest inch/second reading.  I'm not sure what the value is thats coming off the accelerometer?  I assume its just a voltage, but how to convert that to in/sec?

I do have the sound and vibration toolkit, and I'm able to display the waveform of the output.  But how to get that specific value?

Any help would be greatly appreciated.
LV7.1, LV8.5, LV2014/15/16
0 Kudos
Message 1 of 6
(2,994 Views)
There are many posts with the 9233 module in the Dynamic Signal Analysis forum. 
 
With the Sound and VIbration toolkit, you will first want to use the scale to engineering units function.  This will take the calibration data you have from your sensor, say 100mv/g and will scale the voltage coming from the DAQmx functions to acceleration.  To get the data to inches per second, you will want to use the sound and vibration toolkit function called integration.  This will integrate under the accleration trace to produce a velocity trace.  You can do a max/min of your velocity trace to get the maximum velocity in the run. 
 
Hope this helps.
Preston Johnson
Solutions Manager, Industrial IoT: Condition Monitoring and Predictive Analytics
cbt
512 431 2371
preston.johnson@cbtechinc
0 Kudos
Message 2 of 6
(2,985 Views)
Thanks for the help preston, sorry for the delay in response - was out of town for a few days.

The procedure makes sense, but after getting some more information about how our current system works, I wonder if it requires any changes.

I was told this is the current procedure for how we acquire our vibration level:

Sensor outputs electrical voltage -> combined with the scaling factor we get an acceleration curve -> integral of that curve gives velocity (as you mentioned!) -> here's where it changes though - I was told that once we have this waveform, we take the peak to peak value at every cycle. and plot that value.  By plotting that value we produce a sort-of linear plot composed of these peak to peak values.  This is a plot we need to keep.  Then next to get that in/sec value we average all of those peak to peak values and thats our overall vibration value.

Does that sound correct?  I've implemented up to the point that you metioned with a single channel. (Added 3 channels in the DAQ assist, but for some reason when I use the split signal function I can't split each one to perform the rest of the manipulations.  Velocity curve works though for 1 channel....
LV7.1, LV8.5, LV2014/15/16
0 Kudos
Message 3 of 6
(2,963 Views)

Hello Leachdor,

It sounds like your calculation is different from Preston's in that yours is an average max/min where as his is strictly the max/min.  It is really up to you whether or not you want to average or not.  If you're looking for the "overall vibration value" the average is probably more representative than the max/min.

If you're performing the same analysis on all for channels then it’s likely that you don't need to split the signals as many VI's are able to automatically adapt to multiple channels.  If you find that some of the analysis VI's you're using do require a single signal input then you should be able to use the split signals VI to split the signals.  In order to do this you'll need to put a Split Signals VI on the block diagram and then expand the VI to have 4 outputs by hovering your mouse over the bottom edge of the VI.  Once you're hovering there you can click and drag the lower edge of the VI to expand the number of output.

I hope this helps, and if you still have trouble with this feel free to post back with more questions.

Cheers,

Brooks
0 Kudos
Message 4 of 6
(2,941 Views)
Thanks brook,

I found out why it wasn't letting me use the split signals as I mentioned and you referred to....apparently I pulled down as you mentioned also, but according to the phone support guy at NI, that function is buggy when it comes to dragging.  In my instance, I had to drag "up" for all channels to appear...dragging down only left the one output channel, where dragging up the same function provided all 3.  Not sure if thats isolated to LV8.5 but he was able to recreate it and sent a bug claim or something in to R&D.

It is odd though, I was able to get a reference sensor to check if my calculations were correct.  Running the test once, I was able to get a very close value, within a few thousands.  All the rest of the values though come up pretty far off, so I'm guessing that one was just a fluke?  It looks like between the two, I'm getting about a 16% difference.  I'm going to post my code....maybe someone see's where the problem is?


LV7.1, LV8.5, LV2014/15/16
0 Kudos
Message 5 of 6
(2,917 Views)

Hello Leachdor,

 

It is difficult to diagnose why the results vary, but here is how I would approach it.  I would assume that if you pass the same data set to the analysis VIs then you'll always get the same values.  That means that if your result is different than your input signals aren't always the same.  I would recommend using some graph indicators on your VI to view the signals at each stage of your VI to make sure they're what you expect.  If you have some very low frequency vibrations it’s also possible that phase discontinuities are playing a role, but this will be apparent in the graph indicators.

 

Also, are you saying the same reference sensor read the same value every time (within a few thousandths of the expected value), and that you have another sensor that reads 16% off?  Or are you saying that the reference sensor read within a few thousandths the first time and about 16% off in subsequent runs?

 

In either case I would recommend looking at the input signals in both cases as this is likely the source of the resulting disparity.  Once you know what the difference is between the signals it will be easier to diagnose the problem or modify your analysis to account for the difference in your signals.

 

Cheers,

Brooks
0 Kudos
Message 6 of 6
(2,891 Views)