When the panel's own clock and graphs stop and a tap or page change brings them back, the display hardware is alive and the panel's idle update path is starved. Pull the PLC cable and watch the clock untouched for one minute, then run a one-object test page from a project copy. A clock that still stalls with the cable out points to project load or panel memory, and the lighter page is the fix.
When the clock on an HMI panel stops and the line graphs sit still, and a tap or a page change brings them back, the screen hardware works and the PLC link is not the driver. The panel's scheduled work, the timer that advances the clock and the task that plots each new trend point, has lost the time or memory it needs. The numbers in front of you say the same thing: page changes that take 3 to 5 seconds, a clock frozen at one reading, graphs that redraw the moment the screen is touched. Two tests, each under ten minutes, tell you whether the fault lives in the panel's own load or on the communications side. Both need only a stopwatch and a copy of the project.
What each symptom points to
- The internal clock stands still. The clock runs on the panel, so no PLC data can be required to advance it. A frozen clock places the fault on the panel side before any cable is touched.
- Graphs catch up only after a tap or a page change. A forced redraw that works shows the display pipeline is healthy. What stalled is the scheduled redraw: trend sampling and the periodic repaint that should run without input.
- Page changes are slow enough to time on a watch. Navigation is panel work, so time a few changes in seconds and write the number down. That before-and-after pair is the evidence for every change you make.
- It continues with the PLC cable unplugged. A freeze that survives an unplugged link clears polling load, response timeouts and cable faults as the cause.
- Two panels freeze the same way. Two units with the same behaviour point at what they share: one project download, one heavy page, or a shared power arrangement. Two units with different projects point at panel condition.
Test 1: watch the panel with the PLC link unplugged
- Agree a pause with production so the panel can run without its PLC link for a few minutes.
- Watch the clock and graphs untouched for 60 seconds with a stopwatch in hand. Record whether the clock advances, whether each graph adds a point, and how many seconds a page change takes.
- Unplug the PLC communications cable at the panel.
- Wait 60 seconds untouched and repeat the three observations.
- Reconnect and write down what changed.
Read the result this way:
- Clock still frozen with the cable out. Panel side. Go to Test 2.
- Freeze appears only with the cable connected. Communications side. Read the PLC scan time while the freeze is active: a small PLC scanning in 2 to 4 ms is doing its job quickly, so a fast scan next to a crawling panel points at the volume or handling of the data. A PLC heartbeat counter shows whether the link is dropping and recovering, and tracing a delay between an HMI panel and its devices gives the checks in order.
- Freeze clears when unplugged and stays clear. The project's polling or data feed is the trigger. Lighten the page, and Test 2 shows by how much.
Test 2: run a one-object page from a project copy
- Copy the project and note its revision. Work on the copy only.
- Build a test page that carries one object: a clock, or a numeric field reading a single register.
- Download it to the panel during the agreed pause, using the maker's documented transfer procedure.
- Watch 60 seconds untouched. A clock that advances 1 second at a time on a one-object page shows the panel keeps time once the page load is gone.
- Add objects back in groups: the line graphs first, then the numeric fields, then lamps and buttons, with a download and a 60 second watch after each group. The group that brings the slow page changes back is the load to cut.
A graph that loses its plotted history when the page changes is a separate behaviour, and why a real time graph clears when you change HMI screens covers that one.
If the one-object page still stalls, and the panel freezes the same way after a restart through its documented shutdown, the panel itself is the suspect and the next conversation is service or replacement. If the one-object page runs clean, the fix is a lighter project download.
Example: two graphs, 40 objects and a 4 second page change
Suppose a packing line panel shows the full signature: the clock stands still, two line graphs move only after a tap, and page changes timed on a watch come in at 3 to 5 seconds, about 4 seconds on average.
Test 1 first. For the first 60 seconds the clock and graphs sit as before. Pull the PLC cable and wait another 60 seconds untouched: the clock has still not moved. Panel side.
The page carries 40 objects that repaint with it: 2 line graphs plus 38 numeric fields and lamps. Each graph samples once per second and holds 600 samples, which is 600 seconds, or 10 minutes, of trend per graph, and the two graphs together plot 2 new points every second.
Test 2 next. A fresh page with only the clock advances 1 second per second, clean. Adding graph 1 alone stays clean. Adding graph 2 and the 38 fields back returns the stall, and page changes go back to about 4 seconds.
The cut that holds: keep 1 graph at 1 sample per second but hold 300 samples, which is 5 minutes of trend, and split the 38 fields across 2 pages of about 20 objects. Page changes fall to under 1 second and the clock holds through the rest of the shift. If operators need an hour of trend, keep the 600 samples and sample every 6 seconds: 600 samples at one per 6 seconds is 3600 seconds, or 60 minutes, of trend at a sixth of the writes per minute.
The fix, in order
- Recover the line once. Restart the panel through its documented shutdown while the line is stopped. Never cut power during a project transfer or any other write to the panel's storage: an interrupted write can leave the project damaged, and a reboot that operators depend on deserves the same agreement as any other production stop.
- Cut the load the tests identified. Delete or move objects nobody reads, split crowded pages, keep one graph per page if the graphs were the group that reproduced the stall, and sample trends as slowly as the operators' need for history allows. The example's 6 second rate held an hour of trend.
- Re-download and re-time. Run the stopwatch on the same page changes and the same 60 second untouched watch on the clock. If the stopwatch climbs back toward the original 4 seconds, the load is still on the page.
- Treat a restart as a diagnostic. If the freeze returns within the same shift with no project change, restarts are masking the load, and the work stays in the project.
When the numbers point back at the PLC
Three results in Test 1 send you to the communications side: the freeze appears only with the cable connected, it clears the moment the cable comes out, or one of two panels on a shared link freezes while the other runs clean. Check in this order: the scan time you read during the freeze, a heartbeat counter for a link that drops and recovers, and the number of tags the page polls every second. For a deeper walkthrough of separating communications faults from panel freezes, a step-by-step guide to HMI communications and freeze troubleshooting goes through those checks in order.
The decision
Recommendation: Run Test 1 before ordering any part. Unplug the PLC link at the panel during an agreed pause and watch the clock untouched for 60 seconds. If the clock still stalls, the fault is panel side: restart once through the documented shutdown to recover the shift, then cut the page as the example did, one trend graph with the fields split across two pages, and confirm with the stopwatch that page changes have fallen to under 1 second. Replace or service the panel only when a one-object page still stalls after a clean restart.
The same pattern runs through the other shop-floor screen and machine display checks: one measurement, one change, re-time.
Questions
Why does the clock matter more than the graph?
The clock runs on the panel, so nothing the PLC sends or fails to send can be required to advance it. A line graph is different: it can plot values polled from the PLC or history the panel records itself. A stalled graph can therefore come from either side, while a stalled internal clock points at the panel. That asymmetry is why the unplugged test starts with the clock.
What does a tap that revives the screen tell you?
It tells you the panel's display, backlight and touch hardware all work, because a touched page repaints immediately. The fault sits in the scheduled side: the timers, trend sampling and periodic repaints that should run without input. This is also why a touch test on a bench passes on a panel with this fault, and why replacing the touch layer or the whole panel will not fix a project-load problem.
Should the panel be restarted or the project changed first?
Restart once, with the line stopped, to recover the shift and to confirm the diagnosis. Panel maker documentation for slow or hanging devices lists low memory as a cause and a restart as the recovery step. If the freeze returns within the same shift and no project change was made, the restart was a diagnostic, and the work moves to the project: fewer objects per page, slower trend sampling, shorter history.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.