Tuning Alarm On-Delay and Off-Delay Times
Adding a delay to an alarm is easy; choosing the right delay is the hard part. Every second of on-delay buys quiet by filtering transients, and every second also postpones the operator hearing about a real event, so tuning is always a trade between nuisance alarms and missed response time. This page is a working guide to that trade: how to choose delay values from the signal's actual behavior, a step-by-step workflow for diagnosing a chattering alarm, how delays interact with deadband, and what to record before touching a timer so the change can be judged and reversed.
Alarm delay tuning in one line: Tune an alarm delay from evidence, not habit: measure how long the nuisance transients on that point actually last, set the on-delay just longer than the transients you intend to reject, and check the result stays small against the time available to respond to a real event. Diagnose chatter before configuring anything, because amplitude jitter at the threshold calls for deadband while brief timing excursions call for a delay, and log the alarm counts, raw trend, and current settings before every change so its effect can be verified or rolled back.
The Trade: Nuisance Alarms vs Missed Events
A delay can fail in two directions. Too short, and the transients it was meant to reject keep reaching the operator, who gradually learns to ignore that point and then every point like it. Too long, and a genuine event is announced late, spending response time the operator may badly need. The right value therefore depends on two things that can both be observed rather than guessed: how long the nuisance transients on that signal actually last, and how quickly the condition can become consequential once it is real.
The method follows directly. Pull the trend and event history for the point and measure the duration of the excursions that should not have alarmed - the pump-start blips, the valve-stroke spikes, the momentary telemetry dropouts. Set the on-delay just longer than those, and no longer. Then compare the chosen delay against the time available to respond to a real event on that point. If the delay needed to reject the noise starts to approach the response window, the delay is the wrong tool for that point, and the real fix lies in the setpoint, the deadband, or the source of the noise itself.
This guide assumes the timer mechanics are already familiar. If they are not, the definitions - what an on-delay and an off-delay each do, and how they differ - are covered in the companion page on alarm on-delay and off-delay; this page is about choosing and defending the values.
A Chattering-Alarm Diagnosis Workflow
Start from the alarm history, not the configuration screen. Rank the alarms by activation count over a recent window and let the worst offenders identify themselves; chattering points are almost always a small minority producing a large majority of the events. Take the worst one, pull the raw signal trend for a representative period, and draw the alarm threshold on it. The shape of the signal against that line is the diagnosis.
Three patterns cover most cases. If the value hovers at the threshold and jitters across it in small movements, the problem is amplitude and the tool is deadband or hysteresis, not a timer. If the value spikes briefly but decisively past the threshold and returns on its own, the problem is duration and a short on-delay is the fix. If the value crosses the threshold in genuine, repeating process cycles - a pump cycling a level through the limit, for instance - neither filter is honest: the setpoint is in the wrong place or the process itself needs attention.
The workflow has one more branch: chatter that reflects a real fault. A failing transmitter, a loose termination, or slugging flow can all masquerade as alarm noise, and filtering the symptom buries the evidence. Before configuring anything, ask whether the signal itself is telling the truth. A delay applied to a lying signal does not fix the alarm; it hides the instrument problem that maintenance needed to see.
How Delays Interact with Deadband
Deadband and delay filter along different axes, and the interaction matters when tuning. Deadband works in amplitude: it separates the set and clear thresholds so small jitter around the limit cannot cycle the alarm. A delay works in time: it requires the condition to persist before annunciating or to stay clear before resetting. A sharp spike crosses the entire deadband, so only a delay rejects it; a hovering value violates the threshold for long stretches, so no reasonable delay suppresses it and only deadband helps. Matching the tool to the observed pattern is the core of the previous section's workflow.
The caution is stacking. A generous deadband combined with long on- and off-delays multiplies the blind spot: an excursion now has to be large and long before anyone hears about it, and the combined filtering is rarely reasoned about as a whole. The disciplined approach is to change one mechanism at a time, verify the effect against the alarm history, and add the second only if the residual chatter genuinely calls for it. Every layer of filtering should be traceable to a pattern someone observed on a trend, not to a default copied across the tag database.
What to Log Before Changing a Delay
Before touching a timer, capture the baseline: the current on-delay, off-delay, and deadband values, the alarm activation count over a defined recent window, a saved trend excerpt showing the behavior being fixed, the reason for the change, the expected effect, and who is making it and when. This takes minutes, and it is the difference between a tuning decision and a guess, because without the before picture there is no way to know whether the change worked, made no difference, or made things worse.
After the change, re-measure the same things over a comparable window. If the activation count fell as predicted and no real events were delayed past their response window, the change stands and its record explains it. If not, the baseline makes rollback trivial. Delay changes on consequential points deserve the same review discipline a setpoint change gets, because a timer quietly determines when an operator learns about a problem, which is a protection question, not a cosmetic one.
A central platform makes both halves of this practical. In a cloud SCADA system such as Merobix, per-point delay and deadband settings are changed in one place with an audit trail of who changed what and when, and the alarm history that supplies the before and after counts is a query rather than a manual tally. That closes the tuning loop - observe, change, verify, and keep the evidence - which is what separates a rationalized alarm system from one that has merely been quieted.
Frequently Asked Questions
How long should an alarm on-delay be?
Just longer than the nuisance transients it is meant to reject, and clearly shorter than the time available to respond to a real event on that point. Both quantities are measurable: the transient durations come from the trend and event history, and the response window comes from how fast the condition can become consequential. There is no universal number, and a delay copied from another point or another site imports someone else's noise profile onto a signal that has its own.
How do I tell whether chatter needs a delay or a deadband?
Overlay the raw signal trend on the alarm threshold and look at the shape. A value hovering at the limit and jittering across it in small amplitude movements needs deadband, because the condition is genuinely true for long stretches and no reasonable delay suppresses it. Brief spikes that shoot past the limit and self-clear need an on-delay, because they cross any deadband entirely. Repeating process cycles through the limit need a setpoint or process fix, not more filtering.
What should I record before changing an alarm delay?
The current delay and deadband settings, the alarm activation count over a defined window, a saved trend excerpt showing the behavior, the reason for the change and its expected effect, and who is changing it and when. After the change, measure the same things over a comparable window to confirm the prediction held. The baseline is what lets a change be verified or rolled back, and it gives a later reviewer the evidence behind the value in service.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.