Reuse one panel definition for equipment with the same behavior. Choose fixed instances for explicit equipment mappings, or a shared panel only when identity, feedback and command routing can change coherently. Define command availability, visibility and selection transitions before building the layout.
Use one reusable panel definition for equipment that shares the same controls and indications. Then choose whether to place a separately connected instance for each equipment item or use one shared panel that changes its data context when you make a selection. Neither approach requires an independently navigable screen inside another screen. The important requirement is that the equipment identity, feedback and command destination agree before controls become available.
What a reusable equipment panel means
A reusable HMI equipment panel, often called a faceplate, groups the controls and indications for one equipment type. Its definition contains the layout and common behavior. Its interface supplies the connections that make a particular instance represent a particular valve, motor or other device.
That separates two different decisions:
- Definition reuse: identical equipment uses the same maintained panel design.
- Runtime selection: selecting equipment either reveals its dedicated instance or changes the target of a shared instance.
You can reuse a definition without changing any data connections at runtime. Several instances can each have fixed connections to their own equipment.
Start with equipment behavior, not appearance. Two on/off valves may share a definition even when their tag names differ. A modulating valve may need a position request, measured position and different command handling. That can justify a separate definition rather than a collection of hidden controls inside an increasingly complicated common panel.
This is an operator-control design. If the requirement is only to show production information, first distinguish a factory status display from an operator HMI. A read-only display does not need the command interface described here.
Choose fixed instances or a shared context
Fixed instances are usually easier to inspect because each instance has an explicit equipment mapping. A shared panel can reduce the number of placed objects, but it introduces a selection transition that must be designed and checked.
| Design point | Fixed instance for each equipment item | One shared panel |
|---|---|---|
| Common layout | Reused from one definition | Reused from one definition |
| Data connections | Remain assigned to that instance | Change with the selected equipment |
| Selection action | Shows the corresponding instance | Requests a new equipment context |
| Main mapping risk | An instance contains a copied connection to another item | Identity, feedback and commands switch at different times |
| Verification focus | Every instance connection | Every connection plus the selection transition |
| Better fit | Explicit mappings and straightforward visibility control | A platform with documented support for coordinated context changes |
Choose fixed instances when the HMI cannot reliably change all required connections together. Duplicating a complete process screen is not necessary just because runtime rebinding is unsuitable.
Choose a shared panel only after confirming how the selected platform handles indirect addressing, parameter changes, scripts and communication quality. A feature that changes a displayed value does not necessarily change the destination of a command button.
Use the manufacturer's documentation for the exact object and connection mechanism. A grouped object, popup and reusable component may have different capabilities even when their appearance is similar.
Define the complete equipment interface
Write the panel interface before arranging its buttons. Every value crossing the boundary needs a purpose, direction and equipment association.
| Interface group | Typical contents | Requirement to specify |
|---|---|---|
| Identity | Equipment identifier and description | The displayed identity matches the command target |
| Command requests | Open, close, start, stop or position request | Each request reaches only the intended equipment |
| Process feedback | End positions, running state or measured position | Indications come from process feedback, not button animation |
| Operating mode | Local, remote, manual or automatic state | The panel shows the actual mode and its effect on operation |
| Availability | Permission, ownership and interlock state | Controls explain why a request is unavailable |
| Diagnostics | Faults, rejected requests and communication quality | Missing or rejected information is distinguishable from normal operation |
Keep equipment-specific addresses outside the common graphical definition where the platform supports that separation. This makes the definition reusable and leaves instance mappings available for review.
Optional features need explicit behavior. If one equipment item has no position feedback, hide that indication or mark it as unavailable. Do not display a default value that resembles a real measurement.
Avoid making a single definition cover fundamentally different command models. A few optional indications can be manageable. Different operating sequences, command ownership rules or confirmation requirements often deserve separate panel types.
Make selection a controlled transition
A shared panel must not become operable simply because its title has changed. The title, feedback and command destination may be updated through different mechanisms.
Specify a selection state model:
- No selection: there is no valid command target, and equipment controls are unavailable.
- Selection changing: a new target has been requested, but the panel is not yet ready for operation.
- Selection ready: the identity and required connections belong to the same equipment, and the required data is valid.
- Selection invalid: a connection or quality check has failed, so commands remain unavailable and the reason is visible.
The transition should inhibit equipment commands before changing the context. Operation becomes available only after the design establishes that the required connections and identity agree.
Do not use an arbitrary delay as proof that the transition has completed. A delay cannot establish that every connection has changed or that current feedback has arrived.
Also define what happens to pending actions. A confirmation opened for one valve must not apply to a different valve after reselection. Clear it or keep it explicitly associated with the original target and require the intended identity to remain visible. An outstanding request must not be redirected by a later selection.
If the platform cannot support these requirements clearly, use fixed instances. Simpler mappings are preferable to a shared panel whose command destination is difficult to establish.
Keep command requests separate from feedback
A pressed button means that an input action occurred. It does not prove that equipment moved, started or reached its requested state.
Show the distinctions that matter to the process:
- A command was requested.
- The controller accepted or rejected the request, where that information is available.
- Equipment is moving or changing state, where feedback supports that indication.
- The requested condition has been reached.
- Feedback is unavailable or the expected response has not occurred.
Use the machine's defined command protocol. A request might be momentary, maintained or acknowledged through a handshake. Do not choose its behavior solely from the visual style of an HMI button.
The controller must enforce the applicable operating permissions and process interlocks. Disabling an HMI button helps explain availability, but it must not be the only control preventing an impermissible machine action. Safety functions must remain independent of ordinary panel visibility and selection logic.
For press-and-hold controls, pay particular attention to navigation and reselection. A hidden object may no longer receive the input-release event expected by a simple implementation. Define the request lifecycle in the control design, including communication loss, rather than relying on the panel staying visible.
Define what opening and closing actually do
Opening a panel should identify equipment and expose the appropriate information. It should not silently change the operating mode or issue an equipment command.
Closing a panel normally means hiding the panel. It is not a stop command, a reset or a cancellation of a controller sequence. If a workflow needs one of those actions, provide an explicitly labeled control with the required permissions and behavior.
Before allowing close or reselection, define how any active interaction finishes. This is especially important for maintained requests, confirmation dialogs and edits that have not yet been submitted.
Specify startup behavior as well. A panel can begin hidden with no selection, or it can restore a previous selection if that is an intentional requirement. Restoring an equipment name alone is not sufficient: the data context and command availability still need to become valid.
Keep the equipment identifier inside the panel, close to the controls. Do not rely only on its position beside a process symbol. If several panels can remain visible, each needs an unmistakable identity and its own command routing.
When data quality becomes invalid, distinguish unavailable feedback from a confirmed stopped or closed condition. If a last-known value remains visible, label its status clearly and apply the command restrictions defined for that condition.
Specify acceptance checks before commissioning
Prepare an equipment-to-interface mapping and expected outcomes before commissioning. Carry out command checks under the machine's approved commissioning procedure, without bypassing protective functions.
For fixed instances, review every connection, not just the equipment label. A copied panel can show the correct name while retaining another item's command address.
For a shared panel, include transitions as well as steady selections:
- Select equipment with different known states and confirm that identity and feedback agree.
- Change selection rapidly and confirm that commands remain unavailable during an unresolved transition.
- Check that stale feedback cannot appear as valid data for the newly selected target.
- Confirm that an open confirmation or unfinished edit cannot transfer to another target.
- Check the defined response to communication loss and recovery.
- Confirm that closing the panel has no unintended process effect.
- Verify that each permitted request reaches only its intended destination and that the resulting indication comes from feedback.
The design handoff should contain the reusable interface, instance mappings or context-selection rules, visibility behavior, command protocol and acceptance criteria. Those details make the panel reusable in practice. A common drawing alone does not.
Questions
Do you need a different HMI panel for every valve?
You can use one panel definition for equipment with the same controls and indications. Each equipment item can then have its own instance with fixed connections. A separate definition is useful when the command model or operating workflow differs materially, rather than merely because equipment names or addresses differ.
When should you use one shared equipment panel?
A shared panel is appropriate when the platform can coordinate equipment identity, feedback and command routing during selection changes. Commands should remain unavailable until the required context is valid. If that coordination cannot be established clearly, fixed instances with explicit equipment mappings are the better choice.
Should closing an equipment panel stop the equipment?
Closing normally changes visibility only. It should not silently issue a stop request, change operating mode or cancel a controller sequence. Any active command interaction needs defined completion behavior, and stopping equipment should use an explicitly identified function governed by the machine's control design.
Why should command buttons and equipment feedback use separate signals?
Button appearance indicates an input action, not physical movement. Equipment status should come from the relevant process feedback. Where the control system provides it, also distinguish request acceptance, rejection and movement in progress so that a missing response is not confused with a display problem.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.