CODESYS Platform · 05
Visualization: the operator interface inside the control project
Screens are not drawn in a separate HMI package: they are designed inside the control project, on the same variables, and published from one source to both panel and browser.
What one shared variable pool actually buys you
In the classic approach the screen is drawn in separate software, the variables are declared a second time, and a communication layer is built between the two. The most common complaint we meet in the field — “the value on the screen is wrong” — usually traces back to mismatched tags in that second table.
When the interface lives inside the control project, that entire class of problem disappears: the indicator binds straight to the variable and any rename is caught by the compiler.
- Alarm handling Alarm classes, acknowledgement logic and history are built from ready-made components.
- Trends and logging Selected variables are plotted against time and the data can be written to local disk.
- Recipe management Product parameters are stored so the operator changes over with a single selection.
- Multilingual interface Texts are held in a separate table, so adding a language does not mean redrawing the screen.
- User roles Operator, maintenance and engineer permissions are separated so critical parameters stay protected.
Panel or browser?
Both use the same design; what differs is where the screen is rendered. On most machines they are licensed together: the panel on the machine, the browser for remote maintenance.
| Requirement | Panel on the machine | Browser |
|---|---|---|
| Touch operator station | Suitable | Possible |
| Maintenance screen on a tablet | Not supported | Suitable |
| Operation during a network outage | Unaffected | Needs a connection |
| Multiple concurrent users | Single screen | Licence dependent |
| Remote software support | Limited | Suitable |
The rule we apply to screen design
A screen an operator stares at for a whole shift is a working tool, not a design showcase. Our criterion is simple: the machine’s state should be readable at a glance, the three most-used actions should be one touch from the home screen, and an alarm should say what to do in its text, not merely in its colour.
Frequently asked questions about visualization
Do I need to install software to open the screen?
Not for the browser-published version: the screen is served by the web server on the controller, so a current browser is enough. It can also be reached from a tablet or phone on the same network.
How do I map screen elements to controller variables?
There is no separate tag table to build: the visual element binds directly to the variable in the project. If a variable name changes, the mismatch is reported at build time — you never get the silent disconnect that only shows up in the field.
Is remote access secure?
We do not recommend exposing the screen directly to the internet. Our preferred approach is to keep access behind the corporate network or a VPN, define user roles and enable session timeouts. With those three in place, remote maintenance can be run safely.
How many people can view the screen at once?
The number of concurrent clients depends on the licence. In practice two or three is enough on most machines: the panel on the machine, a maintenance tablet and one desktop for production monitoring. Buying a high client count before the need is clear just adds cost.
What happens to the screen if the network drops?
The panel on the machine is unaffected: the screen is rendered on the controller itself, so the machine keeps running. A remote browser view does need the connection. That is why it makes sense to keep critical operator actions on the panel and leave monitoring and reporting to the browser.
How long can alarm history be kept?
As long as the local disk allows — keeping months of records is routine. If you need long-term retention and reporting, it is healthier to push alarm and production data upstream over OPC UA and archive it there. Data left to accumulate on the controller becomes a problem when the disk fills.
Can I make the screen multilingual later?
Yes, though it is far cheaper if planned from the start. When texts live in a separate table, adding a language is just adding a column. If the texts are embedded in the screens, every page has to be reworked one by one.
How does recipe management work?
Product parameters are stored as a named set, and the operator loads that set with a single selection at changeover. What matters is choosing correctly which parameters belong in a recipe: if machine calibration values get mixed in, a product change will also disturb the tuning.
How do you separate user permissions?
We recommend at least three levels: operator, maintenance and engineer. The operator runs production, maintenance reaches the tuning parameters, and the engineer can change the configuration. Keeping critical parameters off the operator screen entirely measurably reduces downtime caused by mistyped values.
Do I have to redraw my existing operator screens?
The screen flow and alarm list can be preserved; what gets rebuilt is how the visual elements bind to variables. We usually suggest treating the migration as a chance to simplify the flow — in practice most of the pages added over the years turn out to be unused.