Has anyone experience using the maximum time waveform peak as one of the analysis parameter sets?
Most of us have used the normal analysis parameter sets with their corresponding alarm limit sets (like overall, < 1xn, 1xn, 2xn... 8xn-60xn,etc plus noise), which to my understanding are all based in the spectra information. But not many use information (except for the patterns, maximum amplitudes and perhaps crest factor) from the time waveform data in a way that it is trendable.
The idea is that the maximum time waveform peak provides trendable information that can be compared to alarm limits defined for them to complement the information for the other alarm limit sets.
It is clear the alarm limits should vary depending on different factors like machine speed, maximum frequencies involved (considering the presence of gear mesh frequencies, etc), perhaps also machine power.
I know there are many alarm limit specifications based on different standards (like ISO) but also most of them are linked to the spectra information.
In case anyone knows alarm limit standards, or have tried with good results others based in their own experience, which can be applied in the set-up of alarm limit sets for the maximum time waveform peak please share your experience or knowledge.

CSI has some limits for peakvue TWF true peak (equivalent to acceleration TWF true peak if the sampling frequency is high eoug) which apply in cases where you know that the peak is a result of a bearing fault. Depends on which race and the machine speed. Discussion here:

http://www.compsys.com/drknow/aplpapr.nsf/06b6f5a4de2ea...050d1e7?OpenDocument

Roughly speaking for the speed range 900rpm-3600rpm (most of my equipment), their true pk/pk accel TWF alert level is 3g's for inner race defect, 6'gs for outer race defect. Double those for alarm limit. I'm not sure if they mention limit for cage or ball defect.

This is a general guide and they point out that of course trending and other factors should be considered as well.

My thought is if you reach their alarm limit you have pretty good assurance that you will see visible damage on the bearing (and not be embarassed by calling a bearing which later appears to be good when disassembled). How much longer before failure is a different question which has been batted around a lot on the forums.

Some other discussion of this parameter - limits and significance of was here:
http://maintenanceforums.com/eve/forums/a/tpc/f/375...011/m/4651006802/p/2

This message has been edited. Last edited by: electricpete,

Hi electricpete,
Thanks for your input, it made me remember I had printed last year another paper also from James Robinson presented with James Berry from Technical Associates of Charlotte during the 2001 Emerson Reliability Conference (Description of peakvue and illustration of its wide array of applications in fault detection and problem severity assessment).
Both papers are excellent and apparently do not differ much.
We don't use peakvue in our normal collection route mode, but in the analyze mode when we want to confirm something that perhaps the normal spectra and time waveforms did not show clearly to address a change.
I will have to go back and read the section in which they are making recommendations for alarm limits and alarm parameter sets to be able to trend (time to study again!!). I am not sure if the guidelines can be extrapolated for a special time waveform (not peakvue) but your idea of using double the G peak to peak may be a good approach.

quote:

I am not sure if the guidelines can be extrapolated for a special time waveform (not peakvue)

Demodulation processes do not signficantly change the peak compared to the TWF they started with. Peakvue as I understand it also somehow retains the true peak based on hardware sample rate. Regular accel TWF peak will be slightly lower than peakvue TWF peak if the sample rate isn't high enough. Any error can be fixed by increasing the sample rate for the accel TWF. For trending purposes pick a high enough sample rate and stick with it. Or else if you want to use a lower sample rate on routes for trending against historical data or for minimizing storage requirements, you might apply a correction factor to their limit to account for the lower sample rate.

This message has been edited. Last edited by: electricpete,