Event triggered screen change on an HMI when a PLC alarm bit turns on

How does a screen change on its own when an alarm bit turns on?

Nothing on the panel changes screens on its own: the change comes from a tag it reads, an event or trigger function watching the alarm bit or a screen-select register the PLC writes, and the panel sees that tag at each poll, 500 ms apart in this article's examples.

Two mechanisms do the job, and they differ in where the decision lives. Panel side, an event or trigger function evaluates a tag condition and runs the screen action itself. PLC side, ladder writes a screen number to a register and the panel navigates to the screen that matches the value.

The timing rule sits under both. The panel is a guest on the link: it sends a request, the PLC answers, and what happened between two requests is invisible unless the PLC still holds the answer. A fault bit that turns on and off inside one scan is exactly such an event, and the polling version of the same drop is what we treat in fix dropped PLC-triggered messages on a serial HMI panel.

That fixes the build order: latch the bit in the PLC first, attach the trigger second. A screen-change pushbutton cannot take part; it acts on touch and nothing else.

What do you need before you build the trigger?

You need four things: the alarm bit's address in the PLC, a latched copy of that bit in ladder, the alarm screen already built with its acknowledge button, and an event or trigger function in the panel software, or a screen-select register if the software has no trigger.

• The alarm bit address, and a rung of ladder to add: the latch is SET on the fault contact and RESET on acknowledge AND fault cleared. The acknowledge side is its own job; map an HMI alarm acknowledge to a PLC bit wires it.
• The alarm screen, built before the trigger: alarm name, corrective action text, an indicator lamp on the alarm bit, an acknowledge button, a return button.
• The trigger mechanism. Search the software help for event, trigger and screen change, and read the item names from your installed version, because they move between releases.
• The real poll interval, read from the communication settings; one vendor documents it as Poll Time (ms), the wait between communication cycles with the PLC.
• If the version has no trigger function, a screen-select register the panel follows; change HMI screens from the PLC and give control back covers that hand-off.

Should the panel or the PLC drive the screen change?

Let the PLC drive it when you can: a screen-select register keeps the priority logic in ladder where your alarm logic already lives. Use the panel's own event trigger when the software has one and the decision is a simple bit on.

Put the decision where the alarm logic already lives. Ladder can compare alarm numbers, pick the highest priority and write that screen number, all before the panel's next poll. The panel trigger wins when the answer is a single bit and you want the PLC untouched.

How do you build the alarm screen and the trigger?

Build it in this order: alarm screen first, latch second, trigger third, because the trigger has nothing to show until the screen exists. A project with one alarm bit, one instruction screen and one acknowledge button needs about seven steps and one download.

1. Build the alarm screen: alarm name, corrective action text, an indicator lamp on the alarm bit, an acknowledge button writing the PLC acknowledge bit, and a return button to the home screen.
2. Latch the alarm in ladder. SET the bit on the fault contact. RESET it only when the acknowledge bit AND the fault-cleared contact are true. One safety rule sits on this rung: a reset on acknowledge alone lets an operator bury a fault that is still live on the machine.
3. Find the trigger in your version: an event or trigger setup item, or a screen object driven by a tag value. Read the exact item names from your installed software; they change between releases.
4. Wire the trigger with the latched alarm bit as the condition, change to the alarm screen as the action, and the rising edge as the mode, so it fires once at off-to-on.
5. For the register method, map the alarm screen to a fixed screen-select value. The number is your choice; 7 is the example here. Ladder writes 7 on the alarm's rising edge and writes the home screen's value once the fault clears and the operator acknowledges.
6. Download the project to the panel and to the PLC.
7. If the shift starts first, put an alarm lamp and the instruction text in a header on the home screen as a stopgap, and replace it with the trigger at the next download.

Example: what does a 10 ms fault pulse look like at a 500 ms poll time?

The panel sees a 10 ms fault pulse 10 ms out of every 500 ms, a 2% catch rate, so 98 of 100 short faults never reach the alarm screen until you latch the bit in ladder.

Take the numbers one at a time. The example scan runs 10 ms, so a fault contact held for one scan keeps the bit on for 10 ms. Where does a 10 ms bit come from? A momentary bit lives exactly as long as the logic holds it, scan by scan, which how many PLC scans an HMI momentary button bit stays on works through. The panel in this example polls every 500 ms; read your real interval from the communication settings, where one vendor documents it as Poll Time (ms).

A poll catches the pulse only if it lands inside the 10 ms window:

Catch rate = pulse width / poll interval = 10 ms / 500 ms = 2%

So 98 of every 100 identical faults never light the alarm screen. Speed the poll to 100 ms and the same pulse is caught 10 ms / 100 ms = 10% of the time, which is still 9 misses in 10. Stretch the pulse to 50 ms against the original 500 ms poll and the catch rate is 50 ms / 500 ms = 10%.

With the step 2 latch, the bit stays on until acknowledge, and an acknowledge takes seconds at the shortest. The worst-case delay to the screen change is one poll interval, 500 ms here, and the catch rate is 100%. The poll interval moves the delay; the pulse width moves the catch rate; the latch moves both to safe.

Recommendation: latch every alarm bit in the PLC, SET on the fault, RESET only on acknowledge AND fault cleared, and fire the screen change on the rising edge from the panel's event trigger. Where the software has no event function, write the screen-select value from ladder instead. Catching a one-cycle pulse is the same problem as a communication handshake that pulses for one cycle; COM_MOD_MAST DONE pulse lasts one cycle: how to catch it treats that case.

How do you test the trigger before the shift starts?

Run the forced-bit tests with nobody at the panel: the screen appears untouched, it holds or returns as the mode says, acknowledge clears it only with the fault cleared, the second alarm fires, and a power cycle boots to the screen you planned. The set takes about 15 minutes.

1. Force the alarm bit on from the PLC software. The alarm screen must appear with no touch, within one poll interval: 500 ms worst case in the example.
2. Navigate away while the bit is still on. A rising-edge trigger leaves the operator where they went; a level trigger walks the panel straight back. Match what step 4 chose.
3. Press acknowledge while the fault is still forced. The bit must hold, because the reset rung wants acknowledge AND fault cleared, and the screen must stay up. Clear the fault and press acknowledge again: the bit drops and the return button takes the panel home.
4. Force the bit off, then on again. The screen must appear a second time.
5. Cycle panel power with the bit still forced and note which screen boots. If it comes up wrong, set the startup screen; HMI panel shows no power up screen: set the startup screen covers that setting.

If the screen never appears, check the tag address and the link status first: the panel cannot trigger on a bit it cannot read.

Why does the alarm screen snap back after the operator walks away?

It snaps back because the trigger is level based: every poll while the bit is still on re-issues the screen change, 500 ms later in this article's example. Fire it on the rising edge instead, or clear the bit on acknowledge.

A level condition re-evaluates on every poll and re-issues the action each time it finds the bit true. The edge is the fix: a rising-edge action fires once at off-to-on and leaves the operator alone until the bit goes off and comes back. For an alarm instruction screen, take the edge and let the ladder reset decide when the alarm is over.

The return path needs the same planning. The panel has no memory of the operator's previous screen, so decide during the build: a return button to a fixed home screen is the simple case, and the FAQ below carries the two ways back to wherever the operator was. The fire-once-and-reset question comes up again with PLC flags, and PLC flag triggers an HMI event once: check the reset path works through the reset side.

When is a pop-up better than a full screen change?

Pick a pop-up when the operator still needs the process view to fix the fault: the alarm instructions occupy a corner window while trend and faceplate stay live. Take a full screen when the instructions need the whole display, roughly 6 lines of text or more.

On a typical 800 x 480 panel, a corner window holds about 6 lines at normal text size, and more than that means a full screen with the acknowledge button kept on the alarm surface either way. Where the platform raises alarms as events, the pop-up can hang off the alarm itself, the ActivateScreen on Incoming pattern from the table above. Where the panel ships monitoring objects, use them: an Alarm indicator object shows whether alarms are pending and how many, and alarm list and alarm history objects give the operator a built-in screen for viewing, acknowledging and clearing alarms.

Keep one trigger per alarm. Shared triggers lose events; one documented case lost four alarm logs because all four shared a single M900 trigger bit, and a screen trigger shared the same way drops alarms identically. The case is written up in four alarm logs missing because all four shared one M900 trigger.

Questions