Dec-2015

When it surges, it shakes

Why is elevated vibration during surge often absent from the data collected by the online vibration monitoring software?

Shun Yoshida and Serge Staroselsky, Compressor Controls Corp.
Steve Sabin, SETPOINT ™ Vibration

Article Summary

Surge and rotating stall in centrifugal and axial compressors are well-understood aerodynamic phenomena, documented in literature. The mechanical vibration, both radial and axial, that occurs during surge and rotating stall has likewise been documented. Depending on where vibration sensors are mounted, and the compressor stage at which stall/surge may be occurring, it is usually possible to observe a simultaneous rise in vibration. For example, 14 separate surge tests conducted across seven separate compressor trains showed a 100% correlation between vibration and surge, observed by almost every vibration sensor on the machine (Table 1).

Yet if vibration can often be such a good precursor or corroborator of surge, why is it often missing in action when the vibration condition monitoring software is consulted following a real or suspected surge event? To understand why this happens, and what can be done to remedy it, we must first look at how vibration data collection is triggered in most online systems today.

Online systems, by design, do not store everything. If they did, even a modest number of vibration sensors would incur terabytes of data storage per month. A reasonable rule of thumb for mechanical vibration is that it uses approximately the same sample rates and bandwidth as the audible spectrum for high-fidelity sound. Consider that a 1 hour audio CD consumes approximately 600MB for two channels (stereo), and extrapolate to one month (720 hours). To record one month of stereo audio, approximately 400 GB is required. This is roughly the same as a single X-Y pair of vibration sensors would require. As even a modest compressor train has a dozen or more vibration sensors, the implications of storing everything and moving it over the network infrastructures available in a typical industrial plant render it impractical.

In addition to these physical limitations, there are also practical considerations. Out of a typical 720 hours in a month, bona-fide machinery problems manifesting as abnormal vibration patterns may occur for only several minutes, if at all. Thus, the ratio of interesting data to uninteresting data is usually exceedingly small. Sifting through 720 hours of vibration data to find the blip of interest can be daunting.

To deal with these issues, the most commonly encountered systems in the field for continuous vibration condition monitoring established three basic modes of dynamic (i.e., waveform) data collection:
Delta-Time (∆t): Data collected at evenly-spaced, preset time intervals
Delta-RPM (∆RPM): Data collected at evenly-spaced, preset rpm intervals, as the machine was started or stopped
Alarm Buffer: Data collected before, during, and after a time window surrounding an alarm (usually, hardware alarms rather than software alarms). The data window is typically 10 minutes before an alarm and 1-2 minutes after an alarm at moderate resolution, and only the immediate 30 seconds preceding an alarm at high resolution.

So-called static data (amplitude, phase, gap or bias voltage, and so on) is generally collected more frequently than dynamic data, but still adheres to the above three regimes. These systems have evolved little since their inception in terms of the way they recognise and trigger the collection of interesting data.

Delta-time collection
This mode collects data at evenly spaced time intervals as shown in Figure 1. Its primary purpose is to establish trends with sufficient resolution such that slowly developing changes can be seen. The intervals shown are for illustration purposes only. Actual ∆t intervals are not usually in seconds (20 minutes to 2 hours are typical). Only a minimal set of attributes relating to the data are stored, such as maximum amplitude, minimum amplitude, and average amplitude during the time interval.

Alarm event collection
This method relies on a rolling buffer. It maintains a relatively high-resolution record of the last 10 minutes of vibration data. When no alarms occur, the oldest data is continuously overwritten by the new data. When an alarm occurs, the data in this buffer is frozen and saved, much as one might capture an intruder on surveillance camera by sensing when glass breaks on the front door and reviewing the video footage leading up to, during, and several minutes after the glass breakage. Vibration systems work in similar fashion by waiting for a hardware alarm to occur from excessive vibration and saving approximately ten minutes of data leading up to the alarm, at the moment of alarm, and approximately two minutes after the alarm (Figure 2).

However, there are several ways that data can fail to be captured. Most users only configure hardware alarms due to the tedium involved in tailoring software settings for each vibration point and parameter. Two levels of hardware alarms (high and high-high) are typically present, but are typically set conservatively in order to not trip machine trains based on small changes in vibration. It is not unusual for vibration levels in normal operation to be only 10% of alarm levels, such as a compressor set to alarm at 4 mils and trip at 5 mils of radial vibration, but running normally at 0.5 mils. In such a case, vibration amplitudes would need to increase by a factor of 8 for an alert and a factor of 10 for a trip, either of which would trigger a hardware alarm and freeze the corresponding alarm buffer.

Many vibration events do not incur sufficient change to trigger a hardware alarm. Surge-related vibration often falls into this category: significant enough to be of interest, but not of sufficient amplitude to trigger a hardware alarm or machine trip.

Another factor contributing to missed data is that although surge-related vibration often manifests as pronounced axial vibration rather than solely radial vibration, the thrust bearing monitoring on most machines is set to recognise only gross axial position changes, not axial vibration. Axial position monitors contain filtering that ignores the axial vibration component and responds only to the average axial position.

The alarm buffer method, therefore, often provides no useful data in a surge event because no relevant hardware alarms have been triggered. Trends may show elevated vibration levels, but waveform data is missing (the very data needed to distinguish surge-related vibration from other sources with similar characteristics and sub-synchronous frequency content such as axial and radial rubs, oil whirl, oil whip, and anything that causes re-excitation of the first balance resonance.

Delta-RPM collection
This mode collects data at preset rpm intervals. For example, the user may configure the system to collect a waveform (dynamic data) at 100 rpm intervals during a startup. For a machine running at 6000 rpm, a total of 60 waveforms would be collected during a startup. Static data is often collected at a 10:1 ratio, or in this case, once every 10 RPMs. Thus transient data is collected at relatively high resolution and when a surge-related event occurs during a startup or coast-down on machines for which ∆RPM data capture has been configured, it is usually caught.

Unfortunately, the times when surge is most often of interest are not during transient run-up or run-down conditions, but during steady-state speed operation when other process changes are occurring. These changes can lead to surge and may not be fully characterised in the surge control algorithm, which is the time when supplemental vibration data to confirm a surge event can be most beneficial.