A project with repeated stepper-control function-block instances needs one reusable operator interface, not a separately maintained visualization for every controller. The central constraint in the described environment is that visualization objects access global memory rather than an individual function-block instance directly. Whether the platform supports parameterized or instanced visualizations cannot be determined without the visualization product, version, and runtime capabilities.
Define the Required Instance Boundary
Keep stepper control and visualization-facing logic separate. The existing design already provides one control function block per stepper and one visualization-control function-block definition. The missing boundary is a supported way to bind each displayed visualization occurrence to the corresponding visualization-control instance.
That binding must preserve instance context. Without it, every visualization occurrence resolves the same global symbols, forcing separate global instances, duplicated screens, or an explicit global routing layer.
Separate Confirmed Constraints From Unknown Capabilities
| Item | Status | Engineering consequence |
|---|---|---|
| Multiple stepper controllers use separate instances of one control function block | Confirmed | The control logic is already reusable. |
| The described visualizations access global memory | Confirmed for the reported project | A visualization cannot bind directly to local instance memory under the current configuration. |
| A separate visualization can be connected through a global visualization-control instance | Confirmed | The design works, but screen and support-code duplication grows with the module count. |
| Reusable visualization references with instance parameters | Unknown | Product and runtime documentation must confirm whether a child visualization can receive an instance reference or structured data context. |
| Dynamic visualization creation at runtime | Unknown | Do not design around dynamic instantiation until the platform explicitly documents it. |
Evaluate the Reusable-Visualization Path
- Identify the visualization product, engineering version, and target runtime. The supplied evidence does not contain these details, so no product-specific feature or syntax can be selected safely.
- Check whether the platform supports a reusable visualization object, embedded visualization reference, template, frame, or equivalent construct with parameters.
- Confirm the permitted parameter type. The required capability is either a reference to the visualization-control function-block instance or a structured interface that exposes its commands, states, and status values.
- Create two occurrences bound to different controller instances and operate them independently. A command or status change in one occurrence must not alter the other occurrence unless the underlying control logic intentionally couples them.
- If instance parameters are unavailable, retain global access and implement an explicit routing layer instead of assuming that direct function-block binding is possible.
Use a Global Routing Layer as the Fallback
When the visualization can resolve only global symbols, expose the required visualization-control instances through global memory and route each screen occurrence to the intended controller. Keep the interface limited to operator commands, displayed states, alarms, and status data; do not expose unrelated internal function-block state merely to satisfy visualization access.
This fallback can reduce logic duplication, but it does not prove that visualization objects themselves can be dynamically instantiated. Verify isolation by commanding each stepper from its assigned interface and confirming that feedback returns from the same function-block instance.
FAQ
Can a visualization access a function-block instance directly?
Not under the access constraint described in this project, where visualizations resolve global memory. Direct binding requires a documented visualization parameter or instance-reference capability from the selected product and runtime.
How can I avoid duplicating visualization support logic?
Define the visualization-control logic once and create separate instances for the controllers. If the visualization cannot accept an instance reference, expose those instances through a controlled global routing layer.
How do I verify that reusable visualization instances are isolated?
Bind two visualization occurrences to different controller instances, issue commands independently, and confirm that each occurrence displays feedback from only its assigned instance. Any cross-control indicates shared binding or incorrect routing.