An HMI web server shows zeros for PLC tags because the page can only repeat what the panel holds, and the panel holds fresh values only for the tags on its active screen. Confirm it with a three-screen refresh test, park the panel on the production screen to restore the page, then move the counters into a persistent header element or add a dedicated panel.
Your web page reads 0 while the touch screen shows live production counts because the page has no independent line to the PLC. It repeats the values the panel is holding, and the panel holds fresh values only for the tags on the screen it is displaying. When the panel leaves screen 1, its copy of C5:7.ACC through C5:15.ACC stops being updated, so the page serves nine zeros while the counters in the PLC keep counting untouched. The repair is a short screen-by-screen test to prove the dependency, then one permanent change: keep the counter tags polled on every screen, or put a dedicated panel on the production screen. Work through the sections in order. Each one ends with a check that has to pass before you move on.
What each symptom points to
Match your symptoms to a cause before you change anything. Each cause below has a test that separates it from the others.
- Zeros on the web page, live values on the touch screen. The PLC link, the node settings and the tag addresses are good: the panel is reading real production data. The fault is in which tags the panel updates, not in what it can read.
- The page is correct only while the panel sits on screen 1. That is the screen dependency this article fixes, and the screen test below proves it.
- Zeros on the web page and on the panel together. A link or addressing fault. Start with the panel's communication status and the object tag assignments.
- Wrong numbers on the panel, not clean zeros. An object configured with the wrong data type. Counter accumulators in this register style are 16-bit signed integers, so a value can only fall between -32,768 and 32,767; fix the object's data type first.
- The page stops loading images or the server crashes. A different fault family, tied to the panel clock in several panel software versions. That is covered in the FAQ; it is not the fault that produces correct images with zero values.
Rule out the PLC side first
The panel has already proved the link, the node and address settings and the tag addressing: on screen 1 the touch screen shows real production data and the web image matches it. Do not re-enter tag names and do not touch communication settings. Make one comparison instead.
- Put the panel on screen 1.
- Go online with the PLC programming software and open counter file 5.
- Read C5:7.ACC through C5:15.ACC and compare each of the nine accumulators with the number on its panel object.
Check: all nine values match. If a value disagrees on the panel itself, fix that object's data type first. If all nine match, the PLC and the link are cleared, and the fault lives in what the panel chooses to update.
One production note: resist cycling PLC power as a diagnostic. The counter values are intact and the office is reading them, and a controller power cycle on a running line is a decision for the line owner.
Moves that cannot fix this fault
Every move in this table fails for a stated reason, so none of them is worth a shift.
| Quick move | Why it fails here |
|---|---|
| Cycle PLC power or toggle run/program | The PLC data is intact and the panel reads it on screen 1. Cycling can also disturb counter totals other people are watching. |
| Rewrite tag names or addresses | The same tags display on the touch screen and on the page whenever screen 1 is active. The addressing is not the fault. |
| Refresh harder or clear the browser cache | The page renders valid values whenever the panel is on screen 1, so the browser is not the source. |
| Swap the Ethernet cable or switch port | Images are being served. A cable fault does not return a valid page whose zeros depend on which panel screen is up. |
| Re-download the panel project | Try this last, and only after a backup. It changes nothing if the cause is which screen is active. |
Check: nothing in the project, the addressing or the communication settings has been altered. From here on, change one variable at a time.
Test whether the zeros follow the screen
- Open the web page in a browser on a PC and leave it open.
- Put the panel on screen 1, refresh the browser, and record the nine values.
- Navigate to a second screen, refresh, and record the nine values again.
- Repeat on a third screen.
- Return to screen 1 and refresh once more.
Check: values are correct only while the panel is on screen 1, they read 0 on the other screens, and they return when you go back. That pattern confirms the screen dependency in one pass. If the values read 0 on screen 1 as well, the fault is a different one: go back to the PLC-side comparison and the panel's communication status.
Example: nine counters across three screens
Scenario: a packaging line with an 8-inch panel. Screen 1 carries the production totals, and C5:7.ACC through C5:15.ACC feed the browser page the office watches. At 14:05 the panel sits on screen 1 and the page shows C5:7.ACC at 1,284 parts, matching the panel. The operator opens the alarm list at 14:06, and the refreshed page shows 0 in all nine fields. The recipe screen at 14:07 gives the same result. Back on screen 1 at 14:08, the page reads 1,291 parts, again matching the panel.
The arithmetic: 9 tags across 3 screens is 27 readings, of which 18 came back as 0, and every zero fell on the two screens that carry no production objects. The return value moved 1,291 - 1,284 = 7 parts in 3 minutes, about 140 parts per hour, in line with the line rate. Correct, zero, zero, correct: no PLC value was touched, no setting was changed, and the dependency is confirmed in about three minutes at the panel.
Park the panel on screen 1 tonight
This is a temporary restore, not the repair. The office reads production from the page, so the fastest way back to correct numbers is to keep the panel parked.
- Navigate the panel to screen 1 and leave it there.
- Tell operators the panel stays on screen 1 during production, and tape a note on the bezel if that helps.
- Refresh the web page and confirm the nine values against the online counter view.
Check: leave the panel untouched for 10 minutes, refresh twice, and confirm the values still track the counters.
Any touch on a navigation button breaks it again. If operators need other screens to run the machine, this hold will not last a shift, so move to the permanent fix. If your panel software offers a screen timeout or return-to-home option, set it so an idle panel returns to the production screen. And after every power cut, check that the panel opened on screen 1: the startup screen setting controls which screen it opens on.
The permanent fix
The repair puts the counter tags where the panel services them on every screen, or takes the panel out of the data path. Pick the option that fits how the machine is operated.
| Option | How it works | Trade-off |
|---|---|---|
| Persistent header element | An element present on every screen keeps the nine counter tags in use wherever operators navigate. Place the counter objects there, then rerun the three-screen test. | Uses screen space on every screen. Works only if your panel software offers the feature; look in the project editor's screen-change or background element options. |
| Dedicated panel on the production screen | A second panel stays on the production-data screen and serves the web page; operators run the machine from the first panel. | Extra hardware. Before you commit, test a panel's startup and runtime first. A second panel over Ethernet needs no spare serial port, though adding another operator interface when the PLC ports are full is its own planning job. |
| Consolidate operator functions onto screen 1 | Nobody navigates away, so the counter tags stay in use. | Crowded screen, and fragile the day maintenance needs a second screen. |
| Read the PLC from another system | Production data goes to a system that talks to the PLC directly, such as a read-only process display for the plant floor. | Needs its own communications path to the PLC. When a panel already holds the port, connecting SCADA to that PLC needs planning around the panel. |
Do not move the counters inside the PLC. The counters and their addresses are correct, and changing counter file 5 only creates new addressing work in the panel project.
Recommendation: Run the three-screen test first. If the nine values come back only while the panel sits on screen 1, place the counter objects in a persistent header element that appears on every screen; if your panel software has no such element, put a dedicated panel on the production screen and let it serve the web page. On a panel that polls every screen regardless, neither change does anything, so the test decides the repair.
Retest after the change
Repeat the three-screen test after the permanent change. All nine values must stay correct on every panel screen, not only on screen 1, and each one must match the online counter view. If a screen still serves zeros, the tags are still polled from one screen only, and the next option in the table is the repair.
One test, one change, one retest: after that, the page shows production values wherever the panel is left.
Questions
Does every HMI web server repeat the panel's display?
The behavior varies by panel software and version. Older small-panel web servers are generated from the panel's project and repeat its display, so their tags depend on the active screen; some newer web servers build pages with their own tag polling. Your manual states which type yours is, and if the documentation is unclear, the three-screen refresh test settles it in one pass: zeros that follow the panel screen mean the page depends on the display.
What if the web page also stops loading images or the server crashes?
That is a different fault family. Several panel software versions had web server faults tied to the panel clock: when the panel reads date and time from the PLC, a clock problem can crash the server or stop it serving images. The known workaround is to set the panel clock source to internal, set the correct date and time, and retest. Correct images with zero values, as in this article, are a polling problem, and that clock change will not fix them.
Should I move the counters to different PLC addresses?
No. The counters are counting correctly and the touch screen reads them, so the data side is healthy. Moving counter file 5 creates new addressing work in the panel project, risks disturbing production totals that other screens and reports use, and fixes nothing: the page would serve zeros for whatever addresses the inactive screen holds. Repair where the panel services the tags, not where the PLC stores them.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.