Stop HMI event emails firing at startup with an edge bit

What the burst is telling you

The panel's event manager has one job, and the documentation for it states that job plainly: events watch their conditions the whole time the panel runs, and when a condition is met, the event's actions run, email included. A condition like 'C0 is off' is met the instant the panel starts if C0 is off at that moment, whether or not anything tripped. That is the whole mechanism behind the startup burst. A burst typically lands within 2 seconds of the panel finishing its boot sequence. Symptoms and what each points to:

• A burst of alarm and recovery emails lands within seconds of a panel boot or right at the end of a program download, with no change on the machine. That points to level conditions matching the bits' current states at startup.
• For one circuit only one direction fires at a given boot, whichever state matches; across several hundred alarms both kinds appear in the burst, because some bits boot on and some boot off.
• The alarm display and the alarm list look correct while the emails are wrong. Monitoring works; the trigger pattern is what sends mail.

The same startup evaluation can bite the alarm list itself: an alarm already active at boot can stay off the list until the bit is gated, a related problem with its own fix in HMI alarm active at startup missing from list: gate the bit.

Why flipping the bit or comparing words leaves the burst in place

Two edits get suggested for this, and both leave the mechanism standing.

Flipping polarity means watching a bit that turns on when C0 turns off. The new bit still has an on state and an off state, and at boot one of them matches, exactly as the old condition did. At 28 sites with several hundred alarms each, the flip also touches every event definition and adds a new bit per alarm, thousands of edits that still burst at the next boot.

Comparisons and ranges share the gap. If alarms are sequential values in a word, a range condition watches many alarms with one event, which is genuinely useful for grouping. But a word already inside the range at boot matches the range on the spot, the same way the bit did. A range is still a level.

The fix: gate every email event on a one-scan edge bit

Look first in the panel's event-manager documentation for the installed software revision. If it documents a transition or on-change trigger type, switch the email events to it and the PLC stays untouched. If it documents only level conditions, build the edge in the PLC; the rest of this section does that.

For the e-stop bit, add three rungs. The bit names below are illustrative; use whatever your addressing scheme calls a spare boolean. C0 is the status bit, off when the circuit is tripped. PrevEstop is a boolean holding C0's value from the previous scan. EdgeEstopAlarm and EdgeEstopReturn are boolean pulses.

1. EdgeEstopAlarm is on when C0 is off and PrevEstop is on: the one scan on which the circuit tripped.
2. EdgeEstopReturn is on when C0 is on and PrevEstop is off: the one scan on which it recovered.
3. PrevEstop takes C0's value after both edge rungs, in the same scan.

Each pulse lasts exactly 1 scan, a few milliseconds on a small PLC with a 10 ms scan time, so the panel sees a condition that comes on once and goes off, and one email follows each real change. These are standard one-shot rungs; if you have not built a pair before, a walkthrough of rolling your own rising- and falling-edge trigger shows the pattern for both directions.

Initialization decides whether this works. On the PLC's first scan, set PrevEstop to C0's current value and both pulses to off. If PrevEstop powered up off while C0 sat on, rung 2 pulses on scan one and sends exactly the false recovery email being fixed. Giving PLC bits a defined first-scan state is the same habit described in Initialize PLC bits to a safe state after a long power outage.

On the panel, change each email event's trigger condition from the level to its pulse: the alarm email waits for EdgeEstopAlarm, the recovery email for EdgeEstopReturn. Message text and recipients stay as they are. Keep the alarm display and the alarm list driven by C0 itself; the pulses exist for notifications only.

These rungs only read the e-stop status bit. Nothing in this change may sit between the e-stop circuit and the machine's safety function, and a notification change must never alter how a trip stops the machine.

A bypass bit is a different tool for a different job: it mutes notifications during a planned window and someone must restore it afterwards, which Stop HMI event emails with a PLC bypass bit covers. The edge gate is permanent logic with nothing to restore. The same pulses can drive other transition-only panel behavior, such as the event-triggered screen change you may already run on the panel.

Recommendation: switch the email events to a documented transition trigger if the installed panel software documents one; if it documents only level conditions, generate a one-scan pulse in the PLC per monitored condition (one previous-state bit, two edge rungs), point every email event at its pulse, and initialize every previous-state bit to match its monitored bit on the first scan. Keep the alarm display on the original level bit either way.

Example: one e-stop bit across 28 sites

Inputs: C0, off when the e-stop circuit is tripped and on when healthy, with one email event per direction (alarm on the off condition, recovery on the on condition), the scheme this article works throughout. A fleet of 28 sites with several hundred alarms each; the arithmetic takes 300 alarms per site as its working figure. PrevEstop initialized to C0 on the first scan, both pulses off, per the rungs above.

Rule in words: a pulse is on only when the current state and the previous state differ, and only for that 1 scan. Alarm pulse = C0 off now AND C0 on last scan. Recovery pulse = C0 on now AND C0 off last scan. The email events trigger on the pulses, not on the levels.

Arithmetic, with 1 = on and 0 = off:

• Healthy boot: C0 = 1, PrevEstop = 1. Alarm pulse = (NOT 1) AND 1 = 0 AND 1 = 0. Recovery pulse = 1 AND (NOT 1) = 1 AND 0 = 0. Emails sent: 0.
• Boot with the circuit already tripped: C0 = 0, PrevEstop = 0. Alarm pulse = (NOT 0) AND 0 = 1 AND 0 = 0. Recovery pulse = 0 AND (NOT 0) = 0 AND 1 = 0. Emails sent: 0, and the tripped alarm still shows at the panel.
• Real trip, C0 falls from 1 to 0: alarm pulse = (NOT 0) AND 1 = 1 AND 1 = 1, one alarm email. The next scan, 10 ms later at a 10 ms scan time, PrevEstop = 0, so the alarm pulse = 1 AND 0 = 0, no repeat.
• Real recovery, C0 rises from 0 to 1: recovery pulse = 1 AND (NOT 0) = 1 AND 1 = 1, one recovery email.
• The burst before the fix: 300 alarms x 2 messages per alarm = 600 emails per site at each boot, and 600 x 28 = 16,800 emails across the fleet at each boot. After the fix: 0 at boot, one email per genuine change.

Result: with 300 alarms per site across 28 sites, the startup burst of 16,800 emails goes to 0 in both boot states, and each real change sends exactly 1 email.

Decision: gate every email event whose trigger is a plain level. The threshold is mechanical: an email goes out only on a scan where its pulse is on, and a pulse is on only after a real state change, so a state already true at boot never sends.

Word alarms: edge the word

When alarms are sequential values in words, edge the whole word. Keep an old copy of each alarm word and compute an edge word with a bit set only where an alarm rose since the last scan: EdgeWord = NewWord AND NOT OldWord, then copy NewWord into the old register. The recovery direction is the mirror image, OldWord AND NOT NewWord. Each bit of the edge word pulses for 1 scan, and the email events watch bits of the edge word.

The saving is real at scale: 300 alarms packed into 16-bit words need 300 ÷ 16 = 18.75, so 19 words, which is 19 edge computations and 19 copies, 38 rungs in all, against a pair of rungs per scattered bit. Keep range and comparison conditions for grouping and message text; a range is still a level, so the email event still triggers on the edge word, and a word already inside the range at boot sends nothing.

Checks before you call it done

Point the events at a test recipient list, your own address, for the first pass, then run these in order:

1. Boot the panel with the circuit healthy: no email arrives within the first 60 seconds.
2. Boot with the circuit already tripped: no email arrives, and the alarm still shows at the panel.
3. Trip the circuit for real: exactly one alarm email arrives.
4. Clear the trip: exactly one recovery email arrives.
5. Leave each state alone for the rest of the 8-hour shift: no further emails from that circuit.
6. Power up the PLC alone: no pulse on the first scan. One false recovery email here means PrevEstop is initializing wrong.
7. Download the panel program again, the other moment the burst used to appear: still no emails at boot.

Rolling the pattern out across sites

Build the rung pair and the condition swap once, prove it at one site on a representative alarm set (bits that boot off, bits that boot on, bits that genuinely change), then copy the identical pattern to the remaining sites. The pattern is the same everywhere: same three rungs, same condition swap, same first-scan initialization. Name each pulse bit after the bit it watches so the mapping stays readable years later.

Questions