HMI screen slow to update over serial with no errors

What the delay points to

Match the symptom before you open a settings dialog. Each cause below is documented panel behavior or a measured case, and each has a different fix.

• Busy screens lag, a bare screen does not. That is rendering workload. The panel redraws every visible object on each pass, so object count and detail set the floor under response time.
• Values hide behind transparent overlays. An object updating behind a transparent object forces the panel to run transparency blending on every update. The panel vendor's own support guidance names this as a direct cause of slow screen updates.
• The screen slowed after the project was imported from another panel. Imported detail. The buttons look the same, but each carries more drawing work, and the new panel pays for it on every pass.
• Objects read addresses spread across the PLC memory. Scattered addressing. A panel collects values cheaply when it can read them in blocks; addresses spread over many data areas force many small transactions. Update quality drops on any panel when values sit all over the memory map.
• Values drop out, or a PLC-triggered message never arrives. A different fault from a steady delay. Start at fixing dropped PLC-triggered messages on a serial HMI panel, and at timeout and checksum faults when errors show.
• Even a one-object screen is slow. Now the link, its driver or the tag update interval is in scope. Confirm both ends report the same serial settings, confirm the PLC driver selected in the panel project matches the processor path, and check the driver version, all before rewiring anything.

The same split, link first and rendering second, holds above single panels too: troubleshooting a slow screen update on a SCADA client works the pages in the same order.

The one-object test

Edit a backed-up copy of the project, and keep someone at the machine while a test screen runs: a rebuilt page can hide an alarm or a fault indicator.

1. Pick a PLC address that changes on its own, a counter or the real-time clock word, so nothing has to be triggered by hand.
2. Build a test page with one numeric object bound to that address. Change no link settings.
3. Run the test page and time it against the PLC's own value. Note the seconds between a change in the PLC and the same change on screen, ten times, and keep the worst.
4. Put the production page up with the same address visible and repeat the timing.
5. Compare. Under 0.1 s on the test page with whole seconds on the production page is screen workload. Slow on both pages moves the search to the link, the driver or the tag's update interval.

If the single value never moves at all, the fault sits upstream of the screen. Trace which layer freezes when a PLC counter stops updating before touching the panel project.

Example: what one refresh costs at 38.4 kbaud on a 40-value screen

The inputs, with where each comes from:

• 38.4 kbaud line speed: the setting in the case behind this article.
• 10 bits per character: one start, eight data, one stop, the common serial framing.
• 40 values of 2 bytes each, read as one block: a full machine-status page of 16-bit registers.
• 8-byte request and 85-byte reply: the Modbus RTU frame layout of address, function, data and check bytes.
• One port service per transaction: serial ports on small PLCs are often served once per scan, and the scan in the reference case ran 2 to 4 ms.

The rule in words: wire time equals characters sent divided by characters per second; characters per second is bits per second divided by bits per character; add one scan time for the port service.

The arithmetic:

• 38,400 bits/s ÷ 10 bits per character = 3,840 characters/s, so one character takes 1 ÷ 3,840 = 0.26 ms.
• 8 + 85 = 93 characters on the wire per refresh.
• 93 × 0.26 ms = 24 ms of wire time.
• Add one port-service wait of 2 to 4 ms plus panel processing, and call the full refresh 30 to 40 ms.

The scan term is measured, not assumed: in one documented serial test, a 100-word read slowed by 40 ms when the PLC scan time moved from 10 ms to 50 ms, the change one port-service wait adds.

Result: a 40-value page can carry fresh values about 25 times per second (1,000 ms ÷ 40 ms = 25), and the wire budget for one refresh is about 24 ms.

Decision: on this load a healthy screen tracks the PLC with no delay you can see. An operator-felt delay of 1 to 3 s, the figure reported on one press brake with this shape of problem, is 25 to 75 times the whole budget (1 s ÷ 0.04 s = 25, 3 s ÷ 0.04 s = 75). Treat any felt delay above about 0.2 s on this load as a screen or driver problem and leave the baud rate where it is.

Cut the screen work

Work the page, one change at a time, re-timing after each change under the same production conditions.

• Unstack transparency. Move live indicators out from under transparent overlays or delete the overlay. An overlay over static graphics costs nothing; an overlay over live values costs a blend on every update.
• Thin the page. Delete every object no operator reads. Each deleted object is one less redraw on every pass.
• Regroup addresses. Move the page's values into contiguous blocks in the PLC data area so one block read covers them. Two block reads beat twenty scattered transactions, and this is the fix for scattered addressing.
• Set update rates per tag. The update rate for external tags should be short only where the value needs fast response; a temperature that moves once a minute does not need the polling rate of a press position. The panel's tag documentation names the setting, and vendor guidance for exactly this symptom is to raise update rates only for tags that need them.
• Watch trends separately. Where the value feeds a trend graph, the interval usually sets the refresh; see why an HMI trend graph will not update every half second.

Moving to Ethernet without losing the tags

Move only when the one-object page is also slow, and only after the driver list confirms support.

• In the case behind this article, the panel's Ethernet driver of the day did not talk to that processor's Ethernet port. Driver support changes with panel and software revisions, so check the current supported-driver list for the exact panel and software before ordering cable.
• The tags live in the project, not in the port. Back the project up, duplicate it, and change only the communication path on the copy: select the Ethernet driver, enter the processor's address, and leave the serial configuration untouched in the original.
• Verify on the copy that every address still resolves, that values read back correctly, and that operator writes land on the intended addresses. Keep the serial path in service until the Ethernet copy passes on the machine.
• The capacity gap is wide: a 100 Mbit/s port carries 100,000,000 bits/s against 38,400 bits/s on the serial line, about 2,600 times (100,000,000 ÷ 38,400 ≈ 2,604). That is bandwidth, not a latency promise; the felt gain depends on the driver and on the rendering work you cut in the section above.

The decision

Recommendation: Run the one-object test before changing any setting. If the single value keeps up, keep the serial link at 38.4 kbaud and fix the page: unstack transparent overlays, delete objects no one reads, and regroup scattered addresses into contiguous blocks. If even the single value lags, verify the matched serial settings and the driver first, and plan the Ethernet move only after the supported-driver list confirms your panel and processor.

Per case:

• Test page fast, production page slow: stay on serial and cut the workload. Expect the production page to fall close to the one-object time as you strip it.
• Both pages slow: matched serial settings, then the driver, then the tag update interval, in that order. Ethernet comes after the driver check, on a project copy.
• Errors at any point: hand the case to the dropped-message and timeout fixes linked above. The path in this article assumes a clean link.

If the late screen is a signage notice board instead of a machine HMI, the hunt starts at the player stack; diagnosing a factory screen that updates late walks it. A standalone status board beside the machine is a different screen for a different job; our shop-floor signage boards are built for that role.

Questions