Set up HMI screen navigation with change screen buttons

What you need

• The screen list: every screen in the project, with the ones operators reach marked.
• The change-screen object your editor provides. Names vary: one editor documents a Change Screen Pushbutton, others list a plain change-screen object in the object palette.
• Button labels that read as destinations: Mixing, Oven 1, Main.
• The panel itself. The touch test happens on the panel, with the real touch layer and the real screen names.

Build the menu and the return paths

The pairing rule in one table:

1. List the screens. Write down every screen in the project and mark the ones operators reach. The menu needs one button per marked screen.
2. Set the menu as the startup screen. The startup-screen setting in the editor's project or screen properties decides what the panel shows at power-up. Set it to the menu. Leave the default in place and the panel opens wherever the project's screen list starts.
3. Place one change-screen button per destination on the menu. One editor documents the path as the Object menu, then Control, then Change Screen Pushbutton, with the same object listed in its help under the Object List's Control group. In other editors the same object sits in the object palette under a control or navigation group. Configure the destination to the exact screen name on your list.
4. Place one return button on every destination screen. Configure it for the menu screen. Same position and same label on every screen, Main in the bottom-left corner, so operators learn one spot; a persistent HMI layout carries that idea across the whole project.
5. Size the buttons for the hand that uses them. An adult fingertip pad is about 10 to 12 mm across, so make each button at least 12 mm on its shortest side, and about 20 mm where gloves are worn. On a dense panel the pixel count of that size is easy to get wrong; the too-small keypad fix works the pixel arithmetic for a high-resolution panel.
6. Give sub-screens the same pairing. A settings page reached from an operating screen needs its own return button, and its parent needs the button that opens it. Any reachable screen without a route back is the same defect as a missing return.
7. Download and touch-test at the panel. The next section is the test script.

Example: seven screens on a 10.4-inch VGA panel

Inputs, and where each comes from:

• 7 screens: 1 menu and 6 operating screens (illustrative project size for a small packaging line).
• 10.4-inch, 800 x 600 px, 4:3 panel (a common small HMI format).
• Touch navigation only; no PLC-driven screen changes.
• 30 s per route for the touch test, covering two presses plus the wait for the screen to load (planning figure).

Rule in words: a flat menu needs one change-screen object per route, and a route is one press, out from the menu or back to it.

Arithmetic:

• Menu buttons: 7 screens minus 1 menu = 6 destinations, so 6 buttons.
• Return buttons: 1 per operating screen x 6 = 6.
• Change-screen objects: 6 + 6 = 12, and 12 routes to touch.
• Test time: 12 routes x 30 s = 360 s = 6 minutes.
• Button size in pixels: active width = 10.4 in x 4 / 5 = 8.32 in; 800 px / 8.32 in = 96 px/in; 12 mm = 12 / 25.4 = 0.47 in; 0.47 in x 96 px/in = 45 px, so a 48 px square button clears the 12 mm floor with grid-friendly rounding.

Result: 12 change-screen objects, 12 routes, about 6 minutes of panel testing, buttons at 48 px square.

Decision: build the 12 objects, run the 12 press tests at the panel, and release when all 12 pass. Past about a dozen destinations the flat menu runs out of room. Split into section menus of about eight buttons each, every section carrying its own return button, and configuring menu return and grid navigation walks that layout work.

How to check it worked

• Press each menu button in order. The page that opens must match the button's label.
• On each page, press the return button. The menu must reappear.
• Press and slide off one button per screen before lifting. Panels that act at release leave the screen where it was, which is what protects against a brushed button on a moving line.
• Run every route before release. One safety point belongs here: a misrouted button on a running line can park the panel away from the alarm page, so correct the assignment and re-test before production.

When a route fails at the panel

• Wrong page opens. The button's destination selection points at another screen. Compare it with the label, correct the selection, download again.
• Nothing opens. The object may be a plain button with no screen action, or its destination field is empty. Confirm the object type and the selected screen.
• Outbound works, return fails. The destination screen has no return object, or its return object selects the wrong screen.
• Screens change with no touch. The PLC is driving the panel through a register; retriggering the same screen through the screen-switch register is its own job.
• Physical function keys in the mix. Pair each key with its screen the same way; the function-key screen navigation fix covers that case.

Which scheme to use

Recommendation: Use touch-driven change-screen buttons for operator navigation: one per destination on the menu, one return button on every reachable screen, the menu set as the startup screen, and all routes touched at the panel before release. Keep a flat menu to about a dozen destinations and split bigger projects into section menus of about eight buttons each. Reserve the PLC screen register for events the PLC must signal on its own, such as fault pages, and keep the touch buttons for operators.

Questions