Fix Modbus TCP data slow to update on an HMI panel

Why does the panel show Modbus TCP data that is minutes old?

A configured 1-second poll cannot by itself show data 2 to 3 minutes old, so the delay is not the timer: it is the register the item reads, the controller's Modbus service, or a process value that really moves that slowly.

Modbus TCP moves data only when the client asks. The panel sends a read request, the controller answers, and the item on screen updates from that answer. Three things stretch the gap between the real value and the displayed one:

1. The mapped register itself changes slowly, so every answer is correct and uselessly old.
2. The controller's Modbus service is busy or connection-limited and answers other clients first, so answers arrive minutes after the request.
3. Requests or answers are lost and retried, so applied values arrive in bursts.

A timer edit only changes how often the panel asks. If the answer path is the problem, asking more often makes the controller busier without making the display fresher. The rest of this page separates the three with one test value.

How do I tell stale display data from a stale process value?

Watch one known changing value at three points: the process, the controller's own data table, and the panel. If the controller value moves within 1 second and the panel shows it 150 seconds old, the fault is in the panel path.

Pick a register that changes on its own at least once per second: a seconds counter, a free-running timer's current value, a pulsing status word. A static register tells you nothing about freshness, so leave setpoints and daily totals out of this test. Read the same value at three points:

• the process, from the sensor's local display or a gauge you can see;
• the controller, from its programming tool's data view or diagnostics table;
• the panel, from the mapped item on the suspect screen.

Note the time of one change at each point. If the controller's copy moves within 1 second and the panel's copy moves a minute or more later, the process and the controller are healthy and the panel path owns the fault. If the controller's copy is itself minutes old, the problem sits upstream of the panel, in the controller program or the process, and no panel setting will fix it. To use a timer's current value as the test register, the steps are in display a PLC countdown timer on an HMI panel.

What does each symptom point to?

Each pattern narrows the cause: fresh-after-reboot points to client session state, lag growing in poll-time steps points to queued or unanswered requests, and a wrong-but-steady value points to the register map rather than the network.

Match what you see against this list:

• Current right after a reboot, then drifting out of sync: startup rebuilds the panel's client session and forces a fresh request burst, so the first answers are current. The recurring cause sits behind that burst, and every reboot wipes the evidence.
• Lag that grows in steps of one poll interval: a 1000 ms poll producing ages of 60, 120, 180 s means requests are queued, unanswered or applied late; look at the controller's service and its other clients.
• A value that moves but is wrong, or is plausible and suspiciously steady: the item reads the wrong register, data type or word order. A neighbor register that moves a few times a day mimics a communications fault perfectly. Scaling produces the same look; the scaling case is covered in HMI shows the value ten times too small: fix the scaling.
• Every item on one connection freezing together: requests have stopped, so check the link and the controller's connection list before touching any timer.
• Lag that began when a historian or SCADA head-end was added: controller service contention; see the next section.

Over a serial link the symptom list looks similar for different reasons; HMI screen slow to update over serial with no errors covers that case.

How do I check which register the item actually reads?

Modbus references such as 40001 are not the number sent on the wire: the driver drops the 4 and subtracts 1, so 40001 goes out as offset 0 and a one-off mistake reads the neighboring register instead.

The 4 in a reference marks the holding-register table, and the number after it is one more than the offset the request carries: 40002 is offset 1 and 40100 is offset 99 (100 - 1). Drivers differ in which form they expect, so read the driver's own documentation for its convention before touching an address.

Then run the one-item test:

1. Choose one register you can watch change in the controller, and note its reference and offset.
2. Map one display item to it, and nothing else.
3. Compare the panel value with the controller value across five changes.

If the item shows the neighboring value, or a value that only moves when something else writes it, the offset is off by one or the reference form is wrong for the driver. Fix that one item first; once it tracks, apply the confirmed convention to the rest of the map in groups. Hold off rewriting the whole map until one item tracks correctly, because a map-wide change tells you nothing about which entry was wrong.

Could another client be holding the controller's Modbus service?

Yes, and the controller's documented connection limit decides it: published ceilings run from about 10 client connections on small gateway products to 64 or 128 on PLC Ethernet modules.

Modbus TCP expects the controller to serve several clients at once, but the connection count is a limit of the specific controller, not part of the protocol itself. Past the ceiling, the documented symptoms are what the panel is showing: dropped TCP connections and answers that arrive late. A controller rated for 128 connections is still run with 30 to 50 polling instances in practice, because each answer takes response time as well as a connection slot.

Check the controller side:

• its diagnostics page or status table for active connections, rejected connections and request or response error counters;
• its documentation for the connection limit and the behavior at the limit;
• the client list: every historian, head-end, second panel and engineering tool holding a session.

Note the panel's lag while the other client's scan runs and while it sits idle. If the lag tracks the other client, stagger poll groups or lower the request rate. If two or more panels share one controller, the staggering scheme is in connecting many operator panels to one PLC without slow updates.

What do I change, and in what order?

Save the project, record the panel and controller addresses and the affected items, then change exactly one setting at a time: mapping on one test item first, competing clients second, poll rate last, re-running the same observation after each change.

1. Save the project, then record the panel and controller IP addresses, the affected item references, the poll settings, and the displayed values with the time. Every later change is measured against this snapshot.
2. Run the three-point test on the fast-moving test register from the section above. If the controller's copy is fresh and the panel's is not, correct that one item's register reference.
3. Repeat the same observation after the change: five value changes, times noted at both ends.
4. Open the controller's Modbus diagnostics and account for every client connection; note rejected connections and error counters.
5. If another client is loading the service, stagger poll groups or lower the request rate, and re-test.
6. Leave the poll interval alone until the mapping and the service both check out; then size it to the register's own update period.

A reboot belongs at the end, not the middle. It restores the display for operators, and it is safe to do only while they have another way to see values that matter; record the displayed values and the time before you do it. A reboot resets client state and repairs nothing, and how quickly the staleness returns is itself diagnostic: a return that grows in even steps points back at the mapped register or a competing client, and a return only after hours points at a dropping connection.

Recommendation: When a panel trails its controller by minutes, stop editing the poll timer. Run the three-point test on one fast-moving register; if the controller's copy tracks the value and the panel's does not, correct that item's register reference first, then check every client on the controller's Modbus service against its documented connection limit. Change one setting at a time from a saved project, and reboot only to restore service after recording the displayed values.

Scenario: what should the panel show once the fix is in?

On a healthy link the panel trails the controller by one poll interval plus one response round trip: at a 1000 ms poll and a 30 ms response on a local network, expect the display about 1.03 s behind, not minutes behind.

The rule behind that expectation:

display age ≤ register's own update period + poll interval + response time

Scenario: a tank level item on a building automation controller. The controller updates the real level register every scan, so in under 1 second. The intended reference is 40001, which the driver takes as offset 0. The project instead carries offset 1, the 40002 reference, which points at a logged daily total the controller updates every 120 seconds. The poll is set to 1000 ms and the measured response round trip on the plant network is 30 ms.

Before the fix, the oldest value the display can show is the register period plus one poll plus one response:

120,000 ms + 1,000 ms + 30 ms = 121,030 ms ≈ 2.0 minutes

That matches the reported staleness of values a couple of minutes old, and it explains why every timer edit left the display unchanged: the requests were answered correctly, for the wrong register.

After the correction to offset 0, the display age ceiling drops to:

1,000 ms + 30 ms = 1,030 ms

so the panel trails by about 1 second. Prove it: watch the test item through ten changes and confirm the panel tracks each within about 1 second, with no rejected connections or error counters climbing on the controller. Then apply the same reference convention to the remaining items in groups, re-running the same observation after each group.

Questions