Vibration analysis???

I would like to construct a rudimentary vibration analysis system.
The goal would be to find the angular postition of the "heavy
side" of a shaft rotating at ~2400rpm (40 rev/sec). Ideally, the
system should report where (and how much weight) needs to be
added to the shaft opposite the heavy side. Think of how a tire
shop "spin balances" your new tires...

I know such systems can be purchased; however I have more time
than money...

I know about accelerometers, how to condition them, interface
them to an ADC, and have a strong background in analog and digital 
electronics.

One option that I see is a purely analog solution, which uses
an optical pickup to provide a single pulse per shaft rotation as a 
reference, a PLL to get a clock locked to 50x or 100x the shaft
rotation rate, a switched-capacitor synchronous clock-tuned bandpass
filter to select only the fundamental of the accelerometer
signal, and then to use an oscilloscope to display the phase of
the filtered accelerometer signal relative to the optical pickup zero 
crossing. A refinement would be to use a scope with a polar display.

I am also looking for some algorithms to do this in DSP software.
I am familiar with writing code for the ADSP2189, TMS430, Cygnal8051,
various PICs and VisualBasic on PCs. I dont have a strong DSP 
background, so I am looking for suggestions of basic computation
based methods which would do this task.

At 40hz, I think it may be possible to implement this on a laptop,
using the laptop screen as a graphical or polar display. It is not
even necessary to update the display in real time, so postprocessing
a few revs worth of buffered ADCed accelerometer data may be
acceptable.

A stand-alone DSP chip driving an lcd or circle of leds display
would be a cadillac solution.

Looking for ideas.

MikeM

I suggest the use of an optical phase quadrature shaft encoder (e.g. HP or
sim.) to deduce shaft position.  This avoids the need for PLLs to
interpolate within a revolution.  The PQ encoder should drive a
parallel-readable up/down counter.

You can place the encoder inline on the existing shaft if the shaft dia. is
rite, or run a toothed rubber belt to an idler shaft with the encoder on
it.  Larger toothed wheels (1:1 ratio) will reduce the lumpiness of the
drive transfer function.

You can get resolutions up to several thousand points/revolution, but I
would assume that you are only looking for a degree or so.  I recommend a
power of two (512, 1024 etc.) so that simple AND masking can give the
position within the current revolution without tricky modulo 360 stuff.

Some encoder models have an optional zero detect output, which can be very
handy for setting accurate zero or other reference points.

If the CPU is quick enough, you could poll the up/down counter for each
count change and store the force sensor reading for that instant.

You will need a fairly fast (>= 100Ksps) ADC.  If it has a digital
anti-alias filter, you will need to allow for the time delay it introduces.

Due to the vagaries of bearing rattle etc., you may need to average the
measurements with the corresponding points from previous revolutions to
reduce noise.  A variable averaging time constant is very handy here to let
you get a stable reading or assess the bearings as desired.

With a bit of effort, you could make the display indicate the part of the
rotor which needs to be brought to the top for manual attention.

Interesting job.
Jim Adamthwaite

Jim Adamthwaite wrote:

> I suggest the use of an optical phase quadrature shaft encoder (e.g. HP or
> sim.) to deduce shaft position.  This avoids the need for PLLs to
> interpolate within a revolution.  The PQ encoder should drive a
> parallel-readable up/down counter.
> 
> You can place the encoder inline on the existing shaft if the shaft dia. is
> rite, or run a toothed rubber belt to an idler shaft with the encoder on
> it.  Larger toothed wheels (1:1 ratio) will reduce the lumpiness of the
> drive transfer function.
> 
> You can get resolutions up to several thousand points/revolution, but I
> would assume that you are only looking for a degree or so.  I recommend a
> power of two (512, 1024 etc.) so that simple AND masking can give the
> position within the current revolution without tricky modulo 360 stuff.

I would be happy with a resolution of between 1/50 to 1/128.

> Some encoder models have an optional zero detect output, which can be very
> handy for setting accurate zero or other reference points.

I am familiar with optical shaft angle encoders. I understand that it
would be convenient for the encoder to intrinsically generate the high 
frequency clock which is automatically phase locked to the shaft 
position.  However, I cannot mount an encoder on the shaft (no room).

About the best I could do is to place a piece of reflective tape on
the shaft, and use an optical pick up. I would only get one pulse per 
revolution, requiring the PLL to multiply the clock frequency by 50 to
128. The shaft speed changes relatively slowly, so the PLL should have
sufficient time to lock up, and then track shaft speed.

Alternatively, I could use the reflective tape to get an absolute index, 
and an existing periodic signal which happens either twice or thrice per 
shaft rotation to pump the PLL (thereby lowering its lockup time).


> If the CPU is quick enough, you could poll the up/down counter for each
> count change and store the force sensor reading for that instant.
> 
> You will need a fairly fast (>= 100Ksps) ADC.  If it has a digital
> anti-alias filter, you will need to allow for the time delay it introduces.
> 
> Due to the vagaries of bearing rattle etc., you may need to average the
> measurements with the corresponding points from previous revolutions to
> reduce noise.  A variable averaging time constant is very handy here to let
> you get a stable reading or assess the bearings as desired.

I understand that the accelerometer will see lots of higher harmonics. 
The off center mass that I am trying to detect will be at the shaft 
rotation rate. If I can use the PLL to get a suitable high freq clock, 
then it can clock a high-Q bandpass filter tuned to the fundamental, and 
the PLL clock will also sample the ADC. The high Q bandpass should act
as an anti-alias filter for the ADC.

> With a bit of effort, you could make the display indicate the part of the
> rotor which needs to be brought to the top for manual attention.

That is the goal...

MikeM

mikem wrote:

   ...

> I am familiar with optical shaft angle encoders. I understand that it
> would be convenient for the encoder to intrinsically generate the high 
> frequency clock which is automatically phase locked to the shaft 
> position.  However, I cannot mount an encoder on the shaft (no room).

   ...

I don't know how much room you need. Some encoders are very small. PLLs
suitable for your application are very hard to build. The low speed of
your shaft makes lock-up slower, not simpler. Lock-up typically takes a
certain number of pulses, not time. At one pulse per revolution and low
speed, don't expect rapid lock-up.

If you plot the difference of actual frequency and when first locked up,
decaying to a sawtooth. The sawtooth is the result of the frequency
drifting away between synchronizing pulses, then snapping back. If you
turn your shaft with a synchronous motor and adjust the oscillator's
free-running frequency to be exact, you can use the PLL yo adjust phase
without suffering from the sawtooth.

The machine you propose can achieve static balance, that is, the rotor
will be in neutral equilibrium. To achieve vibration-free rotation, you
need dynamic balance, which aligns the axis of rotation with an axis of
maximum or minimum moment of inertia. In practice, that is achieved by
separately balancing each end of the shaft.

Since the out-of-balance condition is sensed inertially, sensitivity is
proportional to the square of the speed. That is why low-speed balancers
are harder to build than high-speed ones. I expect that you will need a
dedicated computer (i.e., one without Windows of Linux) to make even
your low-speed balancer work. I suggest that you cram a few numbers onto
the back of an envelope to see how much latency and angular inaccuracy
you can tolerate.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:

> If you plot the difference of actual frequency and when first locked up,
> decaying to a sawtooth. The sawtooth is the result of the frequency
> drifting away between synchronizing pulses, then snapping back. If you
> turn your shaft with a synchronous motor and adjust the oscillator's
> free-running frequency to be exact, you can use the PLL yo adjust phase
> without suffering from the sawtooth.

Something got lost. The paragraph should read

If you plot the difference between the correct frequency and the actual
frequency when first locked up, it will oscillate, decaying to a
sawtooth. The sawtooth is the result of the frequency drifting away
between synchronizing pulses, then snapping back. If you turn your shaft
with a synchronous motor and adjust the oscillator's free-running
frequency to be exact, you can use the PLL to adjust phase without
suffering from the sawtooth.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins wrote:

> I don't know how much room you need. Some encoders are very small. 

The application requires temporary connection to different aircraft.
I dont have access to the end(s) of the crankshaft, so a rotary encoder
wont work.

> PLLs
> suitable for your application are very hard to build. The low speed of
> your shaft makes lock-up slower, not simpler. Lock-up typically takes a
> certain number of pulses, not time. At one pulse per revolution and low
> speed, don't expect rapid lock-up.
> 
> If you plot the difference of actual frequency and when first locked up,
> decaying to a sawtooth. The sawtooth is the result of the frequency
> drifting away between synchronizing pulses, then snapping back. If you
> turn your shaft with a synchronous motor and adjust the oscillator's
> free-running frequency to be exact, you can use the PLL yo adjust phase
> without suffering from the sawtooth.

I was afraid that an analog PLL might take many revolutions to lock up.
Since I know that the expected RPM will be between 2200 and 2500 during
a static runup, the vco only has to tune about 12% of its center freq.
Since the engine always accelerates from idle to the test rpm, the 
unlocked vco could be preset to 2200rpm (37Hz) so that the engine
goes thru that range on its way up to the actual test rpm...

> The machine you propose can achieve static balance, that is, the rotor
> will be in neutral equilibrium. To achieve vibration-free rotation, you
> need dynamic balance, which aligns the axis of rotation with an axis of
> maximum or minimum moment of inertia. In practice, that is achieved by
> separately balancing each end of the shaft.

With a propeller bolted onto one end of the crankshaft of the
engine, the only improvement I can make is in the static balance.
I do not have access to the opposite end of the crankshaft, so
the only place that a mass can be added is at the propeller end.
The means to achieve static balance is to add a bolt and washers
to the propeller spinner backing plate (on the lighter side).

> Since the out-of-balance condition is sensed inertially, sensitivity is
> proportional to the square of the speed. That is why low-speed balancers
> are harder to build than high-speed ones. 

Unfortunately the RPM achievable during a static ground run is about
80-90% of the in-flight cruise RPM, so the balance has to be achieved
there. Since the prop is 84" long and weighs about 35lbs, the
vibration caused by an unbalanced prop should be readily detectable
even at ~40Hz.

> I expect that you will need a
> dedicated computer (i.e., one without Windows of Linux) to make even
> your low-speed balancer work. I suggest that you cram a few numbers onto
> the back of an envelope to see how much latency and angular inaccuracy
> you can tolerate.

Yes, I am an expert on trying to do real time control tasks using PCs.
I have found that booting a modern PC into DOS, and then diddling with
interupts gives fairly good timing resolution.

MikeM

Jerry Avins wrote:

> Jerry Avins wrote:
> 
>> If you plot the difference of actual frequency and when first locked up,
>> decaying to a sawtooth. The sawtooth is the result of the frequency
>> drifting away between synchronizing pulses, then snapping back. If you
>> turn your shaft with a synchronous motor and adjust the oscillator's
>> free-running frequency to be exact, you can use the PLL yo adjust phase
>> without suffering from the sawtooth.
> 
> 
> Something got lost. The paragraph should read
> 
> If you plot the difference between the correct frequency and the actual
> frequency when first locked up, it will oscillate, decaying to a
> sawtooth. The sawtooth is the result of the frequency drifting away
> between synchronizing pulses, then snapping back. If you turn your shaft
> with a synchronous motor and adjust the oscillator's free-running
> frequency to be exact, you can use the PLL to adjust phase without
> suffering from the sawtooth.
> 
> Jerry

If you're implementing your PLL in software you should be able to get it 
to lock very quickly -- even after the fact.  If you implement a 
time-varying loop filter you could latch onto the shaft speed in the 
first rotation, then quickly settle out to the noise-limited performance 
of the PLL.

Alternately you could take a nice big data sample then determine the 
rotational phase, rate and acceleration after the fact.  With the 
reference in hand you could go back over your accelerometer data to 
determine the vibration.  This approach has the advantage that only the 
ADC collection needs to be real-time; you could make or buy a card with 
ADC, uP and memory, and keep the PC application running in Windows or Linux.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim Wescott wrote:

   ...

> If you're implementing your PLL in software you should be able to get it 
> to lock very quickly -- even after the fact.  If you implement a 
> time-varying loop filter you could latch onto the shaft speed in the 
> first rotation, then quickly settle out to the noise-limited performance 
> of the PLL.
> 
> Alternately you could take a nice big data sample then determine the 
> rotational phase, rate and acceleration after the fact.  With the 
> reference in hand you could go back over your accelerometer data to 
> determine the vibration.  This approach has the advantage that only the 
> ADC collection needs to be real-time; you could make or buy a card with 
> ADC, uP and memory, and keep the PC application running in Windows or 
> Linux.

That's well adapted to the task; it has structural beauty. Thanks.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

mikem wrote:

   ...

> Yes, I am an expert on trying to do real time control tasks using PCs.
> I have found that booting a modern PC into DOS, and then diddling with
> interupts gives fairly good timing resolution.

I wrote a small program that can turn off DOS's time-of-day clock
interrupt to remove the timing uncertainty that it creates, and resets
the clock from the CMOS when exiting. Do you want it? Email me if you
do. I too have done real-time work with DOS. (My address above is real.)

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Tim Wescott wrote:

> Alternately you could take a nice big data sample then determine the 
> rotational phase, rate and acceleration after the fact.  With the 
> reference in hand you could go back over your accelerometer data to 
> determine the vibration.  This approach has the advantage that only the 
> ADC collection needs to be real-time; you could make or buy a card with 
> ADC, uP and memory, and keep the PC application running in Windows or 
> Linux.

Tim,

are you saying (in effect) that I can sample the accelerometer at
a fixed rate which is not synchronous with the shaft rotation
(provided that I get a few hundred samples during one shaft
rotation) and still compute where the heavy spot is after the
fact?

I would also need a pulse per each revolution on a separate
(digital) channel to use as an angular postional reference?

MikeM