Processing Machinery Protection and Fault Prediction Data Natively in a Distributed Control System

[0001] This application claims priority to co-pending provisional patent application Ser. No. 62/029,606, filed Jul. 28, 2014, titled “Methods and Apparatus for Integral Vibration Input and Output Card with Process Control System.”

[0002] This invention relates to the field of machine control and machine condition monitoring. More particularly, this invention relates to a system for integrating a machine vibration data acquisition and analysis module directly into a distributed control system architecture as a native data input device.

[0003] In prior machinery control and machinery vibration monitoring systems, the numerical data produced by a machinery vibration monitoring system had to be integrated with data produced by a machinery control system using intermediate communication protocols to bridge the systems together, such as under the OPC standard or Modbus or Profibus (process field bus). Using the traditional integration process, common communication protocols, protocol configuration, data networking, data synchronization, and the manual mapping of data were required. Testing and troubleshooting was required to verify the correct operation of the combined system.

[0004] In traditional machinery protection applications, binary relay outputs representing machine alarm states or trip states and analog 4-20 mA current loop outputs from a vibration monitor were used as hard-wired inputs to a distributed control system (DCS) for trip initiation and vibration values.

[0005] In traditional vibration monitoring systems, the trip levels and alarms were configured and displayed by the vibration monitoring systems separately from the control system configuration and display software. Vibration data was available to the control system only if the system integration methods described above were implemented to acquire the vibration data from the vibration monitoring system.

[0006] Therefore, what is needed is a system for making numerical data produced by a machinery vibration monitoring system available to a machinery control system without having to use intermediate communication protocols to bridge the systems together.

[0007] Embodiments of the present invention provide a vibration data acquisition and analysis module that is operable to be inserted directly into a DCS I/O backplane, so that processed vibration parameters may be scanned directly by the DCS I/O controller. Because the process data and the vibration data are both being scanned by the same DCS I/O controller, there is no need to integrate numerical data, binary relay outputs, and analog overall vibration level outputs from a separate vibration monitoring system into the process control system. Further advantages of embodiments of the invention include: (1) direct acquisition of vibration data by the control system for purposes of machinery protection and predictive machinery health analysis; (2) direct integration of vibration information on DCS alarm screens; (3) acquisition and display of real time vibration data on operator screens; (4) the ability to utilize vibration data for detection of abnormal situations associated with equipment failures; and (5) the ability to utilize vibration data directly in closed-loop control applications.

[0008] Machinery Protection/Prediction Native in DCS

[0009] Some embodiments of the invention provide a vibration data acquisition system that collects and processes machinery protection data and machinery prediction data in a software format that is native to the DCS. As the term is used herein, software is “native” to a platform if it is designed to run on that platform, where the platform may be an operating system or a device, such as a DCS controller. The system includes vibration modules that calculate scalar overall vibration parameters from vibration waveforms in a DCS machinery health monitor module. These scalar overall values are preferably calculated using parallel digital signal processing in a field card Field Programmable Gate Array (FPGA). These processed scalar vibration values are transmitted to the DCS I/O controller via the conventional DCS serial I/O bus.

[0010] The scalar vibration values are scanned and processed by logic routines (referred to herein as “control sheets”) that run at a deterministic rate in the DCS controller. The output of the control sheet logic is preferably transmitted to DCS output modules to perform machine shutdown or other control functions. In various embodiments, control sheets may be optimized for maximum protection (more stringent machine protection) or maximum availability (relaxed protection to minimize nuisance or false trip events).

[0011] Preferred embodiments of the invention provide the ability to transfer time waveform data from the vibration data acquisition system, such as via Ethernet, and view the waveform data on a machine health management analysis computer. Some embodiments also provide for moving blocks of time waveform data on the DCS I/O bus. In these embodiments, the time waveform block data may be transferred to the DCS controller via the DCS serial I/O bus backplane using DCS Remote Desktop Protocol (RDP).

[0012] Separation of Protection and Prediction

[0013] Preferred embodiments of the invention also provide for separation of machinery protection functions from machinery prediction functions. In particular, prediction data acquisition and processing does not interfere with protection data acquisition and processing because the two data streams are processed through separate, independent data paths in the signal processing FPGA. Also, preferred embodiments implement separate physical ports for protection data and prediction data. Prediction data is accessed by Machine Health Management (MHM) software via a dedicated Ethernet port that can be disabled by the DCS configuration software. Protection data is transmitted to the DCS controller via the DCS I/O backplane or is made available via a separate dedicated Ethernet port. Further, prediction components cannot “write” to protection components, and separate configuration and data storage is provided.

[0014] In preferred embodiments, all protection hardware configuration functions are handled by DCS software only, although MHM prediction software may access the protection configuration data to determine sensor and measurement configuration.

[0015] Further, MHM prediction software can control only the prediction time waveform. Although the prediction software can read protection overall values, the prediction software cannot affect the configuration of the overall level measurements used for protection functions. Also in preferred embodiments, the prediction tasks run at lower priority in the pre-emptive multitasking real-time operating system (RTOS).

[0016] Preferably, there are separate software hosts that consume the protection and prediction data. A DCS software host processes the protection data, while an MHM software host processes the prediction data.

[0017] One embodiment of the invention is directed to a machinery health monitoring (MHM) module that processes machine vibration data based on vibration signals and provides the machine vibration data to a distributed control system (DCS). The machinery health monitoring module includes signal conditioning circuitry, processing circuitry, and logic generator circuitry. The signal conditioning circuitry has an interface for receiving analog vibration signals from sensors attached to a machine, amplification and filter circuitry for conditioning the analog vibration signals, and analog-to-digital conversion circuitry for converting the analog vibration signals into digital vibration signals. The processing circuitry includes multiple parallel digital signal processing channels. Each channel processes a corresponding one of the digital vibration signals to generate multiple scalar vibration values per channel and at least one vibration time waveform per channel. The logic generator circuitry receives the multiple scalar vibration values and the vibration time waveform, and formats them according to an input/output data protocol that is native to the DCS.

[0018] In some embodiments, the logic generator circuitry includes a backplane interface that is configured to electrically and mechanically connect to and disconnect from an input/output bus of the DCS. In these embodiments, the multiple scalar vibration values are communicated through the backplane interface and the input/output bus of the DCS using the input/output data protocol that is native to the DCS.

[0019] In some embodiments, the logic generator circuitry includes a first network communication interface that is independent of the backplane interface. The first network communication interface communicates the vibration time waveform via a communication network to a machine health management data analysis computer for machine health prediction processing.

[0020] In some embodiments, the logic generator circuitry includes a second network communication interface that is independent of the backplane interface. The second network communication interface is operable to communicate the vibration time waveform via a communication network to a DCS operator computer for machine protection processing.

[0021] In preferred embodiments, the first and second network communication interfaces are Ethernet interface ports.

[0022] In some embodiments, the logic generator circuitry communicates the vibration time waveform in data blocks through the backplane interface and the input/output bus of the DCS using a block data transfer protocol.

[0023] In some embodiments, the multiple parallel digital processing channels of the processing circuitry include a first channel for processing a vibration time waveform for use in machine health prediction processing, and a second channel for processing a vibration time waveform for use in machine protection processing. The processing performed in the second channel is preferably independent from processing performed in the first channel.

[0024] Another embodiment of the invention is directed to a DCS that includes an input/output bus, one or more MHM modules, one or more DCS input modules, a DCS controller, and one or more distributed control system output modules. The input/output bus transfers data according to a data communication protocol that is native to the DCS. Each MHM module includes signal conditioning circuitry, processing circuitry, and logic generator circuitry as described above. The DCS input modules receive sensor signals from process sensors attached to a machine, generate scalar process values based on the sensor signals, and provide the scalar process values to the input/output bus. The process sensors include sensors other than vibration sensors. The DCS controller includes interface circuitry and logic circuitry. The interface circuitry scans the input/output bus at a predetermined rate to receive the scalar vibration values and the scalar process values. The logic circuitry executes control logic routines that generate control signals based on logical processing of one or more of the scalar vibration values, one or more of the scalar process values, or a combination of scalar vibration values and scalar process values. The DCS output modules receive the control signals from the input/output bus and generate machine operation output signals based on the control signals.

[0025] In some embodiments, the logic circuitry of the DCS controller executes the control logic routines and generates the control signals at the same predetermined rate at which the interface circuitry scans the scalar vibration values and the scalar process values from the input/output bus.

[0026] In some embodiments, the DCS input modules generate temperature scalar values, pressure scalar values, flow rate scalar values, and speed scalar values.

[0027] In some embodiments, each MHM module generates scalar vibration values that include an RMS value, a peak value, a peak-to-peak value, a DC value, an absolute +/−peak value, and a PeakVue value.

[0028] In some embodiments, the logic circuitry of the DCS controller selectively executes logic control routines (also referred to herein as control sheets) that are optimized for different purposes. Some logic control routines are optimized for maximum machine protection using first trip threshold levels. Other logic control routines that are optimized for maximum machine availability using second trip threshold levels that are higher than the first trip threshold levels.

[0029] In another aspect, an embodiment of the invention provides a method for processing data in a DCS. The data is based on sensor signals generated by sensors attached to one or more machines that are under control of the DCS. The method includes:

• • [0030] (a) receiving analog vibration signals from sensors attached to the one or more machines;
  • [0031] (b) converting the analog vibration signals into digital vibration signals;
  • [0032] (c) simultaneously processing the digital vibration signals in multiple parallel digital signal processing channels, where the processing includes:
    • [0033] (c1) processing the digital vibration signals in one or more of the parallel digital signal processing channels that are dedicated to machine health prediction processing only; and
    • [0034] (c2) processing digital vibration signals in one or more of the parallel digital signal processing channels that are dedicated to machine health protection processing only,
    • [0035] wherein the digital signal processing channels that are dedicated to machine health prediction processing are separate from and independent of the digital signal processing channels that are dedicated to machine health protection processing;
  • [0036] (d) generating machine operation output signals based on the machine health protection processing;
  • [0037] (e) generating machine performance signals based on the machine health prediction processing;
  • [0038] (f) using the machine operation output signals in the DCS to shut down one or more of the machines to avoid damage; and
  • [0039] (g) using the machine performance signals to observe trends in machine performance or to predict how much longer one or more of the machines can operate before being taken offline for maintenance or replacement.

[0040] In some embodiments, the processing steps (c1) and (c2) are performed in separate and independent parallel channels of a field programmable gate array (FPGA).

[0041] In some embodiments, the processing step (c1) cannot affect the processing step (c2).

[0042] In some embodiments, data associated with the processing step (c1) are stored in first memory locations, and data associated with the processing step (c2) are stored in second memory locations, and the second memory locations can be read by the processing step (c1) but cannot be written to by the processing step (c1).

[0043] In some embodiments, the processing step (c1) has a lower priority than the processing step (c2) in a real-time operating system that controls task priority in the DCS.

[0044] In some embodiments, step (f) includes providing the machine operation output signals to the distributed control system via an input/output bus, and step (g) includes providing the machine performance signals to a machine health management data analysis computer via a network communication interface that is independent of the input/output bus. In some embodiments, the method includes generating control signals in the DCS to selectively disable the network communication interface.

[0049] Embodiments of the present invention provide a vibration data acquisition and analysis module that interfaces directly to a distributed control system I/O backplane to allow direct acquisition of vibration data by the DCS for purposes of machinery protection and predictive machinery health analysis. As the term is used herein, a “distributed control system (DCS)” is a type of automated control system used in a process or plant in which control elements are distributed throughout a machine or multiple machines to provide operational instructions to different parts of the machine(s). As the term is used herein, “protection” refers to using data collected from one or more sensors (vibration, temperature, pressure, etc.) to shut down a machine in situations in which severe and costly damage may occur if the machine is allowed to continue running “Prediction” on the other hand refers to using data collected from one or more vibration sensors, perhaps in combination with data from other types of sensors, to observe trends in machine performance and predict how much longer a machine can operate before it should be taken offline for maintenance or replacement.

[0050] FIG. 1 depicts a machinery health monitoring module (MHM) 10 that directly interfaces with a DCS 11. In the preferred embodiment, the module 10 includes a field analog signal conditioning and sensor power card 12 that receives and conditions sensor signals, a field digital FPGA signal processing card 14 that processes the sensor signals, and a DCS logic generator card (LGC) 16 that provides an interface to a DCS I/O bus 18. The field card 12 can preferably accept input from up to eight measurement sensors 20 through a field signal interface connector 22. In a preferred embodiment, two of the sensor input channels may be configured as tachometer channels.

[0051] Preferably, galvanic electrical isolation is provided between the analog field card 12 and the digital field card 14. This electrical isolation prevents unintentional current flow, such as due to ground loops, between the mounting locations of the sensors 20 and the DCS 11.

[0052] Sensor power 24 and signal conditioning circuits 26 can support a wide range of sensors 20, including piezo accelerometers, piezo ICP velocity, piezo dynamic pressure, electro-dynamic velocity, eddy current displacement, AC vibration, and DC displacement. Tachometer sensors that are supported include eddy current displacement sensors, passive electro-magnetic sensors, Hall Effect tachometer sensors, N pulse/rev shaft encoders, and TTL pulse sensors. Many additional sensor types are supported over the frequency range of DC to 20 KHz as long as they fall within the following exemplary voltage input ranges: 0 to +24V, −24V to +24V, −12V to +12V, and 0 to −24V. In the preferred embodiment, up to eight sensor power circuits 24 can be individually programmed for a constant current of between 0 and 20 mA, which may also be used as lift current for an electro-dynamic (passive) velocity sensor. Constant voltage sources (+24VDC or −24VDC) may be selected as well as constant current. The input voltage ranges listed above are also individually programmable on each sensor channel. This permits any mix of sensor power and input range configuration between the channels, thereby enabling a mix of supported sensors.

[0053] With timing provided by a clock 26, an 8-channel analog-to-digital converter (ADC) 28 converts the eight analog signals into a single serial data stream comprising eight simultaneously sampled interleaved channels of data. In some preferred embodiments, two tachometer triggering circuits 30 convert the two analog tachometer signals into tachometer pulses.

[0054] On the field card 14 is an 8-channel field programmable gate array (FPGA) 36 for processing the vibration data. The FPGA 36 receives the 8-channel digital waveform data and 2-channel tachometer data and processes the raw data in parallel to generate scalar overall vibration parameters and waveforms. The processed waveforms may include low-pass filtered, PeakVue™, order tracking, high-pass filtered (DC blocked), and selectable single-integrated (velocity), double-integrated (displacement), or non-integrated (acceleration) waveforms. Prediction data channels also preferably include an up-sampling data block to provide higher resolution data for Time Synchronous Averaging (TSA) or order tracking applications.

[0055] The vibration card configuration circuit 32 of the analog field card 12 preferably includes of a set of serial-to-parallel latch registers that accept a serial data stream of configuration data from the application firmware of the LGC 16. This data is loaded into a parallel-to-serial shift register in the interface of the FPGA 36. The FPGA 36 then handles shifting the serial data to the control latches using a synchronous SPI format.

[0056] During operation of the preferred embodiment, the MHM module 10 appears to the DCS controller 19 as a multichannel analog input card having scalar outputs similar to those of a standard DCS input module 21, such as may be outputting measured temperature, pressure, or valve position values. As discussed in more detail hereinafter, vibration signals are converted to scalar values by the module 10 and presented to the DCS controller 19 via the backplane of the DCS. One example of a DCS controller 19 is the Ovation™ controller manufactured by Emerson Process Management (a division of Emerson Electric Co.). In the typical DCS architecture, only sixteen scalar values are presented as high speed scan values to the DCS controller 19. In a high speed scan, the DCS controller 19 can read these sixteen scalar values at up to a 10 mS rate.

[0057] Time waveform block data (and some scalar values) may be transferred to the DCS controller 19 via the DCS I/O bus 18 using a block data transfer method, such as Remote Desktop Protocol (RDP), at a rate that is lower than the scan rate of the sixteen scalar values.

[0058] As the scalar values generated by the machinery health monitoring module 10 are read by the DCS controller 19, they are processed by software running in the DCS controller 19 in the same manner as any other DCS data. One primary function of the DCS controller 19 is to compare the scalar values with alarm limits. If the limits are exceeded, alarms are generated. Logic within the DCS controller 19 may also determine whether any actions should be taken based on alarm conditions, such as closing a relay. Operations including alarm relay logic, voting, and time delays are also performed in software by the DCS controller 19. Preferably, DCS control outputs, such as relay outputs and 4-20 mA proportional outputs, are driven by standard output modules 23 of the DCS. Bulk prediction data is formatted in the LGC host processor 48 and is transmitted via an Ethernet port 52a to a machine health management (MHM) analysis computer 54 for detailed analysis and display. Bulk protection data is also formatted in the LGC host processor 48, but is transmitted via a separate Ethernet port 52b to the DCS operator computer 60.

[0059] In preferred embodiments, a DCS operator computer 60 includes an interface for displaying vibration parameters and other machine operational data (pressures, temperatures, speeds, alarm conditions, etc.) that are output from the DCS controller 19.

[0060] A functional block diagram of a single channel of the field digital FPGA 36 is depicted in FIG. 2. A preferred embodiment includes seven additional channels having the same layout as the one channel depicted in FIG. 2. As described in more detail hereinafter, the channel digital waveform data may be routed through a variety of digital filters and integration stages before being converted to vibration overall values or packaged as “bulk” time waveforms for further analysis by software running on the LGC card 16 or for transmission to DCS software or MHM software.

[0061] As shown in FIG. 2, an ADC interface 70 receives the eight channels of continuous, simultaneously sampled data from the ADC 28 of the field analog card 12 through the connector 34 (shown in FIG. 1). The data is preferably in the form of a multiplexed synchronous serial data stream in Serial Peripheral Interface (SPI) format. The ADC interface 70 de-multiplexes the data stream into eight separate channel data streams.

[0062] Although all eight channels could be used for vibration signal processing, in a preferred embodiment two of the eight channels may be used for tachometer measurement processing. Each tachometer measurement channel preferably includes:

• • [0063] a one-shot 110, which is a programmable trigger “blanking” function that provides noise rejection for tachometer pulse trains having excessive jitter or noise;
  • [0064] a divide-by-N 111, which is a programmable pulse divider that divides pulse rates of tachometer signals produced by gears or code wheels;
  • [0065] a reverse rotation detector 112 that determines the direction of shaft rotation by comparing the phase of two tachometer pulse signals;
  • [0066] an RPM indicator 115 that calculates the RPM of the tachometer pulse stream as a scalar overall value.
  • [0067] a zero-speed detector 113 that provides a “zero speed” indication when the tachometer has been inactive for a programmable interval, such as 0.1 s, 1 s, 10 s, or 100 s; and
  • [0068] an over-speed detector 114 that provides an “over speed” indication when the tachometer exceeds a fixed 2 KHz or 62 KHz threshold. In alternative embodiments, this threshold may be programmable.

[0069] With continued reference to FIG. 2, each of the eight independent parallel channels of signal processing in the FPGA 36 preferably includes the following components:

• • [0070] a high pass filter 72 for DC blocking, which is preferably be set to 0.01 Hz, 0.1 Hz, 1 Hz, or 10 Hz, and which may be selected or bypassed for the integrators described below based on the position of a switch 74;
  • [0071] two stages of digital waveform integration, including a first integrator 76 and a second integrator 78, which provide for data unit conversion from acceleration to velocity, acceleration to displacement, or velocity to displacement;
  • [0072] a digital tracking band pass filter 82 having a band pass center frequency that is set by the tachometer frequency or multiples of the tachometer frequency, and that receives as input either the “normal” data stream (no integration), the single integration data stream, or the double integration data stream based on the position of a switch 80, as described in more detail below; and
  • [0073] scalar overall measurement calculation blocks 88-100 that determine several different waveform scalar overall values as described below.

[0074] In the preferred embodiment, the purpose of the digital tracking band pass filter 82 is to provide a narrow (high Q) band pass response with a center frequency determined by the RPM of a selected tachometer input. The center frequency may also be a selected integer multiple of the tachometer RPM. When a waveform passes through this filter, only vibration components corresponding to multiples of the turning speed of the monitored machine will remain. When the RMS, peak, or peak-to-peak scalar value of the resultant waveform is calculated by the corresponding FPGA calculation block (88, 90 or 92), the result is same as a value that would be returned by an “nX peak” calculation performed in the application firmware of the LGC 16. Because this scalar calculation is performed as a continuous process in the FPGA 36 rather than as a calculation done in firmware, it is better suited to be a “shutdown parameter” as compared to a corresponding value produced at a lower rate in firmware. One application of this measurement is in monitoring aero-derivative turbines, which generally require a tracking filter function for monitoring.

[0075] For several of the scalar overall values, the individual data type from which the values are calculated may be selected from the normal data stream, the single-integrated data stream, the double-integrated data stream, the high-pass filtered (DC blocked) data stream, or the tracking filter data stream based on the positions of the switches 84a-84d. Also, several of the scalar overall channels have an individually-programmable low-pass filter 88a-88d. In the preferred embodiment, these scalar overall values are generated independently of and in parallel to the time waveforms that are used for prediction or protection. The scalar overall measurement calculation blocks preferably include:

• • [0076] an RMS block 88 that determine the RMS value of the time waveform, where the RMS integration time may preferably be set to 0.01 s, 0.1 s, 1 s, or 10 s;
  • [0077] a peak block 90 that determines the greater of the positive or negative waveform peak value relative to the average value of the waveform, which is preferably measured over a period determined by either the tachometer period or a programmable time delay;
  • [0078] a peak-peak block 92 that determines the waveform peak-to-peak value over a period determined by either the tachometer period or a programmable time delay;
  • [0079] an absolute +/−peak block 94 that determines the value of the most positive signal waveform excursion and the value of the most negative signal waveform excursion relative to the zero point of the measurement range, which is preferably measured over a period determined by either the tachometer period or a programmable time delay;
  • [0080] a DC block 96 that determines the DC value of the time waveform, which has a measurement range preferably set to 0.01 Hz, 0.1 Hz, 1 Hz, or 10 Hz; and
  • [0081] a PeakVue™ block 100 that determines a scalar value representing the peak value of the filtered and full-wave-rectified PeakVue™ waveform as described in U.S. Pat. No. 5,895,857 to Robinson et al. (incorporated herein by reference), which is preferably measured over a period determined by either the tachometer period or a programmable time delay. Full wave rectification and peak hold functions are implemented in the functional block 98. The PeakVue™ waveform from the block 98 is also made available as a selectable input to the prediction time waveform and protection time waveform processing described herein.

[0082] The prediction time waveform processing section 116 of the FPGA 36 provides a continuous, filtered time waveform for use by any prediction monitoring functions. An independent lowpass filter/decimator 104a is provided so that the prediction time waveform may be a different bandwidth than the protection time waveform. A waveform up-sampling block 106 provides data rate multiplication for analysis types such as Time Synchronous Averaging (TSA) and Order Tracking Input to the prediction time waveform processing section 116 may be selected from the normal data stream, the single-integrated data stream, the double-integrated data stream, the high-pass filtered (DC blocked) data stream, or the PeakVue™ data stream based on the positions of the switch 102a.

[0083] The protection time waveform section 118 of the FPGA 36 provides a continuous, filtered time waveform for use by protection monitoring functions. An independent low pass filter/decimator 104b is provided so that the protection time waveform may be a different bandwidth than the prediction time waveform. Input to the protection time waveform processing section 118 may be selected from the normal data stream, the single-integrated data stream, the double-integrated data stream, the high-pass filtered (DC blocked) data stream, or the PeakVue™ data stream based on the positions of the switch 102b.

[0084] Preferred embodiments provide for transient data collection, wherein continuous, parallel time waveforms from each signal processing channel may be collected for transmission to external data storage. Transient waveforms are preferably fixed in bandwidth and are collected from the protection time waveform data stream.

[0085] As shown in FIG. 1, the scalar overall values, as well as the digitally filtered time waveforms, pass through the LGC interface 38 to the LGC logic board 16 for further processing and transportation to the DCS controller 19 via the DCS I/O backplane 18 or to external software applications running on the MHM data analysis computer 54 via the Ethernet port 52.

[0086] FIG. 3 depicts an example of a control logic routine (also referred to herein as a control sheet) that is performed by the DCS controller 19. In preferred embodiments, a control sheet is scheduled to execute at a predetermined rate, such as 1 sec, 0.1 sec, or 0.01 sec, by the DCS software running in the controller 19. As the control sheet that controls the vibration process is executed, scalar overall vibration values are scanned from the DCS I/O bus 18 and output values are generated at the execution rate of the control sheet.

[0087] Logic functions performed by the control sheets preferably include:

• • [0088] Voting logic, such as logic to determine that an alert condition exists if 2 out of 2 scalar values are over threshold, or 2 out of 3 are over threshold.
  • [0089] Combining vibration data with other DCS process parameter data (such as pressure and temperature).
  • [0090] Trip multiply, which is a temporary condition determined by current machine state or by manual input that increases an alarm level. Trip multiply is typically used during the startup of a rotational machine, such as a turbine. As the turbine speeds up, it normally passes through at least one mechanical resonance frequency. Since higher than normal vibration conditions are measured during this resonance, “trip multiply” is used to temporarily raise some or all of the alarm levels to avoid a false alarm trip. The trip multiply input may be set manually with operator input, or automatically based on RPM or some other “machine state” input.
  • [0091] Trip bypass, which is typically a manual input to suppress operation of the output logic to disable trip functions, such as during machine startup. Trip bypass is a function that suppresses either all generated vibration alarms, or any outputs that would be used as a trip control, or both. The trip bypass input may be set manually with operator input, or automatically based on some “machine state” input.
    Time delay, which is a delay that is normally programmed to ensure that trip conditions have persisted for a specified time before allowing a machine trip to occur. Trip time delays are normally set to between 1 and 3 seconds as recommended by API670. The purpose of this delay is to reject false alarms caused by mechanical or electrical spikes or glitches.

[0092] The foregoing description of preferred embodiments for this invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise form disclosed. Obvious modifications or variations are possible in light of the above teachings. The embodiments are chosen and described in an effort to provide the best illustrations of the principles of the invention and its practical application, and to thereby enable one of ordinary skill in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. All such modifications and variations are within the scope of the invention as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly, legally, and equitably entitled.