What the screen is telling you
An operator sees an alarm banner flash red and clear again before anyone reaches the station. The alarm journal shows an active timestamp and a cleared timestamp a second or two apart. Nothing is wrong with the process, nothing is wrong with the tag value, and nothing is wrong with the alarm expression — the condition genuinely was true. The problem is that the alarm system faithfully reported a transient that no human needs to act on.
The classic case is a cleanroom differential-pressure monitor. Room-to-room dP is alarmed on low limit. Every time somebody walks through a door, dP dips below the limit and recovers within a couple of seconds. The alarm is correct every single time. It is also worthless, because the condition that matters — a door propped open — looks identical for the first two seconds and then persists. The discriminator is not the value. It is the duration.
Once operators learn that the banner clears itself, they stop reading it. That is the real failure mode: a nuisance alarm rate that trains acknowledgement reflexes instead of response.
Why deadband does not solve this
Deadband on an alarm is a value hysteresis. It stops an analog signal sitting on the setpoint from chattering active/clear/active as noise rides across the limit — the value has to come back past the limit by the deadband amount before the alarm clears. That is amplitude filtering, and it works on analogs only.
It does nothing for the case here for two reasons:
- The first excursion still latches the alarm. Deadband suppresses the repeat chatter after the alarm is already active, not the initial trip.
The tag is right and the limit is right. What is missing is a time qualifier: the condition must hold continuously for t seconds before it counts as an alarm.
Where to put the delay: three options compared
| Approach | Where it lives | Filters first trip? | Works on digitals? | Survives comms loss / gateway restart | Cost of change |
|---|---|---|---|---|---|
| PLC on-delay timer feeding an alarm bit | Controller logic, scanned every PLC cycle | Yes | Yes | Yes — timing is independent of the SCADA layer | Requires logic change and revalidation of the PLC program |
| Time deadband on the SQLTags alarm | Ignition gateway, applied against the tag's scan class rate | Yes | Yes | No — timing runs in the gateway and restarts with it | Configuration only, no controller download |
| Value deadband on the alarm | Ignition gateway alarm properties | No | No | n/a | Configuration only |
A fourth variant is worth naming because people reach for it and it is the wrong tool: delaying the notification rather than the alarm. That is a different feature with a different purpose — the alarm goes active immediately and is logged, but nobody is paged unless it is still active after t. Use it when the alarm state itself is meaningful and only the human escalation should wait. It will not clean up an operator's alarm banner or the journal, because the event is already recorded.
Which one to use
Put the delay in the PLC when you own the PLC program. A timer instruction runs at controller scan rate, typically single-digit milliseconds, so the alarm bit that reaches Ignition is already qualified. The delay survives a gateway restart, a network drop, and a database outage, and the same qualified bit is available to interlocks and to any other client of the controller. There is one version of the truth about whether the condition is real.
Use the gateway-side time deadband when the PLC is not yours to change — a retrofit into a running system, a validated program you do not want to touch, or a field device that only publishes raw values. Dumb data-acquisition hardware that serializes readings with no logic capability leaves you no other place to put the timer. That is not a compromise to apologise for; it is the correct location given the constraint. Time Deadband exists in SQLTags precisely for this case.
Do not implement both for the same condition. Two delays in series add, and the effective response time becomes the sum, which is invariably discovered during a real event.
Configuring the gateway-side delay
The gateway evaluates alarm conditions against sampled data, so the sampling rate sets the resolution of any delay you configure there. Size the two together.
- Measure the transient. Trend the tag at the fastest scan class you have and record the longest nuisance excursion — door transit, pump start inrush, valve stroke. Take the worst case, not the average.
- Set the delay above that. Delay must exceed the longest legitimate transient with margin, and stay well below the time in which a real fault must be answered. If those two numbers overlap, the alarm limit is wrong, not the delay.
-
Check the scan class. The delay must be much longer than the tag's poll period. Aim for at least five to ten samples inside the delay window:
samples = delay / scan_period. A 2-second delay on a 1-second scan class gives you two samples and unpredictable edge behaviour. Move the tag to a faster scan class or lengthen the delay. - Verify the tag is actually on that scan class. A tag inherited from a group default may be polling far slower than you assume. Read the scan class assignment on the tag itself.
- Apply the time deadband to the alarm in the SQLTags alarm configuration and save. Do not also change the limit while testing — one variable at a time.
- Decide the clear behaviour. Establish whether the delay applies to the active transition only or also to the clear transition, and set it to match how operators expect the alarm to reset. Test the transition you did not configure explicitly.
Note the sampling limit honestly: a condition shorter than the poll period may never be sampled at all, and a condition slightly longer may be seen only once. Anything you need to catch reliably at sub-scan-class durations belongs in the PLC.
Pitfalls that recur
- Delay used to mask a bad limit. If the delay has to be minutes long to stop nuisance trips, the setpoint is inside the normal operating band. Fix the limit.
- Safety-relevant alarms delayed. Anything feeding a trip, an interlock, or a regulatory record should be qualified in the controller, not in the SCADA layer where a gateway restart resets the timer mid-event.
- Delay applied at the wrong tag. Delaying a derived or expression tag when the raw tag drives the notification leaves the original nuisance path intact. Trace which tag the alarm is bound to.
- Historical logging still records the raw blip. Suppressing the alarm does not suppress the value history — that is usually what you want, and it is how you audit the delay later.
- Stacked delays. PLC timer plus gateway time deadband plus notification delay gives a response time nobody has calculated. Document which layer owns the delay for each alarm.
Verify it
- Force a transient shorter than the delay — open and close the door, jog the device — and confirm no alarm appears in the banner and no active event lands in the journal.
- Force a transient longer than the delay and confirm the alarm goes active, with the active timestamp offset from the raw tag transition by approximately the configured delay.
- Compare the alarm journal timestamp against the tag's value history for the same event. The difference between the value transition and the alarm active timestamp is your measured, as-built delay — that number is what you put in the alarm rationalisation record.
Frequently Asked Questions
Can I use an alarm deadband to filter a momentary digital alarm?
No. Value deadband is amplitude hysteresis and applies to analog signals; it suppresses chatter after an alarm is already active but never blocks the first trip. A digital bit has no intermediate value for it to act on. Use a time-based delay instead.
Does Ignition support a time delay before an alarm becomes active?
Yes — a Time Deadband feature was added to SQLTags in Ignition, so the condition must hold for the configured period before the alarm counts. It is configured on the alarm in the tag configuration, not in the PLC.
Can I put the delay in the PLC instead?
Yes, and it is the more dependable option when you can modify the program. An on-delay timer runs at controller scan rate and is unaffected by gateway restarts, network drops, or database outages, and the qualified bit is available to interlocks as well as to the HMI.
Does the scan class rate affect the accuracy of a gateway-side delay?
Yes. The alarm engine only sees sampled data, so the delay should span at least five to ten poll periods — samples = delay / scan_period. Conditions shorter than the poll period may not be sampled at all.
Can I delay the notification instead of the alarm itself?
You can, but it solves a different problem: the alarm still goes active and is journaled immediately, and only the escalation to a person waits. Use it for conditions that legitimately self-clear; use a time delay when the transient should never have been an alarm.