Yes, most HMI software can pop an alarm up in the middle of the screen with a message box object. Reserve that for the one or two conditions that must interrupt any screen; run the rest through an alarm banner or an alarm list object. Trigger each pop-up from a bit the PLC holds while its condition is true, and test both the set and clear transitions before hand-off.
An alarm can wait at the bottom of the screen, sit in a list, or jump into the middle of the screen and stop what the operator is doing. Most HMI software supports all three, and choosing between them is a decision about the operator's task, not about the software. This page gives the decision rule, the trigger bit behind the pop-up, the text that makes a pop-up worth reading, and the two transitions you must test before anyone relies on the screen. The short version: one message box pop-up for the condition that can stop the machine, an alarm banner and an alarm list for everything else.
Can an HMI show an alarm as a pop-up message box?
Most HMI software gives you three ways to present an alarm, and the pop-up is one of them: a message box object that appears in the middle of the screen when a boolean alarm bit turns on, beside a bottom banner and a full alarm list.
The toolkit is consistent across HMI lines: a banner along the bottom edge that shows the active alarms, an alarm list object you place on a screen like any other object, an alarm database behind them that collects each entry, and the message box that covers the center of the screen. In some HMI lines the banner and the on-screen list are two display modes of the same alarm list object, so you define each alarm once and choose where each one shows.
If your HMI tool has no dedicated message box object, you can build the same effect from a screen shown in a pop-up window; the mechanics are in building an HMI pop-up screen with a screen window.
How does a pop-up differ from an alarm banner and an alarm list?
The three presentations split by how many conditions they show and how hard they interrupt: a pop-up covers the screen for one urgent condition, the banner holds a line of active alarms at the bottom, and the list shows every active or logged entry on a full screen.
| Message box pop-up | Alarm banner | Alarm list object | |
|---|---|---|---|
| Where it appears | Center of the screen, over the working view | A fixed line at the bottom edge | Any screen, sized and placed like other objects |
| What it shows | One alarm condition per box | The currently active alarms | The full list, active and past entries |
| Operator task | Stop and respond now | Glance while continuing the task | Review several, acknowledge, look back |
| Interruption level | Highest: it covers the work area | Low: it shares the screen | Low: it is a screen you visit |
| Driven by | One boolean alarm bit per box | The active set in the alarm database | The alarm database |
The banner line shows whichever alarms are active at that moment; the list is what operators open when they need to compare conditions or check what has already fired. On a screen where you have placed your own objects along the bottom edge, you can switch the banner off for that screen; the steps are in hiding the alarm banner at the bottom of an HMI screen.
When does each alarm presentation win?
A pop-up wins when one condition must interrupt the operator on any screen, the banner wins for conditions the operator should notice without leaving the task, and the list wins when several conditions need review, acknowledgment or a look back at what has already fired.
Pop-up message box. Keep it for stop-class conditions: the fault that halts the station and needs a person now. One or two bits per project is the useful range. Past that, boxes stack up, operators start closing them unread, and a real alarm loses its punch. Give each box its own bit; a box driven by a grouped summary bit tells the operator that something is wrong somewhere, and the operator then has to go find the detail in the list anyway.
Alarm banner. This is the default layer for run-of-shift conditions: a door held open, a roll running low, a top-up due. The operator keeps working and still sees that something is active.
Alarm list. Give the list a screen of its own, or a region on the main screen, whenever operators must compare several active conditions, acknowledge them, or check what fired on the previous shift. A pop-up shows one condition at a time and leaves no review surface, so a process that requires review needs the list.
Recommendation: put a centered message box pop-up on each condition that stops the machine or a station; run every other condition through the alarm banner; give operators one alarm list screen for review and acknowledgment; drive each pop-up from its own PLC bit and test the set and clear transitions before hand-off.
If a station needs a standalone andon or notice board with no PLC connection at all, that is a different product class: a small panel-mount signage display plays its own status pages from a memory card offline, which the shop-floor screens category covers. It sits beside the machine; the HMI keeps the alarms.
Which bit should trigger the pop-up?
Trigger the pop-up from a boolean bit the PLC holds at 1 for as long as the condition is true, because the HMI detects an alarm by watching that bit and refreshing its state on each poll, so the alarm shows within one poll interval of the bit setting.
Put the logic in the controller: the bit sets when the condition is true and clears when it is false. A maintained bit makes the presentation follow the process, and both edges carry meaning: 0 to 1 is the pop-up appearing, 1 to 0 is the recovery. The controller program has to produce both edges cleanly; a note on detecting both the rise and the fall of a PLC bit shows the usual contact pattern.
Keep alarm bits in a poll group the HMI reads quickly. Detection latency is bounded by the poll interval, and the average is half of it, so the useful question for each alarm is how many polls of delay the process tolerates. If a condition needs visibility inside one poll, poll that tag in a faster group, or detect the condition in the controller and send the HMI a single summary bit.
For a condition serious enough to take over the whole screen, trigger a screen change from the alarm bit; event triggered screen changes on an HMI when a PLC alarm bit turns on covers that path.
What should the pop-up message say?
Write the message so the operator can tell which machine failed, what to do next and how far the value has drifted; embed the live readings in the text where the tool allows it, and one documented alarm system carries up to four process tags with each alarm message.
A box that says only Alarm trains operators to close boxes. Name the station and the failed element: Air pressure, palletizer, supply below setpoint. Where the software supports live values in the text, attach them, so the box reads Air pressure 4.2 bar, need 6.0 bar. That allowance covers a measured value, a setpoint and a position or batch number with a tag to spare.
The same alarm text definitions feed the banner and the list, so write each text once and let all three presentations use it. Keep lines short: a banner row has room for one sentence, and an operator responding to a pop-up reads it in a glance.
Example: which alarm presentation does a 12-alarm palletizer cell need?
A palletizer cell carries 12 alarm conditions in its PLC: one low-air-pressure bit stops the cell, so it alone gets the pop-up message box, the other 11 run through the banner and the list, and the pop-up appears within one 500 ms poll.
The situation. The cell's PLC holds 12 alarm conditions. Low supply air pressure stops the palletizer mid-cycle and needs the operator from any screen. The other 11 are notices such as film roll low or guard door open, handled between cycles.
The decision. One condition deserves an interruption, so one message box pop-up is bound to that single bit. The 11 notices feed the alarm list, and the banner line at the bottom of the main screens shows whichever of them are active. No grouped summary bit drives the pop-up, because the operator needs the name of the fault inside the box.
The message. The pressure alarm text carries 2 live values within the tag allowance: the measured pressure and the setpoint. At the test fault it reads Air pressure 4.2 bar, need 6.0 bar, so the operator can judge whether to clear a filter or call for the compressor before walking over.
The timing. Assume the HMI reads the alarm tags in a 500 ms poll group and the PLC scan is 10 ms. Worst case, the bit sets just after a poll, and the pop-up appears one poll plus one scan later: 500 ms + 10 ms = 510 ms. On average the reading catches the bit half a poll after it sets: 500 ms / 2 = 250 ms, plus the 10 ms scan. Both are fast beside a palletizer cycle measured in seconds. If contact with product could go wrong inside one second, the stop belongs in the controller interlock and the pop-up only reports it afterwards.
The test. With the machine in a safe state, force the pressure bit from 0 to 1: the pop-up appears with the correct text and both values. Release it from 1 to 0: the box clears and the banner returns to the remaining active notices. Then set the bit again and confirm the pop-up returns.
The result. One pop-up for the one stop condition, banner and list for the other 11, worst-case pop-up latency 510 ms, and a message carrying 2 live values.
How do you test a pop-up alarm before hand-off?
Test both transitions of every trigger bit before operators rely on the screen: force the bit from 0 to 1 and confirm the pop-up appears with the right text, then release it from 1 to 0 and confirm the screen returns to the state your procedure specifies.
Run the checks with the machine in a safe, authorized state, forcing bits from the controller or the HMI's test tools:
- Set, 0 to 1. The pop-up appears on the screen it is assigned to, with the correct text and live values.
- Clear, 1 to 0. The box closes or blanks, the banner updates, and the entry moves from active to history in the list.
- Dismissal while active. Close the box while the bit is still 1, and keep the condition visible in the banner or the list. If operators must acknowledge alarms under your procedure, make that a configured write to a PLC bit; mapping an HMI alarm acknowledgment to a PLC bit covers the wiring.
- Recurrence. Set the bit again after dismissal and confirm the pop-up returns with the same text.
- Record. Note the tested bit, the displayed text and the observed recovery in the commissioning record.
If a pop-up never appears, check the bit's value in the controller first and the communications path second; change the box layout last. A box bound to the wrong address is fixed in a minute; a layout change hides a wiring problem.
Questions
Does closing a pop-up message box clear the alarm in the PLC?
Closing the box is a screen action, and it ends the alarm only if the project was configured to write back to the controller on close. The safer default is to leave that write out: the PLC bit ends the alarm when the condition clears, and the entry stays visible in the banner until then. Where your procedure requires operator acknowledgment, configure it as an explicit write to an acknowledgment bit and test that write the same way as the pop-up itself.
Why does my alarm pop-up appear late or blink on and off?
Late appearance comes from the poll: the alarm state refreshes each time the HMI polls, so a tag in a slow poll group adds delay. Blinking points at the bit itself: a chattering sensor or a condition sitting right at its threshold makes the bit set and clear repeatedly. Add a debounce or a hysteresis band in the controller logic so the bit changes state cleanly, and look at communications only after the controller value reads steady.
Can one pop-up show on every screen of the project?
Message box objects either belong to the screen they are drawn on or are set to display on every screen, and the choice sits in the object's display behavior settings in the HMI software. For a machine-level alarm that can fire anywhere, set the box to show on all screens so the operator never has to navigate to find it. Where a tool offers per-screen boxes only, use an event-driven screen change to a dedicated alarm screen instead.
Where do past alarms go after they clear?
They stay in the alarm database the HMI project keeps, and the alarm list object can present them as history entries with time stamps. That record is how operators reconstruct a shift: which condition fired, when it fired, and how long it stayed active. It is also the reason the pop-up belongs beside a banner and a list instead of replacing them; the database keeps what a transient box leaves behind.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.