A vibration measurement only becomes useful once it has thresholds attached: a level where someone should be told to look, and a level where the machine should be stopped before it damages itself. Setting those two levels, usually called Alert and Danger or alarm and trip, is part standards work and part judgment about the specific machine. Get them too tight and the machine cries wolf and gets tripped for nothing; too loose and a real fault runs to failure without warning. This guide covers how the two setpoints are chosen and how a monitoring system enforces them without nuisance trips.
Alarm and trip setpoints in one line: Vibration alarm and trip setpoints are the two thresholds that define when a monitoring system warns an operator and when it shuts a machine down. The Alert or alarm level is typically set near the boundary out of acceptable long-term operation, and the Danger or trip level near the boundary into the damage-capable zone, drawn from ISO evaluation zones or from the machine's own baseline plus a margin. Voting logic and setpoint delays are used so that a single spurious reading does not cause an unnecessary trip.
The most common starting point for setpoints is the ISO evaluation zones, because they already encode the meaning operators care about. The boundary out of the acceptable long-term operation zone into the not-suitable-for-continuous-running zone makes a natural Alert level: crossing it means the machine has left the range where it should be run indefinitely and someone should plan an inspection or repair. The boundary into the damage-capable zone makes a natural Danger or trip level, because beyond it the vibration can cause harm and continued running is a real risk. Anchoring the two setpoints to these recognized boundaries gives them a defensible basis.
Zone boundaries alone are not always the whole story, because a specific machine may run reliably at a vibration level that would look high in generic terms, or may show a problem well before it reaches a generic limit. This is where the baseline-plus-margin approach comes in: you establish the machine's normal, healthy vibration once it is running well, then set the Alert at that baseline plus a margin and the Danger at a larger margin above baseline. A machine that normally sits low will alarm on a change that is significant for it, even if the absolute number is still modest by generic standards, which catches developing faults earlier than a fixed zone limit alone.
In practice the two methods are combined. The ISO zones set an outer envelope you should not exceed regardless, and the baseline-plus-margin logic sets a tighter, machine-specific trigger that reacts to change. The Alert is placed at whichever is more appropriate for catching a developing problem early without constant false alarms, and the Danger is placed to protect the machine from damage. The result is a pair of setpoints that respect both the standard and the individual machine's normal behavior rather than relying on either one in isolation.
A trip that shuts down a running machine is disruptive and sometimes hazardous, so protection systems are deliberately designed so that a single momentary reading does not cause one. Voting logic is the main tool: rather than tripping on one channel exceeding its setpoint, the system requires agreement, such as two separate probes both reading above the trip level before a shutdown is initiated. This guards against a single faulty sensor, a loose connection, or an electrical glitch causing a needless trip, since a real machine problem will show on more than one channel while a sensor fault typically shows on only one.
Time delays play the same protective role in the time domain. A brief spike from an electrical transient, a passing bump, or a momentary process upset should not be allowed to trip a machine, so the setpoint is usually paired with a short time delay that requires the level to stay exceeded for a defined period before the alarm or trip acts. A genuine developing fault will hold above the threshold; a fleeting glitch will fall back before the delay expires. The delay is kept short enough that a real dangerous condition is still acted on quickly.
Startup handling is the other classic pitfall, because a machine passing through its critical speeds on the way up can momentarily show high vibration that would trip it against its normal running setpoints. A setpoint multiplier addresses this by temporarily raising the thresholds during start-up, allowing the machine to accelerate through its resonances without a nuisance trip, and then dropping the setpoints back to their normal values once it reaches operating speed. This lets the machine start reliably while still protecting it fully during steady operation, and it avoids the trap of loosening the running setpoints just to survive the run-up.
Once the levels and logic are decided, they have to be configured and enforced somewhere, and increasingly that is a monitoring or SCADA system rather than only a standalone protection rack. The system stores each measurement point's Alert and Danger setpoints, evaluates every reading against them, and applies the voting and delay logic before it acts. Because the platform can hold the machine class and baseline for each point, it can help populate sensible starting setpoints from the ISO zones and the observed baseline instead of leaving an operator to enter numbers from scratch.
Latching is an important detail in how a trip is configured. A latched trip stays in the tripped state even if the vibration falls back below the threshold, forcing a deliberate acknowledgment and reset by an operator before the machine can be restarted. This prevents a machine that tripped on a real fault from automatically restarting as soon as the reading dips, which could otherwise let a damaged machine run again without anyone investigating why it tripped. Merobix records the setpoints, the exceedance, and the reset alongside the vibration history, so the sequence of events around a trip is preserved rather than lost.
Keeping setpoints and events in a continuous history is what makes the whole scheme auditable and tunable over time. When an alarm fires, the stored history shows how fast the machine approached the setpoint and whether the trigger was a real trend or a one-off spike, which helps decide whether the level is set correctly. For fleets of machines across remote sites, having the setpoints, the voting configuration, and the trip-and-reset events all visible in one browser-accessible record is what lets an operator manage protection consistently rather than trusting that each local device was configured correctly and forgetting about it.
An alarm, often called Alert, is a warning that notifies an operator that vibration has risen to a level worth investigating, but it does not stop the machine. A trip, often called Danger, is set higher and initiates a shutdown to protect the machine from damage. The alarm gives time to plan a response, while the trip is the last-resort protective action when vibration reaches a dangerous level.
The usual method is a setpoint multiplier that temporarily raises the trip thresholds while the machine accelerates through its critical speeds, then returns them to normal once it reaches operating speed. This lets the machine pass through the resonances where vibration briefly peaks without a nuisance trip, while still fully protecting it during steady running. Combining this with a short time delay also helps ignore momentary spikes.
Requiring two probes to agree before a trip guards against a single faulty sensor, loose wire, or electrical glitch shutting down a healthy machine. A genuine machine problem will show up on more than one channel, whereas a sensor fault typically appears on only one, so voting distinguishes a real dangerous condition from a measurement artifact. This makes automatic shutdowns far more trustworthy and reduces costly spurious trips.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.