The web UI is showing pages the browser stored before the install, at an address the reflash never changed. Open the controller in a private window or clear the cache: the check takes under a minute and fixed this fault after two reflashes changed nothing. Reflash only when a clean session still shows no runtime.
You installed the 3.5 runtime on a fresh image, rebooted, and the controller's web UI still opens with no runtime entry on the Information tab and no Runtime button under Configuration. Stop before the next reflash: the web UI is drawing pages the browser stored before the install, at an address that never changed. On one controller this fault survived firmware 03.10.08 builds 22 and 21 plus a repeat install, and clearing the browser cache fixed it in under a minute. Here is the symptom list, the check, the disk numbers that clear the controller, and the reflash decision.
Why is the runtime missing from the web UI after a clean install?
The web UI is drawing pages the browser stored before the install, at an address that never changed: clear the cache or open a private window, a check that takes under a minute and fixed this exact fault after reflashes to firmware 03.10.08 builds 22 and 21 changed nothing.
A controller web UI is a set of pages the controller serves to your browser, and the browser keeps copies it can reuse. After a runtime install the web UI is meant to show a runtime entry on the Information tab and a runtime page under Configuration. A browser still holding the pre-install copies keeps drawing the old layout at the same address, so the entry and the button stay missing whatever the controller now contains. A firmware reflash changes the controller and leaves the address alone, which is why two reflashes on this fault changed nothing: the client never fetched the new pages.
Which symptoms point to the browser cache and which to the controller?
A web UI that still logs in, an Information tab with no runtime entry and a Runtime button gone from the Configuration tab, all unchanged across two firmware revisions, point at the browser; a controller that stops answering on the network points elsewhere.
- Web UI opens, Information tab lists no runtime. A cached pre-install page. Check a private window before touching the controller.
- Runtime button gone from the Configuration tab. The same cached layout; the button belongs to the page set the browser stored.
- Identical symptom on two firmware revisions. Client side. The controller changed twice, builds 22 and 21, and the symptom did not move.
- df -h shows a mount at 100% or mounted read-only. Controller side: the install could not finish writing.
- Web UI will not load at all, or the controller stops answering ping. Network or controller side; a cache fault never presents this way.
- The controller's own screen is dark or streaked while the web UI answers from a PC. A display-path fault, not a web page fault; troubleshooting an embedded controller video display covers that job.
How do you clear the cached pages in under a minute?
Open the controller's address in a private or incognito window and log in: that one step takes under a minute and settles whether the controller is healthy, and Ctrl+F5 forces a fresh copy while you stay in the normal window.
- Confirm the post-install reboot finished and the login page loads.
- Open the controller's address in a private or incognito window and log in. A private session starts with no stored pages, so what it shows is the controller's current state.
- Read the Information tab. A runtime entry there means the controller is healthy and the first session was stale.
- In the normal window, clear cached images and files for the controller address. Cookies are optional; you log in again either way.
- Close the browser fully, reopen it, load the address, and press Ctrl+F5 at the login page and once more after login.
- Gate: the Information tab lists the runtime and the Configuration menu shows the runtime page.
How do you verify the runtime is really installed?
Two sessions must agree: the Information tab lists the runtime entry, the Configuration menu shows the runtime page, and a second PC or private window shows the same, before you call the install good and reconnect from the engineering software.
- Information tab in the cleared browser: the runtime entry is listed with its version.
- Configuration menu: the runtime page or button is present.
- A second PC or another private window: both sessions show the same entry.
df -honce more: / and the data volume still sit inside the numbers below.- The engineering software connects, detects the controller and reports the runtime; checking whether a CODESYS runtime is running or stopped gives the state read that closes the job.
When the runtime is confirmed and its data needs to reach the floor, the next choice is between a dashboard and a signage screen; live factory data display: signage or dashboard splits the two jobs, and shop-floor displays cover the screen side.
What if the runtime is still missing in a private window?
Go to the controller: log in over SSH, run df -h, read the mounts against the healthy numbers below, confirm the runtime package matches the firmware revision, then repeat the install once with the transfer finished before the reboot.
The cache is ruled out at that point, so work the controller in this order:
- Log in over SSH and run
df -h. Read the mounts against the table in the next section; anything at 100% or read-only is the finding. - Compare the runtime package against the firmware revision using the package documentation from the manufacturer or its distributor, which prints the supported firmware range. Read it there instead of inferring compatibility from the version number.
- Repeat the install once, with the transfer reported complete before the reboot, then run the private-window check again.
What should df -h show on a healthy controller?
On a fresh image the root filesystem printed 82.5M total, 66.5M used, 11.8M free and 85%, and the volume behind /home, /settings and /log printed 58.6M total with 52.2M free at 6% used; neither listing shows a full or read-only filesystem.
| Mount point | Total | Used | Available | Use% |
|---|---|---|---|---|
| / (root filesystem) | 82.5M | 66.5M | 11.8M | 85% |
| /home, /settings, /log (data volume) | 58.6M | 3.4M | 52.2M | 6% |
The tmpfs mounts at /tmp, /var/log and /run sit near empty on the healthy image, /var/log at 3%, and they reset at boot.
The arithmetic behind the 85%: df divides used by used plus available, 66.5 ÷ (66.5 + 11.8) = 66.5 ÷ 78.3 = 0.85. The nominal free space is 82.5 − 66.5 = 16.0M, and df calls 11.8M of it available because the filesystem holds the remaining 4.2M for its own use. An 85% root is the baseline on a fresh image, so leave it alone. The number that means trouble is 100% appearing right after an install: the package did not finish writing. Free space on the data volume, with 52.2M available, before you delete anything on /.
How did the scenario end on one real controller?
The numbers ruled the controller out: root at 82.5M total and 66.5M used, 11.8M free, the data volume at 52.2M free, two reflashes with no change, and a cleared browser cache bringing the runtime entry back in the same session.
The full sequence, with the numbers. A compact controller on a fresh image, firmware 03.10.08 build 22. The 3.5 runtime package installed, the controller rebooted, the web UI opened, and the Information tab listed no runtime while the Configuration tab lost its Runtime button. The image was reflashed to build 21 and the install repeated: the identical page, both times.
The disk said the controller was healthy throughout: / at 82.5M total, 66.5M used, 11.8M free (85%), and the data volume at 6% used with 52.2M free. Nothing was full, nothing was read-only. Budget half an hour per reflash pass as a planning figure: two passes is 60 minutes of bench time spent proving a healthy controller healthy. The browser cache was then cleared, the session reloaded, and the runtime entry and the Runtime button appeared. Total fix time: under a minute.
When is a firmware reflash the right call?
Only after a clean private-window session still shows no runtime and the controller-side checks fail; here builds 22 and 21 both reproduced the symptom unchanged, which said the image was never the variable and one reflash was already one too many.
The order that protects your time: private window first, cache clear second, controller checks third, one repeat install fourth, reflash last. A reflash earns its half hour when a clean private session still shows no runtime, the disk numbers are healthy, the package matches the firmware, and the repeat install still lands the same way. On this fault pattern, two reflashes that change nothing are the signature of a client-side page.
Recommendation: open a private window before any second install or reflash, and clear the browser cache on every bench PC that shares one static address across controllers. Reflash only after a clean private session still shows no runtime and the controller-side checks fail; on this pattern the fix is the cache, and it costs under a minute.
Questions
Why did reflashing two firmware revisions not change the symptom?
The reflash changed the controller, and the fault sat in the client. The web UI lives at the same address after every flash, so the browser kept reusing the pages it had stored there; builds 22 and 21 drew the identical page until the cache was cleared. A bench PC that has opened several controllers at one reused static address collects stale copies for that address, so clear it whenever firmware or a runtime changes on a controller that keeps its IP.
Is a private window enough, or must I clear the cache as well?
A private window is enough to diagnose, because it starts with no stored pages and shows the controller's current state. Clear the main profile's cache as well, or the next person on that browser sees the old layout again at the same address.
When is disk usage on the controller a fault?
At 100% used, or when a mount reports read-only. The fresh image here ran the root filesystem at 85% used with 11.8M free, a baseline worth recording for the unit, while the data volume sat at 6% used with 52.2M free. A jump to 100% right after an install means the package did not write completely; free space on the data volume before deleting anything on the root.
Does Ctrl+F5 do the same job as clearing the cache?
On the page you have open, yes: it forces the browser to fetch fresh copies of that page and its files. It leaves other stored pages from the same address untouched, which is why the private window is the cleaner test and the full cache clear is the lasting fix.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.