When a controller has no internal web server, the CODESYS HMI runtime runs as a licensed application on a PC. The project holds two applications downloaded independently, separate projects are possible from CODESYS 3.5 SP10, and any browser opens the PC address. This page compares the four architectures, sorts dead-screen symptoms by layer, and sizes the operator text.
A controller with no internal web server can still carry a CODESYS visualization: the screens run as an application on a PC runtime, licensed on that PC, with the PC holding the data link to the controller. The project holds two applications, one for the controller and one for the HMI, and each downloads independently; from CODESYS 3.5 SP10 the two can also be developed as separate projects. Add the web visualization option and browsers open the same screens at the PC's address. This page compares the four architectures that fit the job, sorts the dead-screen symptoms by layer, and sizes the text for the operator, because most failures here are a license, a binding, a network path or a wrong target, and each shows differently on the screen.
Where the visualization can run
The architecture question is which machine executes the screens and serves the pages. Four routes cover the field.
| Approach | Where the screens run | Fits a controller with no web server | The trade |
|---|---|---|---|
| Visualization in the controller | In the controller, served by its internal web server | No; this controller has none | One download and no extra hardware, but it needs the server the CPU lacks |
| CODESYS HMI on a PC | On the PC runtime, which talks to the controller | Yes | Two applications to build, download and maintain; the license sits on the PC |
| CODESYS HMI with the web visualization option | On the PC, also served to browsers by the PC | Yes | Remote browser access, and one more license option |
| A separate visualization product over a standard protocol | On that product's own panel or PC | Only if the controller speaks a protocol the product supports | Read the controller's documented protocol list before committing |
Where each one wins: the controller-hosted route wins on simplicity, and a CPU without a web server takes it off the table. The PC runtime wins at the machine, where one operator walks up, reads and touches. The web option wins for engineers who want the same screens from a desk. The protocol route wins when the controller's toolchain is closed to you, and it is the fall-back when the PC runtime cannot open a data link at all.
Two applications, two downloads
In any CODESYS 3.5 project you create two applications under one project: the PLC application targeted at the controller, and the HMI application targeted at the CODESYS HMI runtime on the PC. Each download is independent, so build the habit now: after any change to a shared variable, download both. From 3.5 SP10 the two applications can also live in separate projects, which suits a screen maintained by a different person than the control logic.
The HMI application never goes on the controller device. When the device tree refuses an HMI application under the controller, that refusal is correct: the HMI target is the PC runtime. Create the application there and the tree takes it.
Images and video the screens use travel with the HMI application on the PC, and where PLC visualization media should live covers planning that storage.
The license goes on the PC
The HMI runtime executes on the PC, so the license activates on that PC. The license store describes the HMI SL package as software installed on a remote computer, a PC or a panel, to equip it with a graphical HMI; check the store's HMI SL pages for the license types and their variable-count tiers, including an unlimited-variables option. These are application-based runtime licenses tied to the machine running the application.
Two field consequences follow. A re-imaged or replaced PC activates the license again, so keep the activation details with the machine documentation. And the package equips one computer: a second operator PC carries its own license.
The browser address is the PC address
The web visualization is an option on the PC runtime, and the PC serves the pages. Every browser URL points at the PC. A browser pointed at the controller's address finds nothing, and no setting on the controller changes that: with no web server inside, the address has nothing to answer with. When a remote session shows a blank page, the first check is which address sits in the URL bar.
What breaks this setup in the field
Five failures account for most service calls on this architecture.
- Single-sided downloads. Renaming or retyping a PLC variable and downloading only the PLC application leaves the HMI bindings stale.
- The PC as a single point of failure. The controller keeps running its logic when the PC stops; the operator loses the window on it. Maintain the PC as a control-system component, and keep emergency stops and safety interlocks hardwired so a stopped PC never takes a safety action away.
- A re-imaged PC. The license activates again on the new image; keep the activation details ready before service work.
- The wrong browser address. The URL names the PC, always.
- A firewall on the PC. A blocked port draws the same screen as a missing binding: stale initial values with no clear error. Check the firewall before rebuilding bindings.
Reading a dead screen by layer
An operator sees one of three things: every element dead, every element sitting at its initial value, or one element wrong while the rest live. Dead and initial-value screens point at the license, the binding, the network or the target. A single wrong element is a tag fault. Sort by what the screen shows before touching the network.
| What the screen shows | Layer | The check |
|---|---|---|
| All elements dead, the runtime reports limited operation or stops | License | Open the license status of the HMI runtime on the PC |
| All elements at initial values, no error shown | Binding | Check that the HMI application's variables are bound to the PLC application's variables and both applications are downloaded |
| All elements dead, communication timeout | Network | Ping the controller from the PC; check the subnet, the controller address and the PC firewall |
| The HMI application cannot be created on the controller device | Target | The HMI application targets the PC runtime; create it there |
| One element wrong, the rest live | Tag | Check the variable name, type and scaling behind that element; a renamed PLC variable breaks only its own binding |
When the controller refuses the HMI
A report that a controller 'does not accept' CODESYS HMI covers three different failures, and each has its own fix.
The device tree rejects an HMI application on the controller. That is a project mistake, and the tree is right: the HMI application belongs under the PC runtime target. Move it and continue.
The controller refuses the PC's data connection. Prove the link in isolation with a page holding one bound variable. If that element never updates while the license, binding and network checks all pass, the data path itself is the blocker.
The vendor documents the combination as unsupported. Then read the controller manual's list of supported protocols and choose a product that speaks one of them. Where the controller runs CODESYS, setting up an OPC UA server for HMI clients opens its variables to any client over a standard protocol.
Build the one-variable page before the real screens. If it updates, the architecture is sound and every later fault is a tag. If it never updates, stop and take the protocol route.
Checking the link end to end
Run this sequence once at commissioning; it settles every layer in order.
- Open the license status of the HMI runtime on the PC and check it shows a full license, with no limited mode.
- Force one bound PLC variable in the online view and watch the matching HMI element follow within the update cycle you set.
- Write a setpoint from an HMI input element and read the same value back in the PLC application's online view.
- Pull the network cable between the PC and the controller. The HMI should flag the loss; reconnect and check the values resume without restarting the runtime.
- With the web option licensed, open the PC's visualization address from a second computer and repeat the write test from that browser session.
Example: sizing the HMI text for an operator 10 ft from a 24-inch screen
The PC HMI is the machine's face, so text size comes from the viewing distance, and the viewing distance comes from where the operator stands.
Inputs.
- Viewing distance: 10 ft, a typical stand-off between an operator and a screen mounted on the cabinet or a swing arm.
- Letter sizing: 20 ft of viewing distance per inch of capital height, the safer figure for fast reading; the FHWA planning figure is 30 ft per inch, for text read occasionally.
- Line spacing: 1.7 times the capital height.
- Panel: a 24-inch 1920 x 1080 screen, a common size for this job.
Rule. Divide the viewing distance in feet by the feet-per-inch figure to get the capital height in inches, then convert to pixels with the panel's pixel density.
Arithmetic.
- 10 ft ÷ 20 ft per inch = 0.5 in of capital height.
- A 24-inch 16:9 panel shows a picture about 11.8 in high (24 × 9 ÷ 18.36), so its 1080 rows give about 92 pixels per inch.
- 0.5 in × 92 pixels per inch ≈ 46 px capitals.
- Line pitch: 1.7 × 46 ≈ 78 px, and 1080 ÷ 78 ≈ 13.8, so 13 full text lines per screen.
- Occasional status text at the FHWA figure: 10 ÷ 30 ≈ 0.33 in, and 0.33 × 92 ≈ 30 px.
Result. 46 px capitals for anything read at a glance from 10 ft, 30 px for occasional status text, about 13 lines per screen.
Decision. Set alarm text, setpoints and live values at the 46 px size, and hold nothing an operator must read quickly below it. Every extra 10 ft of distance adds 0.5 in, about 46 px, of capital height: a screen read from 20 ft needs 92 px capitals on this panel.
When a separate status screen serves better
The PC HMI answers the person standing at the machine. A board the whole floor reads every shift is a different job: it repeats a few numbers where people pass, and it needs no write path to the PLC. Our shop-floor signage covers that side, with offline playback or your own Android app and no subscription. These are signage units, not HMIs: they take no video input and they replace no operator screen. Andon boards: where a small screen fits draws the dividing line, and signage or dashboard for live factory data walks the choice.
The decision
Recommendation: run the HMI as an application on the PC runtime, licensed on that PC, and download both applications after every interface change. Add the web visualization option only when someone must open the screens from another computer, and point every browser at the PC address. Take the protocol route only when a one-variable test page, run after the license, binding and network checks, never updates; then choose from the controller's documented protocol list. When the screens must also serve the whole floor, keep the PC HMI at the machine and put a signage board where the floor walks past.
Questions
Does the CODESYS HMI license ever go on the controller?
No. The license activates on the PC or panel that runs the HMI runtime; the controller runs only the PLC application. This is why the licensing reads oddly at first: you license a computer that is not the PLC. When that panel or PC is replaced, the license is activated on the new machine, so keep the activation details with the machine documentation.
Can the two applications live in separate projects before CODESYS 3.5 SP10?
No. Before 3.5 SP10 both applications share one project, though each downloads independently, which every 3.5 version supports. From 3.5 SP10 you can split them into separate projects. The split pays off when the screens and the control logic are maintained by different people, or when an integrator builds the HMI project without ever opening the PLC code.
How do I prove the data link before building the real screens?
Build one page with a single bound variable, download both applications, and force that variable in the PLC online view. If the element follows the forced value, the license, the binding and the network are all good, and every later fault is a tag. If it never moves, stop building screens and sort the layer it failed on; a full set of screens built on an unproven link fails the same way.
How big should alarm text be on a PC HMI screen?
Size it from the stand-off distance. At 20 ft of viewing distance per inch of capital height, an operator 10 ft away needs 0.5 in capitals, about 46 px on a 24-inch 1920 x 1080 panel, whose pixel density is about 92 pixels per inch. The FHWA figure of 30 ft per inch gives about 30 px for text read occasionally. Multiply inches by 92 to convert sizes for that panel.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.