Map an HMI alarm acknowledge to a PLC bit

Why does the PLC bit stay off when the operator acknowledges the alarm?

The acknowledgment updates the alarm state inside the panel. The PLC only sees values the project writes to tags over the link. Until the project maps the acknowledgment event to a writable tag, no PLC bit moves.

The alarm manager keeps its own history and its own acknowledged flags. The controller's entire view of the operator is its tag table. That is why the standard pattern in documented installs runs one way: the panel writes the acknowledgment across the link, and the PLC logic, not the panel, decides what the acknowledgment releases. Three pieces have to exist for a bit to move: the acknowledgment event mapped to a writable tag, the selected alarm's identity carried with the write, and a reset condition agreed before download. Missing any of the three, the operator can press acknowledge a hundred times and the bit stays where it was.

Which PLC tag should the acknowledgment write?

Give every alarm the PLC must act on its own request bit, because the controller logic needs to know which alarm the operator accepted. 32 alarms then use 32 bits, which is two 16-bit words of panel-writable memory.

Decide what the bit means before you map anything. The same bit can carry "operator acknowledged this alarm", "request to acknowledge", or "the condition has cleared", and the three meanings are not interchangeable. This article uses the first: a latch in the PLC, set by the acknowledgment edge and reset by the alarm input.

Keep the acknowledgment latch out of safety and permissive circuits: it records that the operator saw the alarm, and the hazard is gone only when the process input says so.

What do you need before you touch the project?

You need a project backup on both sides, the alarm list with each alarm's tag or number, one spare panel-writable word area for the handshake tags, and a commissioning window with the line held in a safe state.

• A saved backup of the panel project and of the PLC program, kept where you can reload them.
• The alarm list with each alarm's identity as the panel prints it, for example lshh-101.
• One word area the panel can write and the PLC can read, with bits free for the request and the alarm-number word if you use it.
• An online tag monitor on the PLC side.
• A commissioning window where the alarm can be raised under control.

How do I map the acknowledgment event in the panel project?

The acknowledgment mapping lives in the alarm configuration of the panel's project editor. Documented alarm systems have shipped it as "PLC acknowledgement tags" or as a "Status tag" that the acknowledgment function sets.

1. Create the handshake tags in the PLC first: a BOOL request bit per alarm, a BOOL done bit, and on the number route a 16-bit alarm-number word. Give the panel write access to the request area; the done bit travels the other way.
2. Open the alarm configuration in the panel project, the alarm manager or alarm-class screen, and find the acknowledgment mapping; your panel's manual names its version of the setting.
3. Point the acknowledgment at the selected alarm's request bit. On a panel with indirect addressing, map the event to write the request whose index comes from the selected alarm's number.
4. If the alarm system exposes no acknowledgment output to tags, keep the native history workflow and add a push-button object on the history screen that writes the request bit, taking its index from the screen's selected-alarm value. The button is the PLC interface; the alarm manager keeps the record keeping.
5. Map the done bit into the panel project as a read, so the panel clears the request when it arrives.
6. Download both sides inside the commissioning window.

How does the PLC catch a momentary request without missing it?

Detect the rising edge of the request bit, latch the acknowledgment on that edge, and pulse a done bit back to the panel for exactly one scan. A momentary request only has to stay readable for one PLC scan to be caught.

The edge memory makes a slow link harmless. Illustrative tags, all BOOL, initial FALSE at power-up:

ACK_DONE    := FALSE;                        // cleared each scan unless re-set
IF ACK_REQ AND NOT ACK_REQ_OLD THEN          // rising edge of the panel request
    ACK_LATCH := TRUE;                       // operator-acknowledged record
    ACK_DONE  := TRUE;                       // one-scan pulse back to the panel
END_IF;
ACK_REQ_OLD := ACK_REQ;

The done pulse lasts one scan. The panel sees it on a later read and clears the request, and the edge memory then treats the next press as a new event. How long a panel-written momentary bit stays readable, scan by scan, is covered in how many PLC scans an HMI momentary button bit stays on. If your panel can hold the request until the done bit arrives, prefer that: request-then-done staging also closes the double-count race that device-to-PLC handshakes hit when both sides change inside one update window, and a PLC program number handshake race condition fix walks one staged fix on another interface.

What does the timing look like in a worked example?

With a 5 ms PLC scan and a 100 ms link update period, the acknowledgment lands in the PLC latch about 105 ms after the operator presses the button, and the link update period, not the scan time, sets that figure.

Scenario: high-high level switch lshh-101 trips at 10:02:00, the operator opens the history screen and presses acknowledge at 10:03:00.0, call it t = 0. The example inputs are assumptions for the arithmetic: PLC scan 5 ms, and the panel writes and reads the handshake area on a 100 ms update period.

• t = 0 ms: button pressed.
• t = 100 ms: the first update boundary after the press, worst case; ACK_REQ arrives as 1.
• t = 105 ms: the next scan catches the edge, 100 ms plus one 5 ms scan; ACK_LATCH sets and ACK_DONE pulses until t = 110 ms.
• t = 200 ms: the panel's next read of the done bit, worst case; it clears ACK_REQ.

Press to latch is 105 ms at worst and about 55 ms on average, half an update period; the request is clear again by about 200 ms. One unknown stays unknown: the panel's internal time between the press and the tag write is not published by panel makers, and it adds to that first interval.

When does the acknowledgment bit reset for the next alarm?

Reset the acknowledgment latch when the alarm input clears, so the next trip of lshh-101 presents itself unacknowledged and needs a fresh press; the request and done bits reset on their own through the handshake.

ALM_LSHH101 is the BOOL alarm input the level switch drives. The reset rung:

IF NOT ALM_LSHH101 THEN
    ACK_LATCH := FALSE;
END_IF;

With that reset, the acknowledgment record describes the current event only: the condition clears, the record clears, and a fresh trip comes back as an unacknowledged alarm. If your alarm philosophy counts occurrences, add an occurrence counter on the input's rising edge and clear the record per count; that one-shot reset path is the same one described in check the reset path when a PLC flag triggers an HMI event once.

A dropped link can leave ACK_REQ held on, because panel-written outputs hold their state through a communication timeout, the behavior covered in fixing an HMI communication timeout when outputs hold state. Add one timer: a request held longer than 5 s sets a link-fault bit and clears the request, since a healthy handshake finishes in about 0.2 s at the example rates.

How do you check the whole path before the line runs?

Trigger the alarm, acknowledge it on the history screen, and watch three tags in the PLC's online monitor: the request arrives within one link update, the latch sets within one scan of it, and no other alarm's bit moves.

1. Inside the window, force or cause the lshh-101 condition and confirm the alarm on the history screen.
2. Press acknowledge and watch ACK_REQ, ACK_LATCH and ACK_DONE against the timing in the example.
3. Acknowledge a second, different alarm and confirm only its own request bit and latch move.
4. Clear the process condition, watch ACK_LATCH drop, re-trigger the alarm and confirm it presents unacknowledged.
5. Hold a request past 5 s, or disconnect the link with a request pending, and confirm the link-fault bit sets and the request clears.
6. Power both devices down and up and confirm no stale request at power-up, plus the latch behavior you chose.

If the panel shows the alarm acknowledged and the PLC value stays put, check the tag's access direction and the link status first; between them, those two explain most of these cases.

Recommendation: map one request bit per alarm the PLC must act on, catch it with a rising edge, pulse a one-scan done bit back, hold the request until the done bit arrives, and reset the latch on the alarm input; add the alarm-number word only when the list passes about 64 alarms or changes often, and keep the whole handshake out of safety and permissive logic.

When is a separate floor alarm board the better answer?

When the crew must see alarm state from across the floor, order or build a floor status screen with its own project and leave the acknowledgment handshake where the buttons are, on the operator panel.

That board plays its own content or runs your own Android app; we build shop-floor and andon-style screens for status and notice duty, and a larger wall model is quoted per project, so the quote confirms its software and interfaces before you order. The board shows state; the acknowledgment and any release logic stay in the PLC and the panel.

Questions