Lock HMI screen navigation while a bypass tag is on

Decide what the lock has to stop

The phrase 'before they can proceed' has two meanings, and they need different mechanisms. If it means the operator stays on this screen until the bypass is off, a visibility condition on the navigation objects delivers exactly that. If it means the machine must not act, the logic that enables the action has to check the bypass tag on every path that can start, advance or clear it. Plan both together: the conditioned screen gives the operator a display that releases only when the tag goes off, and the logic permissive holds the release point even if the operator ends up somewhere else. A screen whose exits disappear is a rule for people at the panel. The logic is the enforcement.

What you need

• The bypass tag confirmed live at the HMI: it must read the same value the controller holds in both toggle positions.
• The audit list from the next section: every object in the project whose action ends in a screen change.
• The condition properties on button objects. Most HMI platforms offer a visibility condition that hides or shows an object from a tag or expression, and an enable condition that leaves the object visible but refuses presses. Either works; hiding is the stronger lock, because a disabled button still invites an attempt.
• Download access under your site's change procedure, and the change record.

Where an object accepts no tag-driven condition at all, some projects hold the restricted screen behind an access level instead. That mechanism suits a role rule; this one suits a process state.

Find every route off the screen

Walk the project at the design station and list five route types:

1. Screen-change buttons drawn on the restricted screen.
2. A menu button that opens a screen full of further exits.
3. A shared navigation bar configured once and placed on every screen.
4. Alarm or event banner objects that jump to an alarm list or diagnostics screen.
5. Function keys or hardware keys mapped to screen changes. These are easy to miss because they are not drawn as buttons, and their failure mode is the one described in fixing HMI function key navigation across screens.

Then add the sixth route, which lives in the logic: any controller write to the HMI's screen number, such as an automatic jump on a major alarm. Changing HMI screens from the PLC covers how those writes work and how control is handed back. Note every object and every write with its screen, because the condition must reach each one.

Set the visibility condition on every object

1. Verify the tag first. Toggle the switch and watch the tag value in the runtime while the restricted screen is open. It must match the controller in both positions; a stale or reversed read makes a correct condition behave backwards.
2. Open each object from the audit list and set its condition so the object shows only while the bypass tag is off. Where the property takes an expression, write the off state as the visible sense.
3. Fix the polarity once and copy it everywhere: hidden while the tag is on, visible while off. Mixed senses leave some exits in place and make the screen look broken instead of locked.
4. Apply the same condition to the exits on other screens that can undo the intent, such as the alarm banner link that jumps the operator away while the bypass is on.
5. Gate the controller's screen-number writes on bypass off, so the logic cannot move the display while the tag is on. Binding a condition to a controller tag is the same mechanics as gating an HMI button on a timer done bit, shown step by step there.
6. Download under your site's change procedure, then run the check below.

Example: nine screens, thirteen objects

A pack cell HMI has 9 screens. The line setup screen holds the bypass toggle, and while the tag is on, the operator must stay on that screen.

The audit counts the exits:

• Line setup screen: 3 screen-change buttons plus 1 main menu button = 4 objects
• Shared navigation bar, configured once and placed on all 9 screens: 4 buttons = 4 objects
• Alarm banner with 1 link to the alarm list screen: 1 object
• Function key map: 4 keys written to screen changes = 4 objects

That is 4 + 4 + 1 + 4 = 13 display objects, each set to show only while the bypass tag is off.

The logic holds 2 screen-number writes: an automatic jump to the alarm list on a major alarm, and a recipe change that opens the recipe screen. Both writes take a bypass-off condition in the rung. 13 objects plus 2 logic writes is the whole job.

The test plan follows from the count: 2 tag states tried from 2 entry points, the setup screen itself and a forced alarm jump, makes 4 passes. With the tag on, all 13 objects hide and both writes stay blocked, so the display sits on line setup until the tag goes off. With the tag off, all 13 return and both writes work. If the team wants the alarm jump to survive the bypass, leave the jump unconditioned and condition the alarm list screen's exits instead, then add those objects to the count.

How to check it worked

• Tag on, from the restricted screen: every audited route is gone. Press where each hidden object sat, and press each mapped function key. Nothing changes the display.
• Tag off: all conditioned objects return, and each route lands on the screen it should.
• During both passes, compare the tag shown at the HMI with the controller value.
• Test the permissive at the logic, separately: with the tag on, command a start. The controller must refuse it whatever screen is showing, because a hidden exit is not proof the machine is held; the proof is the permissive rung.
• Write the tag states, routes and results into the change record.

Keep the permissive in the logic

The visibility condition governs what the operator can select at the panel, and nothing else. The tag keeps its value in the controller, and every command path keeps working; only the display's exits are gated. So the rule that matters, that the bypass must be off before the cell proceeds, is written where proceeding is authorized: the rung or step that enables the start, the sequence advance or the clear reads the bypass tag directly and refuses while it is on.

If the bypass touches a safety-related function, it belongs to the machine's approved safety design, which the machine safety standards for that design govern: the machine must stay safe while the safety function is bypassed, by measures inside that design. A display object's visibility setting guides the operator and is never credited toward that design.

Recommendation: Use a bypass-driven visibility condition on every navigation object in the project when the requirement is that the operator stays on one screen until the bypass is off, and key the machine's own permissive on the same bypass tag inside the logic that enables the action whenever the requirement touches equipment behavior. Audit all six route types before you write the first condition, test both tag states from every entry point after each download, and treat the display lock as operator guidance: when a bypass forms part of a safety function, the approved safety design governs and the screen never counts toward it.

Questions