HMI alarm active at startup missing from list: gate the bit

Why does an alarm that is already on at startup never appear in the list?

Because the list is event-driven. It registers an alarm at the moment its bit turns on. A condition already true during the panel's boot has no turning-on moment for the panel to catch, so it is skipped while the same tag still feeds the indicator light.

A state object reads what a tag says now; an event object reads what a tag did. The Event Manager belongs to the second group: it fires on a watched bit rising, and the panel ignores conditions that are already active while it starts. That is why the fault has this shape: alarms that trip while the panel is running register every time, and the miss is confined to the one condition that was on before boot finished. A lit indicator with an empty list entry on the same tag is the signature. The light is a state object, so it follows the tag the whole time, and event registration is a separate path with a separate rule.

The same appetite for a fresh rise shows up elsewhere in the panel. If you run an event triggered screen change on an HMI when a PLC alarm bit turns on, expect that feature to need the same fresh transition and gate its source bit the same way.

How do I tell a startup miss from a bad tag mapping?

Run one controlled test: power up with the condition already active and watch the list, then clear the condition and let it trip again while the panel is running. An alarm that appears only on the second trip has a good mapping and a startup registration miss.

On the machines with this fault the mapping had already been checked the hard way. The alarm tag was moved from C0 to a new C16, the old tag deleted, and the list behaved exactly the same, while the indicator light mapped to the same tag tracked the flow switch the whole time. Address changes were the wrong search, and the controlled test says so in one power cycle.

Work the test in this order:

1. Note the raw condition before power-up: flow switch low, raw bit true.
2. Power up and watch the list: empty for that alarm while its indicator light is on.
3. With the machine running and the panel up, clear the condition with the machine's approved test method, then let it trip again under controlled conditions.
4. Read the result: a miss at power-up plus success on the later trip is registration timing, and the startup gate in the next sections applies. A miss on the later trip too means the alarm configuration is the open question: verify the alarm's source address against the PLC bit and re-check the event setup in the project.

Use the machine's approved test method to create the trip; never defeat a protection to exercise a display.

What does each symptom point to?

Four combinations cover this fault, and each points at a different layer. Match your machine's exact behavior against the list before you change anything.

• Miss at power-up, correct after a later trip. Registration timing. The condition was on during boot and made no transition. Apply the startup gate; nothing else needs changing.
• Indicator light on, list entry missing, same tag. The address is good. State and event objects read the tag by different rules, so keep the address and add the gate.
• Miss on every trip, even with the panel up. The startup race is not the cause here. Verify the alarm's source address against the PLC bit and re-check the event configuration in the project before anything else.
• Two identical machines show the miss and two older machines do not. The affected pair ran programming software and firmware 2.23; the two clean machines ran version 2.0. Record the versions per machine and take the comparison to the panel vendor's support channel. A version difference is a data point to report, and a downgrade is not a repair step to trial on a running line.

How long should the alarm bit stay inhibited at power-up?

Hold the bit off until the panel is demonstrably ready. Gate it on the panel's ready signal where one exists, or on a timer set to your measured boot time plus 5 seconds, which gives 25 seconds on a panel measured at 20 seconds from power-up to live tags.

Measure the boot once per panel model and use that number. Time from breaker on to the first live tag update on the alarm screen, over three power-ups, and keep the longest reading. The panels in this case measured about 20 seconds; other models differ, and the 5-second margin exists to cover the last poll cycle and the screen draw after the ready state sets. Startup speed is worth knowing before purchase too: the intake checklist in test startup and runtime first turns boot time into a number you compare while the panel is still a quotation line.

One limit matters more than the timing. If the alarm feeds an interlock or a safety function, machine safety standards such as IEC 60204-1 require that function to operate without depending on the HMI, so gate only the annunciator bit that feeds the list and leave the protective logic on its own path.

What does a worked example of the startup inhibit look like?

A filler machine's HMI panel measures 20 seconds from power-up to its first live tag update, Low Water Flow is true at every power-up, so the timer holds the annunciator off for 20 + 5 = 25 seconds and the list registers the alarm 25 seconds after power-up.

Walk the timeline:

• t = 0: power on, flow switch already low, raw bit true, inhibit timer running, list empty.
• t = 20 s: the panel finishes booting and draws the alarm screen; the light is on, the list entry is still absent.
• t = 25 s: the timer done bit releases the gate, the annunciator bit rises from off to on, and the Event Manager registers Low Water Flow in the scrolling list. The operator sees the alarm 25 seconds after power-up instead of never, and any alarm that trips later runs at zero added delay because the gate is already open.
• With the ready-signal gate instead, and the ready signal measured at 18 s, the release moves to 18 s, which is 7 seconds earlier: 25 - 18 = 7.

(* Illustrative names; map them to your own tags. *)
(* Types: LowFlowRaw, PanelReady, LowFlowAnnunc : BOOL; InhibitT : TON. *)
LowFlowRaw    : BOOL := FALSE;  (* TRUE when the flow switch reads low *)
PanelReady    : BOOL := FALSE;  (* TRUE when the panel's ready bit is on *)
InhibitT      : TON;
LowFlowAnnunc : BOOL;           (* the bit the alarm list watches *)

(* Timer variant, where the panel publishes no ready bit *)
InhibitT(IN := TRUE, PT := T#25S);
LowFlowAnnunc := LowFlowRaw AND NOT InhibitT.Q;

(* Ready-bit variant, preferred where the bit exists *)
(* LowFlowAnnunc := LowFlowRaw AND PanelReady; *)

The test that checks the change: power up with the flow switch held low. Before the change the list stays empty until the condition clears and trips again. After the change, Low Water Flow appears at 25 s on the timer variant or the moment PanelReady sets on the gate variant, and the indicator light never blinks. One boundary on the timer variant: it releases 25 seconds after the PLC program starts, so it covers a full machine power-up. If the panel alone reboots while the PLC keeps running, the timer has long since expired, the gate is open during the panel's boot, and the miss returns; use the ready-bit variant wherever the panel can reboot on its own.

Is a ready-signal gate better than a fixed timer?

Yes. Many HMI panels write their own status into PLC registers, including a communication-good bit, and gating on that bit releases the alarm at the true ready moment, about 18 seconds on the example panel, with no guessed margin added on top.

Check whether your panel publishes one. The panel in this setup exposes a Communication Okay bit for exactly this job, and panels in the class commonly write status such as screen number and communication state into PLC registers. Put it to work in this order:

1. Find the panel-to-PLC register that carries the Communication Okay bit; the panel's documentation names the address.
2. Watch it through three power-ups: note the moment it sets, 18 s on the example panel, and check that it stays off until communication is established.
3. Gate the annunciator with it: LowFlowAnnunc := LowFlowRaw AND PanelReady.
4. Define the failure path. If the bit never sets, a PLC-side timeout raises the alarm instead: 60 seconds from power-up is a workable starting point, and it drives an ungated PLC alarm plus your defined response, such as a stack light output.

The register-exchange habit works in both directions; signaling an HMI alarm acknowledgment back to the PLC is the same idea with one agreed bit per side, so both devices know the state of the handshake.

Recommendation: Gate the annunciator on the Communication Okay bit when the panel publishes one, keep the indicator light mapped to the raw bit, and put a PLC-side timeout behind the gate so a panel that never becomes ready is still announced. Use the timer at measured boot plus 5 seconds only where no ready bit exists, and never gate an alarm bit that feeds an interlock or a safety function.

Do I need new hardware or a separate display?

No. Every change above is one comparison in the PLC project, AND the raw bit with a ready signal or with a timer done bit, so the panel, the PLC and the cabinet all stay as they are.

If the repair leaves you wanting the same alarm text where the whole shift can read it, that is a separate status board driven from the PLC, a different product from the HMI. We build shop-floor signage for exactly that duty, and a board on a low-voltage feed belongs on a rail-mount supply in the cabinet.

How do I verify the fix and what do I record?

Close the job only after the panel passes both tests: the condition already active at power-up appears in the list at the release moment, and a fresh trip while the panel is running still registers exactly as it did before the change.

1. Power up with the flow switch held low: the list shows Low Water Flow at the release time, 18 s on the gate or 25 s on the timer, with no duplicate entry when the condition later clears.
2. Trip the alarm normally with the panel up, using the machine's approved test method: it still registers on the transition, so the gate added no lag to ordinary alarms.
3. Watch the indicator light through the inhibit window: it stays on from power-up because it maps to the raw bit.
4. Reboot the panel alone with the PLC running: the ready-bit gate recovers the alarm when the panel returns. If you ran the timer variant, the miss returns in this test, which is your cue to move that machine to the gate.
5. Write one line per machine: software and firmware version, 2.23 or 2.0 in this case, measured boot seconds, gate type, release time, and both test results. Two affected machines against two clean ones is exactly the record a support engineer can act on.

For a record that never depends on the panel, log the alarms in the PLC itself: a circular event buffer with separate pointers keeps the history in the controller while the display side is the thing under repair.

The decision, case by case: the alarm misses only at boot and registers on a later trip, gate the annunciator on the panel's ready bit; no ready bit published, use the timer at measured boot plus 5 seconds; the alarm misses every trip, repair the alarm configuration instead; the alarm feeds an interlock or a safety function, leave it ungated and treat the HMI list as a second window only.

Questions