Group HMI screen addresses into dense ranges for faster updates

Why screen position is the wrong map

The panel does not walk the screen left to right and top to bottom, object by object. It collects the addresses the screen uses, merges them with event and trend addresses, and builds packets that cover the set in as few requests as it can form. Which objects share a packet depends on which addresses they reference, so a tag's row and column predict nothing and its address predicts nearly everything.

That makes the development software's address list, not the canvas, the working map. Sort the tags by address and the grouping falls out: values that sit consecutively travel together, values split by gaps travel apart. A screen carrying 140 objects, each with its own visibility condition, looks chaotic on the canvas and is still just one list of addresses on paper.

The panel's exact packet plan is its own logic and depends on the addresses requested. The part you control is the set of ranges it has to cover.

What the panel reads besides the screen

Three additions join the read set, and panel documentation names them:

• Trends. Opening a screen that contains a trend sets request bits in a trend request area, so the trend's addresses ride the same aggregation for that screen.
• Alarm and tag events. Driver documentation for panel families lists alarm events and tag events among the functions that issue their own read requests, whatever the screen shows. An event that swaps screens when an alarm bit turns on keeps that bit in the set, and Event triggered screen change on an HMI when a PLC alarm bit turns on shows how such events attach.
• Logging and change-of-value tags. One runtime reference manual lists alarm tags, data logger tags and controller tags with value change events among the items a panel reads on every pass, even with no object displaying them.

A screen whose visible objects look compact can therefore span more ranges than the object list suggests. Trends add one more failure mode: if a grouped screen still misses a 0.5 s trend refresh, the trend object's interval settings are the next stop, and Why an HMI trend graph will not update every half second walks that check.

Symptoms and what each points to

Match the behavior to the cause before editing anything:

• Refresh got slower as objects were added. More objects usually mean more address ranges, and each separate range costs at least one read per pass.
• Rearranging objects changed nothing. Grouping follows addresses, so canvas edits leave the request count where it was.
• Plain values update but trend or alarm data drags. Trend, event and logging addresses sit in the same aggregated set, often in ranges far from the screen values.
• A switch to Modbus TCP changed nothing. The request count is the same under either protocol, so the bottleneck travelled with the addresses; a protocol swap by itself does not touch update speed.
• Hiding objects did not speed anything up. A visibility condition does not necessarily pull its address out of the read set. The panel documentation describes hiding objects tied to the process and stops there, so measure it on a copy before counting on it.

If the link is Modbus TCP and data lands late even on a lean screen, poll intervals and timeouts are their own causes, covered in Fix Modbus TCP data slow to update on an HMI panel.

Example: count the ranges on one screen

Scenario: a production screen shows 12 process values, one trend of 4 words and 3 alarm bits, and the target refresh is 1 second. Measured today, a full screen update repeats every 2.4 seconds.

Inventory before regrouping:

• Process values at V2000, V2001, V2100, V3000, V3001, V3015, V5000, V5002, V10000, V10001, V10020 and V10021. Sorted and cut at every gap: V2000-V2001, V2100, V3000-V3001, V3015, V5000, V5002, V10000-V10001, V10020-V10021. That is 8 ranges; V5000 and V5002 count separately because unused V5001 breaks the run.
• Trend words at V2105 through V2108. 1 range.
• Alarm bits: two in word V0300 and one in word V9820. Two words, so 2 ranges.

Total: 8 + 1 + 2 = 11 separate ranges, so the panel needs at least 11 read requests per pass. Count every gap as a break; if the panel spans a short gap with one block read, the real count comes out lower, and this count is still the number to beat.

Divide the measured refresh by the request count for the planning average: 2400 ms / 11 requests = about 218 ms per request. That average lumps protocol turnaround and screen drawing in with the reads; it is a planning number from this baseline, not a datasheet value.

Regroup. The PLC writes the 12 values to V2000 through V2011, the trend words to V2012 through V2015, and a copy rung mirrors the three alarm bits into V2016. One block read now covers V2000 through V2016, 17 words, inside the 125-register cap of a single Modbus TCP read. Requests per pass: 11 down to 1.

Predicted refresh: 1 × 218 ms = 218 ms, about 0.22 s. If the panel splits the block in two, 2 × 218 ms = 436 ms, about 0.44 s. Both beat the 1 second target with margin, under the same screen, driver and production traffic.

The fix: group addresses into dense ranges

1. Save a copy of the running project before editing anything, so the baseline screen and the original addresses stay reachable.
2. Inventory the read set. List the addresses the screen objects reference from the development software's cross-reference or tag usage view, then add the addresses behind alarm and tag events, and the trend or data-logging tags. Miss this step and the regrouping optimizes half the traffic.
3. Sort ascending and count ranges. Every gap that separates consecutive addresses starts a new range, and the range count is the floor for reads per pass.
4. Regroup in the PLC. Move related values into consecutive words, mirror scattered bits into one word with a copy rung where the logic allows, then point the HMI tags at the new addresses. Verify the dependent logic before the change reaches the PLC.
5. Keep blocks purposeful. Dense and related wins; merging unrelated values into one giant range to chase a single read does not, and every driver has a block limit per read, 125 registers for Modbus TCP, its own printed number otherwise.
6. Retest under the same conditions: same screen, same driver, same production traffic. Time a repeatable update the way you would before moving a panel from serial to Ethernet, over several cycles, and compare with the baseline.
7. Put back anything switched off for diagnosis. Alarms, events and trends that were disabled to isolate the test come back on, and the retest confirms the grouped layout holds with them running.

How to check it worked

• The refresh interval, measured the same way as the baseline, meets the target set for the screen.
• Trend and alarm data update together with the plain values instead of trailing behind them.
• A second screen left untouched still updates at its old pace, which ties the improvement to the grouped addresses rather than to network luck.

Recommendation

Recommendation: Inventory the full read set, screen objects plus alarm and tag events plus trends, on every screen that updates slowly, count the separate ranges, and regroup related values into consecutive PLC addresses until that count is small. Keep the Ethernet driver that already works and change protocol only when the project needs it for another reason. If the PLC layout cannot move, mirror the values into a dense block with copy logic and point the HMI tags there.

Questions