HMI alarm priority will not carry an alarm to every screen

Why does my alarm vanish when I change screens?

The screen you switched to has no alarm display object on it, so it has nothing to draw the message with; the alarm is still active in the project, and priority never moves a display from one screen to another.

Every HMI platform splits an alarm into two parts. The condition lives in the alarm database with its trigger, its message text and its priority. The display is a separate object you place on a screen, the same way you place a button or a numeric readout. One major platform's documentation calls the object an alarm control and sets its rows and cells in the screen's properties; other editors call it an alarm banner, an alarm list or an alarm line. The name changes, the rule stays the same: the object belongs to the screen it sits on.

That is the whole failure. The screen where you configured the alarm has the display, so it shows System off. Setup has no alarm display, so it shows nothing, even though the trigger bit is still on and the alarm database still lists the condition as active. Priority sits in the database next to the condition; it never adds an object to a screen that lacks one.

What does alarm priority actually change?

Priority sorts the alarms a display is already showing, so the important ones read first; in the worked example a priority 1 system-off alarm lists above a priority 5 manual-mode alarm on every screen that holds a display object.

Priority does three jobs inside a display and none outside it. It orders the rows, usually highest first. It decides which alarms keep their rows when more alarms are active than the display has room for: if the display shows 3 rows and 4 alarms go active, priority decides which one waits. In some editors it also groups alarms into classes you can show or hide per display. What it never does is add a display to a screen; a sort rule cannot draw a row.

The practical consequence is an order of work: fix visibility first, priority second. Once the banner is on every screen, the priorities you already set give the ordering you wanted, and adjusting them is a two-minute edit rather than a rebuild.

Is the trigger failing or is the display missing?

Watch the trigger bit in the programming tool while you change screens: if the bit stays on while the message disappears, the display object is missing; if the bit drops out, the trigger or the acknowledge logic is at fault.

Match your symptom to a row before you edit anything:

• Message gone on the other screens, trigger bit still on: the other screens have no alarm display, or the object is there but hidden behind another object or sitting on a hidden layer. This is the most common case, and the fix is in the next two sections.
• Message and trigger bit both drop on navigation: something in the logic or an on-panel reset turns the condition off. Check the rung that drives the bit and any reset or acknowledge button on the screen you just left.
• Message shows on every screen but in the wrong order: visibility is already solved; now the priority, the sort column or a filter on the display is the edit.
• Message never appears anywhere: the alarm editor is pointed at the wrong tag or address, the alarm is disabled, or the condition never goes true. Force the tag and watch the bit while the alarm editor is open.
• Alarm list misses an alarm that was already active before the screen opened: a different fault with its own fix; our article on an HMI alarm list missing active alarms at startup shows how to gate the bit so the list catches it.

How do I get the alarm onto every screen?

Use the project's common alarm window if its editor offers one; otherwise copy the alarm banner object onto each screen an operator can reach, and point every copy at the same alarm class so all of them show the same active alarms.

1. Common alarm window. Some editors provide a banner or window meant to sit on every screen from one definition. If your editor has it, use it: one object covers the whole project and screens added later get it automatically. If it does not, the next route costs one object per screen.
2. Banner copy per screen. Copy the alarm banner from the screen where it works onto each remaining screen. On a 3-inch display keep it one line tall along the top edge so the screen's own controls still fit. Four screens means four banner objects.
3. Alarm pop-up. Where the editor supports it, a message box that opens on the alarm gives stronger coverage because it opens over the screen you are on until it is acknowledged; our article on showing an HMI alarm as a pop-up message box walks through that setup.
4. Two-state text driven by the same bit. The fallback that works on any panel: place a small text object on every screen bound to the trigger bit, reading System off in one state and Run or blank in the other. Our article on showing two text states from one PLC bit shows the pattern.

Routes 2 to 4 leave the alarm database untouched. You are adding drawing surfaces, so the trigger, the message text and the priority all stay exactly as configured.

Worked example: does a system-off alarm reach all four screens?

On a 3-inch panel with four screens and two alarms, the fix is four banner copies or one common window, and the proof is eight navigation checks, about 16 minutes at the bench.

Scenario: a small machine panel with four screens (Run, Manual, Setup, History) and two discrete alarms from the PLC. Tag names below are illustrative; use the addresses your project actually uses.

Run is the only screen with an alarm banner, which is why both alarms look broken the moment anyone leaves Run.

Fix: copy the one-line banner to Manual, Setup and History. Object count: 1 existing plus 3 copies gives 4 banner objects, all pointed at the same alarm class.

Verification arithmetic: 2 alarms times 4 screens gives 8 checks. At about 2 minutes each (force the bit, walk the screens, read the rows) that is 16 minutes of bench time.

Result on every screen: with SYS_OFF forced alone, the banner shows the System off row. With both bits forced, the priority 1 system-off alarm sorts above the priority 5 manual-mode alarm, so the top row reads System off. History already carries a full alarm list, so its two checks pass once the list is set to show active alarms.

If the editor had offered a common alarm window, the object count would drop from 4 to 1 and the same 8 checks would still apply unchanged.

How do I test both alarms on every screen?

Force one alarm bit at a time from the programming tool, walk every screen while it is active, and write down the row you see; eight checks cover the example project, and any screen that misses the message still lacks its display object.

1. Stop the drives and put the machine in a safe state. Force alarm bits from the programming tool only; never trip a real stop circuit or bypass an interlock to make a message appear.
2. Force SYS_OFF on. Visit Run, Manual, Setup and History in order and note the banner row on each. Expect System off four times.
3. Remove the force and confirm the row clears on each screen.
4. Repeat steps 2 and 3 for MAN_MODE. Its display objects are independent copies, so test that alarm on its own.
5. Force both bits at once and confirm the ordering: the priority 1 system-off row above the priority 5 manual-mode row.
6. Acknowledge the alarm on one screen and walk to another. The message stays hidden while the condition remains active; the row comes back only if the condition drops and returns.

Keep the eight results in the project folder. If any screen misses its row, the object is missing or hidden on that screen, so go back to the banner copy route in the previous section; editing priority will not fill the gap.

When is a separate alarm screen the better answer?

On a 3-inch panel a banner can crowd the screen's own content, so if the operator must read full alarm text rather than a one-line strip, jump to a dedicated alarm screen when the bit turns on, or repeat the alarm on an annunciator away from the panel.

The event route: many editors let a bit drive navigation directly, so when SYS_OFF turns on the panel jumps to an alarm screen with the full list and plain-language instructions, and returns when the alarm clears. Our article on an event-triggered screen change from a PLC alarm bit shows the setup. This costs one screen and one event instead of four banner copies, and it suits a small panel where a permanent banner would squeeze out the controls.

The annunciator route: if the alarm must be seen from across the cell, a dedicated annunciator display is the standard tool, and our comparison of an annunciator display for two PLCs covers choosing between an HMI panel and a monitor for that job.

Recommendation: Use the common alarm window if your editor provides one. If it does not, copy a one-line alarm banner to every operator screen, keep the system-off alarm at the top of the priority order you already use, and run the full navigation test, 8 checks in the example, before sign-off. Move to an event-driven alarm screen when the banner crowds a small display, and to an annunciator when the alarm must be visible away from the panel.

Questions