09-02-2010 07:58 AM
Dear all,
In our company we do shaft motion tests at turbochargers. One part of it is performing order analysis and there lies my problem.
Please take a look at picture 1 and 2. They show the speed curves and the corresponding waterfall-diagramms. The difference in the pictures is the type of speed rise.
Picture 1:
The speed rise is evenly and the representation of the 1 EO (Exciting Order) is very straight and linear.
Picture 2:
The speed rise until maximum speed is very unevenly. The speed goes up and down bewteen 20000 ... 25000 RPM. In result of it the representation of the 1 EO is very poor.
Do you know how to avoid such poor representation despite changes in speed?
Parameters used:
Thank you for your help.
Regards jenz
09-02-2010 08:30 AM
Thanks for the post Jenz.
One item that can cause jitter in the order analysis, is when the data stream to the order analysis VIs is not continious. If the data acquisition is starting and stopping, then the speed and order anslysis reset themselves. On slow changing speeds, you may not notice this.
On the order analysis VIs, (Not the express VIs), you can improve the analytical results by selecting the accurate (as compared to fast) selection.
Is your block diagram small enough to share?
Preston
09-02-2010 08:41 AM
Hi Preston,
I analyze the signals offline. But online I have the same problem, so I think it is a data aqusition problem.
Best Regards Jenz
09-02-2010 09:49 AM
Are the two DAQs synchronized at the start?
09-02-2010 02:54 PM
thanks for the block diagram images. I like your producer consumer loop.
It appears that you are only writing the output of the orbit analysis to file and only writing the results to file when there is some change in speed. Is this correct?
I would consider writing a good size time waveform from the vibration signals say perhaps 10 seconds in each record.
Are you using the NI Sound and Vibration Tools for order analysis inside your VIs?
Preston
09-03-2010 02:26 AM
@ Ian Ren
I use a PXI-Chassis 1033 with a NI-6122. The speed signals is recorded by a counter (edge counting) and the vibration signal is recorded by two analog inputs.
I'm not sure whether I need an additional synchronization between the counter and the vibration signals (?). At present the counter and the analog inputs use the same 20 MHz Timebase and starts at the same time.
Do you think something is wrong?
@ Preston
(1) Yes, I only write the output of the orbit analysis VI to file.
It includes:
Do you think there is too much to calculate and therefore delay in writing the data to the file? Please take a look to the block diagramm.
(2) Yes, I begin first writing data if the calculated speed value is > 0.
The speed calculation after the edge counting delivers a speed value at 400 RPM. At this point I have already vibration signals. So I avoid a time misalignment.
(3) No, at present I do not use NI Sound and Vibration Tools but I have the software. The reason is, that I can not provide real signals to test the software and my DAQ-Hardware.
(4) What do you mean with "writing a good size time waveform from the vibration signals say perhaps 10 seconds in each record"?
Jens
09-03-2010 08:05 AM
Just from the waterfall, it appears there is a time offset between the analog signals and the speed (counter) signal, the speed (counter) DAQ starts later than the analog DAQ.
09-03-2010 09:43 AM
I would encourage you to study the Sound and Vibration Examples, in particular the Order Tracking Magnitude and Phase (Digital Tacho, DAQmx). This has a configuration VI that syncrhonizes the DSA device and the counter timer device, using the oversample clock of the DSA device. If you do not have real world signals, you can use a function generator with a square wave for the timer and an analog waveform for vibration.
Hope this helps.
Preston
09-06-2010 01:28 AM
Unfortunately, I do not have a DSA device
10-04-2010 11:19 AM
From looking at your block diagram, it looks like you are using the same timebase and sample rate, but that does not guarantee synchronization. The tasks are not started at the exact same time, but started some time 'close' that is dependent on how fast the software executes the two start task operations.
What I would suggest would be to syncronize the two tasks by sharing a clock from the AI task to the CTR task. Maybe the AI sample clock.
-Alan