An HMI alarm that blinks but cannot be acknowledged is an event with its confirmation box unchecked. The requirement sits on the event in the Event Manager, not on the Alarm Message object on the page. Check the box, transfer the project, and the alarm then holds after acknowledgment until its condition clears.
An alarm that blinks on the page and gives the operator no way to acknowledge it is an event with its confirmation box unchecked. The requirement to confirm an alarm is a setting on the event in the Event Manager, and the panel's help file says so in one line: the confirmation requirement for any alarm is a setting in the Alarm Configuration, inside the Event Manager. Nothing on the Alarm Message object you placed on the page creates an acknowledgment step. Check the box on the event, transfer the project, and you get the sequence you expect: the alarm blinks in, the operator acknowledges it, it holds, and it clears when the condition goes away.
Where the acknowledgment requirement lives
Four jobs sit inside what looks like one acknowledgment function, and each lives somewhere else:
- The event, edited in the Event Manager, decides whether the operator must confirm the alarm before its record can be cleared in the alarm history screen.
- The Alarm Message object, picked from the Object List and placed on a page, shows the alarm text. It is a display.
- The event's actions decide what else happens when the alarm fires. A Message Box action pops a dialog on the screen.
- The tag or switch behind the event decides when the alarm condition clears.
Reworking the page object first changes none of this. Other packages split the work the same way: one vendor's alarm and event control object has a Require confirmation checkbox that opens a confirmation dialog when the user acknowledges a single alarm. Wherever the software comes from, confirmation belongs to the alarm definition or its control object, and the list and message objects present it.
Match the symptom to the setting
| What you see | What it points to | What to do |
|---|---|---|
| The alarm blinks red and there is no way to acknowledge it | The event does not ask for confirmation, so the software creates no acknowledgment step | Edit the event in the Event Manager and check its confirmation box |
| No popup when the alarm arrives | The event has no Message Box action; the page object is only the display | Add the action on the event: press Add Action, press the V button on the command, select the Message Box tab, press OK |
| The operator acknowledges the alarm and it stays on the page | The condition is still active; acknowledgment records the response and the alarm holds until the condition clears | Close the door, reset the switch, or return the tag to normal |
| The alarm left the page but its record sits in the history screen | Normal: the history record is separate from the active display | Clear the record from the history screen if your log practice allows it |
| An alarm that was active before power-up is missing from the list | Startup handling of the alarm bit | Gate the bit at startup |
Two questions give four states
ISA-18.2, the alarm management standard, gives every alarm two attributes: whether the condition is active, and whether a person has acknowledged it. Two yes-or-no questions make four states, and every symptom in the table above is one of them.
| Condition | Acknowledged | State | Operator action |
|---|---|---|---|
| Active | No | New alarm, blinking | Respond to the machine, acknowledge |
| Active | Yes | Acknowledged, holding | Clear the condition |
| Cleared | No | Gone, unanswered | Acknowledge so the record can be cleared |
| Cleared | Yes | Finished, record kept in history | None |
Alarm colors and blink patterns are set in the Alarm Screen Style, under the Panel Manager. If the controller must know the operator responded, map the HMI alarm acknowledgment to a PLC bit. The split between a value and a person's confirmation runs through the rest of the software too: a written value can show as pending until the operator confirms it.
Worked example: one guard-door alarm through the four states
At 08:14:02 a guard door opens and its switch bit turns on. The event fires, the Alarm Message object shows the alarm, and it blinks red. Active, not acknowledged.
At 08:15:30 the operator acknowledges it: 08:15:30 - 08:14:02 = 1 min 28 s after arrival. The event requires confirmation, so the response is recorded. The door is still open, so the alarm holds on the page. Active, acknowledged.
At 08:41:10 the door closes and the bit drops out. Cleared and acknowledged: the alarm leaves the active list, and its record stays in the alarm history screen, where a record needs confirmation before anyone can clear it. Total alarm life: 08:41:10 - 08:14:02 = 27 min 8 s.
Run the same event with the confirmation box unchecked and the middle step has nothing to press at 08:15:30. That missing step is the fault you are chasing.
The fix, step by step
- Open the project in the panel software and open the Event Manager.
- Find the event behind the blinking alarm, matched by message text and tag. When several events feed one Alarm Message object, open the event tied to that alarm, not its neighbor.
- Edit the event and check its confirmation box in the Alarm Configuration area.
- Save the project and transfer it to the panel. Transfer during a stoppage or with the machine idle; during a download the panel is out of the alarm loop.
- Walk the four states in the table above, then the checks below, before you call it done.
Add the popup only if you want one
A popup is presentation, and it goes on the event as an action. Open the event, press Add Action, press the V button on the command, select the Message Box tab, and press OK. The full walkthrough is in showing an alarm as a pop-up message box on an HMI screen. The popup pulls the operator's eyes to the screen; the confirmation box is what records the response. A popup with the box unchecked still leaves an alarm nobody can acknowledge. The same ask-first pattern covers button confirm dialogs, where the operator accepts an action before the panel runs it.
Check it worked, in simulation first
The projects folder of the panel software ships a sample named sample_alarms_events. Load it and run it in the simulator on the computer, then compare its event settings against yours. That comparison shows what the confirmation box changes, with no machine attached. Then test the panel:
- Make the condition active and watch the alarm arrive blinking.
- Acknowledge it and check that it holds while the condition stays active.
- Return the tag to normal and check that the alarm leaves the active list.
- On a fresh test alarm, try to clear its record in the history screen before acknowledging. The panel should refuse until the event is confirmed.
If the history comes back empty, an HMI alarm history downloads only if logging was on before the alarms happened. When the view stops at the newest 64 records, save alarms beyond the 64 limit to USB.
Make the alarm line readable from where the operator stands
While the project is open, check the text. Plan 30 ft of viewing distance per inch of capital height, the highway sign planning figure, and use 20 ft per inch for a person reacting to an alarm. Space lines at 1.7 x the capital height. A panel read from 10 ft needs 10 ft / 20 ft per inch = 0.5 in capitals, with line spacing of 0.5 in x 1.7 = 0.85 in. An alarm window 3.5 in tall then fits 3.5 in / 0.85 in = 4 lines. If the installed font comes out smaller, enlarge the font or move the operator closer.
The decision
Recommendation: Check the confirmation box on the event itself whenever the operator must respond before the record can be cleared from the alarm history screen. Keep the Alarm Message object as the display, and add the Message Box action only when the alarm also needs a popup. Leave the box unchecked for informational events nobody must answer. Walk the four states in the sample_alarms_events simulator before you transfer to a panel attached to a running machine.
Questions
Why does an alarm blink on the page with no way to acknowledge it?
The event behind the alarm does not require confirmation, so the software creates no acknowledgment step. The setting is the confirmation box in the Alarm Configuration area of the event, inside the Event Manager. The Alarm Message object on the page displays alarm text; no change on that object adds an operator response. Check the box on the event, save, and transfer the project.
Does acknowledging an HMI alarm clear it from the screen?
No. Acknowledgment records that a person responded; the alarm itself clears when its condition clears. An active, acknowledged alarm holds on the page, and a cleared, acknowledged alarm leaves the active list with its record kept in the alarm history screen. ISA-18.2 models this as two attributes of every alarm: active state and acknowledgment state.
Is a message box needed for alarm acknowledgment to work?
No. The Message Box is an event action that pops a dialog when the alarm arrives, to draw attention. The confirmation box on the event is what creates the acknowledgment step and lets the record be cleared from the alarm history screen once it is confirmed. You can run either one without the other.
How can I test alarm confirmation without stopping the machine?
Load the sample_alarms_events project from the panel software's projects folder and run it in the simulator on the computer. Compare its event settings against your own, then transfer and test on the panel with the machine idle, since the panel is out of the alarm loop during a download.
Why is my alarm history empty or short of old alarms?
The history downloads only if logging was enabled before the alarms happened, so check that logging was on. Some history views also stop at the newest 64 records; export the alarm history to USB to keep the older records.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.