Go
New
Find
Notify
Tools
Reply
  
3-star Rating (1 Vote) Rate It!  Login/Join 
Posted
Question would you use 75% overlapping on an online monitoring system on a large complex gearbox 400 hp 1200 rpm input, 280 rpm double output shafts? If yes why? If no why?
Somewhere in my training i was told Overlapping was only usefull for speeding up data collection. I was told on complex machines such as this gearbox that you could miss much information because of the overlapping process. Is this true or false.
 
Posts: 3 | Location: Texas | Registered: 22 February 2005Reply With QuoteEdit or Delete MessageReport This Post
Posted Hide Post
Hi Wendell, I decided to check my book on this one since it has come up before, here is Ron Eshleman's take on the subject
quote:
Overlap averaging permits the use of a percentage of data from the most recent block of data. Since computational time is a fraction of data acquisition time, this speeds up the data processing time and permits more averaging in a given period of time. Computational time has very little effect of total data acquistion time during overlap averaging, data sampling time is calculated as follows....(table shows calculation which I assume you're familiar with)


Personally, I have online monitoring which is real time live data, I don't overlap, I capture blocks and store them on regular intervals or on alarm. My route based collection is usually 4 averages with 30% overlap, and works quite well.


ensing-dot-ron-at-irvingtissue-dot-ca
 
Posts: 446 | Location: Great White North | Registered: 21 February 2005Reply With QuoteEdit or Delete MessageReport This Post
Posted Hide Post
Wendell,
I would agree with Vibbase. With your online system there should be no need to overlap. If it is continually collecting you do not need to reuse 75% of the previous data.
 
Posts: 25 | Location: Greensboro, NC, USA | Registered: 21 February 2005Reply With QuoteEdit or Delete MessageReport This Post
Posted Hide Post
Wendell,

I'm surprised more people have not jumped in on this with their opinions. I'll go ahead and share mine. I think overlap does provide some advantages when using portable data collectors. In fact, I probably would use that as one of those determining factors in the purchase of a data collector. If it did not have that feature available I would probably rule it out as a potential purchase. I suspect they all have that feature available now, anyway.

An argument can be made that there is a greater benefit to overlap processing (OP)than simply speeding up data acquisition time. The argument I speak of, I think, is about equally countered by a small potential for less accurate data. So the argument for using OP with portable data collectors still boils down to speed in data collection, which is a valid consideration and I would definitely use OP with most machines in route data collection.

With on-line systems the benefit of speeding up data collection is not nearly as apparent, but it may still be a factor. When dealing with on-line systems people should quit thinking in terms of portable data collector data acquisition. However, speed of data collection may still be an issue, depending on how your on-line system works. Many people who are unfamiliar with online systems think that all online systems continuously measuring vibration data from all the channels on the system. That is true on only a few systems that are out there today. Most online systems process data on only one channel at a time. Depending on how many channels a system is set up with and the sample rates used and averaging used, it may take a an online system more than 24 hours to cycle through all the channels and store a spectrum for each channel on the system! Most people would expect better performance than that from an online system and if your system is one of these "multiplexed" or "scanning" systems, OP could help reduce the time between stored spectra in your data base.

Other online systems sample data simultaneously from all channels and are looking at a continuous stream of digitized data from each channel, and can actually be configured to not miss a millisecond of data from any channel! When using this type system you may even consider eliminating averaging, depending on the application. Of course, if you are not averaging you cannot setup OP.

If your on-line system signal processor is limited to about sixteen channels on the single gearbox you described (and perhaps a motor), even with a "scanning" type of system you probably get data from each channel quick enough to not benefit much from OP.

Skip Hartman
 
Posts: 41 | Location: Louisa, Virginia, USA | Registered: 23 February 2005Reply With QuoteEdit or Delete MessageReport This Post
Posted Hide Post
Wendy,
The other reason for overlapping is due to the window weighting process ie Hanning etc so a certain amount of a data block is effectively weighted out. You can more effectively use this information at the start and end of each window by using overlapping. I would not reccommend greater than 65%.
 
Posts: 38 | Location: Auckland, New Zealand | Registered: 23 February 2005Reply With QuoteEdit or Delete MessageReport This Post
Posted Hide Post
Thank you for your input, I am curious what could i miss by using 75% overlap on a complex machine like this? Could i miss a gear defect? Could i cause me to miss a bearing fault. At some time in my career i was led to believe that the use of overlap was basicly a benifiet for speed of collection but that by using this feature you could miss some of the data, such as a transient event of say a tooth defect on a gear?
 
Posts: 3 | Location: Texas | Registered: 22 February 2005Reply With QuoteEdit or Delete MessageReport This Post
Posted Hide Post
quote:
I am curious what could i miss by using 75% overlap on a complex machine like this? Could i miss a gear defect? Could i cause me to miss a bearing fault.


Well, don't use 75% overlap it's too much. Gear defects show up best in the time domain which should be real time for an online system (or close if sampled regularly)Bearing defects will still show up because they are usually high frequency and repetitive with harmonics.


ensing-dot-ron-at-irvingtissue-dot-ca
 
Posts: 446 | Location: Great White North | Registered: 21 February 2005Reply With QuoteEdit or Delete MessageReport This Post
Posted Hide Post
Wendell,

I don't believe you need to be concerned about Overlap Processing causing you to miss an event like a bearing defect or a gear tooth defect. In fact, the effect it has actually may enhance your ability to see these things. As Bruce points out, the Hanning Window that we typically use for vibration analysis, intentionally suppresses the amplitude at the beginning and end of each time block used in the FFT process. This can slightly reduce the amplitude shown in the spectrum for a fault frequency. Since the Overalp Process results in data that is at the end of one time block being shifted to near the middle of the next time block (where there is no suppression) a significant impact amplitude in the waveform may now be "re-emphasized" in the resulting averaged spectrum.

Also, if the availability of Overlap Processing allows you to configure your spectral data for higher resolution you gain in two ways. First, the obvious more precise determination of frequency that you get with high resolution. Second, the lower noise floor resulting from the higher resolution spectral data, which can cause a low amplitude spectral peak to standout from the noise floor so you can see it, where it might have been missed for the noise in a lower resolution spectrum.

If you have a system where the stored waveform you have to analyze is based strictly on what is required to provide the spectrum you defined, the choice of highe resolution will also provide a longer waveform for you to examine, which may reveal something interesting.

The multiplicity of frequencies, remote locations of bearings and gears, process variations that cause noise, and mass dampening all conspire to reduce the amplitude of impulses reaching a sensor on gearboxes like we are disussing. This means that anything that effectively reduces the noise floor of the data acquisition system and reduces the tendency of Hanning to supress the amplitude of a spike in the data should be a benefit.

But, I do agree with vibbase. You can have too much of a good thing. 50% is generally accepted as being effective without totally eliminating the statistical benefits of averaging. I would try to stick with about 50% overlap.

Skip Hartman
 
Posts: 41 | Location: Louisa, Virginia, USA | Registered: 23 February 2005Reply With QuoteEdit or Delete MessageReport This Post
Posted Hide Post
There are some other considerations when using overlap processing.

As others have stated it does reduce collection time and it limits the loss of accuracy of data within each bin or time block when a Hanning window is applied. 50% overlap limits this loss of accuracy to -16.5%.

Why? Because of the window shape which forces the data to zero at the beginning and end of the block. If the frequency of interest is half a bin off then the accuracy is down by 3dB.

In the case of the Hanning window function the result is taht it causes a ripple effect (picket fence) of the data. It has been found that 66% overlap is the optimum to limit the ripple effect.

Is this really necessary? Probably not in most cases. If one uses diligence in setting up the collection point and maintains sufficient bin separation to provide adequate spectral resolution then 50% is probably the best choice.

You loose data accuracy when your resolution is too course, not by overlapping too much.

I have cases where I used this methodology on radar acutator gear boxes where there were three sets of gear reduction prior to the final stage which was an epicyclic gear set. The speeds were around 9000 rpm in and 58 rpm out. It was a blind test of 6 units of which 2 were bad.

 
Posts: 95 | Location: Tennessee | Registered: 21 February 2005Reply With QuoteEdit or Delete MessageReport This Post
 Previous Topic | Next Topic powered by eve community  
 


Copyright © 2004-2008 NetexpressUSA Inc. All rights reserved.