Speed up HMI screen updates when moving from serial to Ethernet

What Ethernet changes

Serial ports on PLC CPUs top out around 38.4 kbps. A standard Fast Ethernet port moves 100 Mbps, about 2,600 times the wire rate, and the pipe is genuinely that wide.

Two more facts decide the delay you feel. First, Ethernet carries heavier framing per message. IEEE 802.3, the Ethernet standard, puts an 8-byte preamble, a 14-byte header and a 4-byte frame check on every frame and requires a 12-byte idle gap after each frame, so 38 bytes sit on the wire before any of your data. The common PLC stacks wrap each message in IPv4 and TCP headers, another 40 bytes. A small tag read spends roughly twice its own length in framing. Second, standard Ethernet carries no delivery-time promise: the technology sets no defined latency value for machine traffic. Frames land fast on an idle link and later when other traffic competes.

The move to Ethernet removes the narrow pipe. The request count behind each refresh and the traffic on the path stay, and those set the delay you see.

Symptoms and what each points to

• One busy screen or graph lags while the rest of the project updates on time. The poll set behind that screen holds too many tags at scattered addresses, so the driver sends one request per tag.
• The delay wanders and is worst when the rest of the plant network is busy. The panel and PLC share an Ethernet segment with competing traffic, and collisions eat throughput.
• Every screen lags by the same steady amount. The link itself is saturated, usually a serial port carrying more data than 38.4 kbps can move, or the PLC scan answers polls late.
• Values skip or arrive late over serial with no error on either end. Poll responses are being dropped, and the checks in fix dropped PLC-triggered messages on a serial HMI panel apply.

A tag database holding 1,000 entries says little about load. The load that matters is the values shown on the active screen plus every event and graph the runtime keeps fresh.

Measure the delay you have now

Pick a PLC register that ticks once per second, a clock or a free-running counter, and show it on the screen that lags. Watch the register change in the PLC and stop a stopwatch when the pixel changes. Run it ten times and write down the typical and the worst. Then watch the graph the same way. Polling means the panel's driver sends a read request at the set interval: a 1 s setting is a request, and the stopwatch tells you whether samples actually land at 1 s spacing. Check the polling description in your own PLC interface manual. The longer version of this diagnosis is in diagnose factory screen update delay.

Record the numbers per screen. That list is the baseline every later change is judged against, and it takes about ten minutes.

Put the graph and event tags in consecutive addresses

Every poll request fetches a block of consecutive addresses. Scattered tags force one request per address, while one consecutive block collapses a whole graph into a single request.

List the addresses behind the slow graph and behind the event logic, in PLC address order. Then move the values into a free consecutive block or mirror them into one each scan, and remap the panel references to the new block. Before the change goes live, check the new addresses against everything else in the program that reads or writes that memory, because an overlap corrupts data silently, and test any panel writes at the new addresses before the machine runs, as laid out in operator panel PLC link setup: test writes before motion.

If the graph and event tags already sit in consecutive blocks, leave the layout as it is. Grouping is done, and the remaining delay lives in the path.

Give the panel a dedicated link

Put the panel and the PLC on a direct Ethernet cable, or on their own switch or VLAN that carries no office or IT traffic. The more unrelated frames the pair sees, the more chances for collisions and slow throughput, and a quiet path is the cheapest capacity upgrade available.

Mind the distance rules: 100 Mbps over copper is good for 100 m per segment under IEEE 802.3, and longer runs add a switch or move to fiber. A panel mounted far from the PLC is a normal Ethernet distance problem, and connect a remote HMI screen 1,500 feet from the PLC works that case through. For the choice between the serial port and the Ethernet port on a given machine, connect a PC HMI to a PLC over a serial protocol or Ethernet covers the basics.

Example: the wire time behind one 1-second graph

Scenario: a panel with 1,000 tags in its database runs a graph of 24 values set to refresh every 1 s, and the 24 addresses are scattered.

Assumptions for the arithmetic: the read request carries about 12 bytes of data and the reply about 50 bytes, which covers 24 registers at 2 bytes each plus a few protocol bytes; Ethernet framing adds 38 bytes per frame for IEEE 802.3 plus 40 bytes of IPv4 and TCP headers, so 78 bytes of overhead per frame; serial framing adds about 10 bytes per message and runs at 8 data bits, no parity, 1 stop bit, which is 10 bits per byte; and each request-reply cycle takes 10 ms end to end through the driver, the network and the scan. The byte counts and the 10 ms are illustrative values, representative of a small block read; measure your own before spending money.

Ungrouped on serial: 24 cycles, each a 22-byte request and a 60-byte reply, give 24 × 82 = 1,968 bytes, or 19,680 bits at 10 bits per byte. At 38.4 kbps that is 19,680 ÷ 38,400 = 0.51 s of wire time. One scattered graph consumes half the update interval just moving bits, before the scan and the other graphs get a turn.

Grouped on serial: one 82-byte cycle moves 820 bits, or 820 ÷ 38,400 = 21 ms of wire time. Six graphs that size take about 6 × 21 = 128 ms per second and still fit the port.

Ungrouped on Ethernet: each cycle is 90 bytes out and 128 bytes back, 218 bytes total, so 24 × 218 = 5,232 bytes, or 41,856 bits. At 100 Mbps that is 41,856 ÷ 100,000,000 = 0.42 ms of wire time. The wire sits idle; the delay you feel is the chain of round trips, 24 × 10 ms = 240 ms.

Grouped on Ethernet: 218 bytes is 1,744 bits, which moves in 17 µs, and one round trip of about 10 ms is all that remains.

The decision follows from the table. On serial, grouping is the fix that matters: it turns a port that cannot carry one scattered graph into one that carries several grouped ones. On Ethernet the wire was never the limit at 0.42 ms, so grouping buys the drop from 240 ms of chained round trips to about 10 ms. Either way the request count decides, and the link decides whether wire time stacks on top of it.

The fix, in order

1. Back up the PLC program and the panel project. Record the baseline stopwatch numbers, per screen.
2. Move the graph and event tags into consecutive blocks, remap the panel references, and confirm every reference lands on the intended value. Test writes at the new addresses before the machine runs.
3. Re-measure the same register and the same graph, changing nothing else, so the numbers show what grouping bought.
4. Move the link to Ethernet if the serial measurements stay over budget or if several graphs and event sets share one port. Use a direct cable or a clean switch and VLAN, not the office network.
5. Re-measure once more with the normal production screens active. One factor per step, so each number names the change that did the work.

Budget the result at a quarter of the update interval: 250 ms or less, measured end to end, for a graph set to 1 s. Under that, stop tuning; the graph reads as live and the headroom absorbs scan-to-scan variation. Still over it on a dedicated 100 Mbps link with grouped tags means the poll set is the limit: trim the tags per graph or stretch the interval to 2 s and re-check.

Recommendation: group the graph and event tags into consecutive PLC addresses first, on whichever link you run today, and judge the change by the measured delay, never by the configured interval. Keep the serial port when the grouped measurements fit the 250 ms budget for a 1 s refresh. Move to a dedicated 100 Mbps Ethernet link when several graphs share one port or the serial numbers stay over budget, and expect the gain to come from fewer requests on a quiet path, with the wide wire rate behind them as margin.

Where to stop

If the panel sits on a dedicated 100 Mbps link, the tags sit in consecutive blocks and the measured delay still runs past a quarter of the interval, stop changing hardware. The remaining delay lives in the panel's driver scheduling or in the PLC scan, and the next step is the poll-scheduling documentation for your panel and PLC, with the per-screen delays, tag counts and addresses in hand.

Keep the HMI as the control screen. When the cell also needs a standalone board for cycle counts, notices or andon status for people away from the machine, that is a separate display with its own playback, and our shop-floor signage is built for that job.

Questions