Dynamic Signal Acquisition

cancel
Showing results for 
Search instead for 
Did you mean: 

Order analysis: poor representation at speed fluctuations

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:

  • Highest frequenc to be measured: 1 kHz
  • Sample rate: 10kHz
  • # of Samples: 1k
  • Freqency resolution: 10 Hz

 

Thank you for your help.

 

Regards jenz

 

 

Download All
0 Kudos
Message 1 of 12
(8,031 Views)

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

 

 

Preston Johnson
Solutions Manager, Industrial IoT: Condition Monitoring and Predictive Analytics
cbt
512 431 2371
preston.johnson@cbtechinc
0 Kudos
Message 2 of 12
(8,020 Views)

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

0 Kudos
Message 3 of 12
(8,017 Views)

Are the two DAQs synchronized at the start?

0 Kudos
Message 4 of 12
(8,007 Views)

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

Preston Johnson
Solutions Manager, Industrial IoT: Condition Monitoring and Predictive Analytics
cbt
512 431 2371
preston.johnson@cbtechinc
0 Kudos
Message 5 of 12
(7,989 Views)

@ 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:

  • the offset correction
  • the transformation of the coordinate sytem of the raw data to the horizontal and vertical directions of the test setup
  • orbit presentation


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

0 Kudos
Message 6 of 12
(7,982 Views)

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.

0 Kudos
Message 7 of 12
(7,969 Views)

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

 

Preston Johnson
Solutions Manager, Industrial IoT: Condition Monitoring and Predictive Analytics
cbt
512 431 2371
preston.johnson@cbtechinc
0 Kudos
Message 8 of 12
(7,956 Views)

 

Unfortunately, I do not have a DSA device  Smiley Indifferent

0 Kudos
Message 9 of 12
(7,932 Views)

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

0 Kudos
Message 10 of 12
(7,714 Views)