Reusable HMI screens can serve similar devices when every indication and command follows the same validated equipment selection. Check platform support, interface consistency and selection transitions; use separate screens when routing or device differences make a shared interface unreliable.
One manual-control screen can serve several similar devices if the HMI supports the required tag routing and every device-dependent indication and command follows the same validated selection. Reusing the artwork alone is not enough. The equipment name, feedback, operating mode and command destination must all refer to the same physical device.
Use separate screens when that alignment cannot be established or when the devices behave differently enough to make shared controls misleading. A reusable layout reduces editing work, but it does not replace controller interlocks, command validation or the machine’s safety functions.
What makes a screen reusable
A reusable screen keeps its layout while changing the equipment data behind it. Selecting one pump connects the shared fields and buttons to that pump’s interface. Selecting another pump connects them to the second pump instead.
Depending on the HMI platform, the supported mechanism might be tag multiplexing, indirect addressing or a parameterized screen component. Tag multiplexing means choosing one tag from a defined collection using a selector. The exact features available depend on the configured panel and software version. Check the manufacturer’s documentation for that target rather than assuming that an object available elsewhere will work.
A group of graphics is not a routing mechanism. Grouping can make a layout easier to edit, but the commands and indications still need explicit equipment references.
Likewise, a shared background or navigation template does not make equipment controls reusable. The important question is which device supplies each displayed value and receives each command after selection changes.
Which devices can share the layout
Reuse works best within a device family whose interfaces have the same meanings. Similar tag names and matching data types are not sufficient.
For example, two pumps may both expose a run request, running feedback, manual-mode indication and fault state. Those functions may fit one shared screen. A valve with open and close commands has a different control model, even if its signals are also Boolean values.
Compare these details before grouping equipment:
- Commands: The available actions and their behavior must match.
- Feedback: Each indication must represent the same physical condition across the group.
- Modes: Manual, automatic, local and remote must have consistent meanings.
- Permissives: The screen must explain why the selected equipment can or cannot accept a request.
- Numeric fields: Units, limits, scaling and write permissions must follow the selected device.
- Exceptions: Any device-specific function must remain clear rather than disappearing into a generic label.
One pump screen and one valve screen is often clearer than a single layout that changes its control language for every selection.
What must follow the selected device
Treat the selector-to-device mapping as a controlled interface. Each valid selection must identify one device consistently across every equipment-dependent property.
| Screen element | What must remain aligned |
|---|---|
| Equipment title | The physical device represented by the active data and command route |
| Command buttons | The selected device’s permitted command interface |
| Running, open or closed feedback | The selected device’s actual feedback, not merely its last request |
| Mode and control authority | The selected device’s current mode and accepted control source |
| Faults and permissives | The conditions belonging to the selected device |
| Numeric fields | The selected device’s value, engineering units, limits and destination |
| Data-quality indication | The validity and freshness of the selected device’s information |
A common mapping error is an equipment list ordered differently from the command list. The title and feedback can look correct while a button targets another device. Review the complete mapping together, not as isolated tag lists.
Check less obvious properties too. A button’s enable condition, an animation, a limit value or a confirmation message can retain a fixed equipment reference even when its main value has been redirected.
An invalid selector must not silently fall back to the first device. Treat it as an invalid control context and prevent equipment requests until a valid selection has been established.
Why changing selection needs a defined sequence
Setting a selector and opening a screen does not necessarily mean every displayed value has refreshed. HMI events, communications and controller scans can complete at different times.
The design therefore needs an explicit transition between equipment selections. During that transition, equipment commands should be unavailable until the application has established the intended target and the required information belongs to that target. Changing the title first is not evidence that the rest of the screen is ready.
The displayed equipment identity should come from the same validated context used for command routing. A decorative label that changes independently of the active route can give false confidence.
Consider rapid selection changes, returning from another page and reopening the screen after a communications interruption. None should rely on a selector left over from a previous visit. Selection itself must not issue a start, open, reset or mode-change command.
Freshness is a separate concern from identity. Correctly routed feedback can still be stale. Where the equipment identity is right but updates arrive late, the checks for factory screen update delay help distinguish delayed data from a routing fault.
Where command decisions belong
The HMI presents a request. The controller should validate the intended equipment, command, operating mode, control authority and relevant process conditions before acting. Hiding or disabling an HMI button is not a substitute for that validation.
For a shared command interface, the request needs an unambiguous target. Depending on the architecture, that may be an explicit equipment identifier in a validated request or a supported route to a dedicated equipment command interface. Do not assume that a mutable screen selector is enough to identify a request already being processed.
Selection changes must not redirect a command that is still active. This is especially important for press-and-hold controls. A press associated with one device and a release routed to another can leave the first request unresolved. Such controls need a documented, target-bound command lifecycle, including what happens if navigation or communications interrupts the interaction. If the platform cannot support that reliably, use a different approved control arrangement.
Manual mode does not remove the need for permissives or interlocks. Safety functions must remain in the machine’s appropriate safety-control design, independent of ordinary screen navigation and tag selection. Communications-loss behavior also needs a machine-specific assessment; there is no universal screen setting that makes every machine safe.
How to check the design before commissioning
Begin in a manufacturer-supported simulator or an approved test environment that cannot energize machinery. A successful compilation only confirms part of the design. It does not establish that every visible value and command destination belongs to the same device.
The review should cover both normal operation and transitions:
- For every device: Compare the displayed identity, mode, feedback, faults and numeric values with the intended equipment interface.
- For every command: Observe the request destination and confirm that no other equipment interface receives it.
- For every selection change: Check that old values are not presented as current information for the newly selected device.
- For invalid selections: Confirm that the screen does not choose a default command target.
- For rapid navigation: Check repeated selection, leaving the page and returning to it.
- For simulated communications loss: Check data-quality indications, command availability and recovery behavior.
- For active interactions: Check what happens when selection or navigation is attempted during a pending request or held control.
Where the architecture uses request acknowledgments, distinguish a request being received from the equipment reaching the requested state. Running feedback must represent running, not merely an accepted start request.
Keep the mapping review with the project documentation. Adding, removing or reordering equipment can affect multiple indirect references. Recheck the full mapping after those changes.
Any subsequent checks on the machine belong under its approved commissioning procedure, with the required isolation and controlled test conditions. Do not bypass a protective function to demonstrate that a shared screen works.
When separate screens are the better choice
Choose separate equipment screens when a required property cannot use the supported routing method, when selection sequencing cannot be controlled, or when device differences make a common interface difficult to interpret.
Separate screens can also be preferable where equipment has substantially different modes, operating consequences or hold-to-run behavior. They reduce some routing complexity, although copied screens still need a review for incorrect equipment references.
A read-only overview is a separate design choice from a manual-control interface. The distinction between a factory status display and an operator HMI matters when deciding where equipment commands should be available at all.
The deciding measure is not how many layouts you can eliminate. It is whether the selected identity, displayed condition and accepted command destination remain aligned through normal use, navigation and faults. If that cannot be demonstrated with the supported platform features, keep the equipment controls separate.
Questions
Can one HMI screen control several pumps?
Yes, if the configured HMI supports the required routing and the pumps have equivalent control interfaces. Every device-dependent property must follow the validated selection, including commands, feedback, modes, limits and equipment identity. Separate screens are preferable when any required property cannot be routed consistently.
What does tag multiplexing do on a reusable screen?
Tag multiplexing selects among equipment tags using a selector value. It can let a common field or button refer to different devices without changing the layout. It does not itself validate commands, synchronize screen updates or provide machine safety functions.
Is changing the equipment title enough to confirm the selection?
No. A title can update before feedback or command routing changes. The equipment identity must be tied to the same validated context used for commands, and control availability must account for incomplete selection changes and invalid or stale data.
When should devices have separate control screens?
Use separate screens when device behavior differs significantly, required properties cannot follow the supported selection mechanism, or command transitions cannot be managed reliably. Dedicated screens still require checks for copied references, controller validation and appropriate behavior during communications loss.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.