Stop PLC messages overwriting the operator menu on an HMI

Why does the PLC message overwrite my menu entry?

Because the menu state lives inside the terminal and no bit reports it to the PLC: the controller keeps writing its normal-operation messages, and on a text display the newest message takes the screen.

Two independent activities are fighting for one display. The operator is inside the terminal's setup menu, changing a tare value or a timeout. The PLC is running its normal display logic, and in a weighing setup the live-weight screen is the normal condition, true almost any time the scale has power. Whichever write lands last owns the screen, and the PLC writes far more often than any operator edits.

No configuration change escapes this. The menu is internal to the display, and this class of five-key text terminals exposes no mode or screen-status register the controller could read. Any fix has to hand the PLC a signal it can act on, and the one always available is the operator's own finger on a function key.

The collision runs the other way on other platforms, where an HMI that overwrites PLC tags at startup wipes retained values the controller expected to keep. Make the ownership of each write explicit and both directions behave.

Is the overwrite message contention or a bad key?

Stop the message rungs under controlled conditions and try the menu again: if the menu stays up for a full edit with the messages inhibited, the key and the menu are healthy and you have contention.

Each symptom points somewhere specific:

• The menu opens, then the live screen replaces it partway through an edit: a message trigger active in normal operation. This is the contention case.
• The menu never opens, messages or not: the key assignment or the key itself. Check the key's function mapping in the terminal configuration.
• The menu opens and the edit saves, but the screen jumps at a steady interval: a timed message routine, triggered from a timer instead of a process condition.
• The display flickers between two data screens with nobody in the menu: two message triggers alternating. Both need the gate later, or they keep fighting after the fix.

The controlled test settles it. Take the machine to a safe state, force the routine message conditions off, enter the menu and hold it through a full edit. If the menu behaves, the entry hardware is healthy and the message paths are the problem. If the menu still misbehaves with every message silent, the terminal itself needs the attention.

How do I stop the messages today, before touching the ladder?

Pause the sequence that issues display messages, with the machine held in a safe state, and let the operator finish the menu work; that clears this session and leaves the next menu entry just as exposed.

If the machine can sit safe with its display logic paused, pause the message rung or step, let the operator finish or cancel the edit, then restore. That recovers production and protects nothing tomorrow, so treat it as recovery, never as the fix.

Before the ladder opens, run the audit that makes any gate trustworthy: list every path that writes to the display. Every rung with a message instruction, plus any alternate message routines called from a different mode or step, not just the message visible on the floor. The audit is finished when you can name each path. In the worked example below it turns up four rungs, including a calibration prompt nobody remembered.

Keep the audit honest about the link layer too. Messages that arrive damaged or go missing point to the transport, a separate fault covered under fixing dropped PLC-triggered messages on a serial panel; settle that before judging the gate.

Which of the five keys should I give up?

One key, configured as an alternate-type button so one press latches the block on and the next releases it; choose the key whose present job matters least, then confirm that job can move or disappear.

The terminal has five function keys, and one becomes the block control. Alternate-type matters: first press latches the block on, second press releases it. A momentary key would drop the block the instant the operator lets go, which is the wrong behavior halfway through an edit.

Map the key to one dedicated bit in the PLC and name it for what it does; this article's example calls it MsgBlock. Keep that bit out of every other job. Give the operator a visible state, a lamp or a screen field driven by the same bit, so the block is never an invisible toggle someone forgets.

Function keys usually carry screen-switching jobs already. If reassigning one breaks how operators move between screens, work through HMI function key screen navigation first. Before any ladder edit, press the key twice and confirm the bit changes state both ways.

Where does the inhibit bit go in the PLC program?

In series with every routine message write: one normally closed contact of the block bit ahead of each message instruction, or ahead of a single shared enable contact only if every message path really passes through it.

If the message paths share one enable point, a single contact there does the same job, but trace every path through it first; one ungated rung keeps the overwrite alive and will find the operator's next menu session.

Two rules keep the gate safe. The block bit belongs to display writes only: never let it sit in a rung that stops the machine, raises an alarm or gates the weighing itself. Those functions must run identically with the block on or off. And decide the fault messages deliberately. Leave fault text ungated, because an operator 30 seconds deep in a menu still needs to see a machine fault; an overwrite you want is not the problem you are solving. If the fault wording needs work, that is the job in operator text in HMI alarms.

After the edit, read the bit's cross-reference with the controller online. Every contact should land in a message rung, nowhere else.

What happens to messages that fire while the block is on?

A latched message condition waits and writes the instant the block releases, so the operator sequence is fixed: block on, edit, leave the menu, block off; releasing while still inside the menu rebuilds the original overwrite.

The trigger type decides the behavior. A message whose condition latches stays pending and writes on release. An edge-triggered message blocked during the window is simply gone, like any message the operator never saw; it will not replay later.

That sequence is a rule, not a habit. Test the release path on purpose: latch one routine message condition with the block on, release, and watch the message appear once the operator is clear of the menu.

What does a blocked menu session look like in a worked example?

Four message rungs, one key, one bit: the audit on a weighing terminal finds the live-weight screen, a batch-total message, a calibration prompt and a fault text; the key gates the first three, and the fault text stays ungated.

The setup is a weighing terminal driven by a compact brick PLC. Rung 1 writes the live-weight screen whenever the scale runs, level-triggered. Rung 2 writes a batch total when a batch completes. Rung 3 writes a calibration prompt from a setup step. Rung 4 writes fault text from the fault contacts.

The gate: key 5 of the 5 function keys, configured as an alternate-type button, writes the bit MsgBlock. Normally closed MsgBlock contacts go ahead of rungs 1, 2 and 3. Rung 4 stays ungated by design.

The session, with example timing you can rescale to your own edit:

1. 0 s: the operator presses key 5. MsgBlock turns on and a screen field reads "messages held".
2. 5 s: the operator enters the menu and starts changing the tare setpoint from 12.5 kg to 14.0 kg.
3. 5 s to 35 s: the edit runs 30 s. Rung 1's condition is true the whole time, so ungated it would attempt a write every scan; at a 10 ms scan that is (35 s - 5 s) / 0.010 s = 3,000 attempts against the menu in one session. All 3,000 meet the MsgBlock contact and none reaches the display.
4. 20 s: a batch completes, so rung 2's condition latches and waits.
5. 35 s: the edit saves; the operator leaves the menu at 40 s and presses key 5 again. MsgBlock turns off.
6. 40 s: rung 1 writes the live screen at once, and rung 2's held batch total follows. Both land on the run screen with the operator clear of the menu.

The numbers that decide it: one key out of five, one bit, three gated rungs out of four, a 40 s block window and 3,000 suppressed writes at the example scan time. The 10 ms scan and the 30 s edit are example inputs; divide your own block window by your own scan time and you know what your gate holds back.

How do I test the fix before operators use it?

Run the whole operator sequence with message conditions live and the machine in a controlled state, and pass every check in one go: key toggles, menu survives a real edit, held messages return after release, faults still show.

1. With the machine idle, press the block key and confirm the bit changes state; press again and confirm it returns. Two presses, two transitions.
2. Make one routine message condition live, such as the running scale.
3. Press the key, enter the menu, change one value, save it and hold the menu through a full edit. The menu must keep the screen the whole time.
4. While still blocked, latch a second message condition, such as the batch-complete bit.
5. Leave the menu, then release the key. The held message writes right after, onto the run screen.
6. Trip a fault input with the block still on. The fault text appears and the machine stop behaves exactly as it does with the block off.
7. Read the block bit's cross-reference online once more: every contact sits in a message rung.

The fix passes when a full editing session survives live message conditions and the machine runs identically with the block on and off. A quiet screen in one lucky test is a weak pass; the strong pass is every path from the audit either gated or deliberately left ungated.

Recommendation: dedicate one of the five function keys as an alternate-type message-block button mapped to a single PLC bit, gate every routine message rung from the audit with that bit, and leave fault text and machine-stop logic outside the gate. Keep a visible held state on the screen, and keep the arrangement until the terminal is replaced by one whose current screen the PLC can read; then gate on the screen number and give the key back.

Questions