Stop an HMI polling PLCs that are not installed

What the panel actually polls

An HMI panel does not poll every controller named in the project. It polls the controllers behind the tags on the active screen: a tag bound to a field is requested while its field is visible on the open screen, and not while the screen is closed. Three functions sit outside that rule. Trend graphs, event triggers and alarm logging keep their controllers in the poll list whether or not their screen is displayed, which is why a graph sampling controller 4 keeps the errors alive on a screen that otherwise reads only controller 1.

A tag set to poll on a fixed interval is transferred at every tick whether or not its value has changed, so an absent controller is asked again on every pass until the request fails and the panel logs the error. The screen split also depends on clean bookkeeping: per-device tag lists are what let you say, for any tag in the project, which controller it belongs to and therefore which controller it can bother. Pointing one panel at several PLCs with per-device tags is exactly the bookkeeping that makes the split hold.

Prove the poll rule on your own panel once, with the walk-through in the example below; one pass through the screens settles it.

Symptoms and what each points to

• A PLC Communication Timeout error appears only when one screen opens, and only at sites missing a controller. A tag on that screen still references the absent controller. Trace every field on it back to its device, including small status objects.
• The error appears while the operator sits on a screen that reads only installed controllers. A trend graph, event trigger or alarm function still references an absent controller.
• The errors survive the screen reorganization. Whatever remains is global: graphs, events, alarms or tag logging.
• The error names a controller that is installed and running. That is a genuine communications fault, a wiring, address or network problem, and it must not be folded into the absent-controller cleanup.

Group screens by controller

Build each screen around the controller that supplies it. Controller 1 screens read controller 1, controller 4 screens read controller 4. Because the same slot number runs the same program at every site, a controller 4 screen works unchanged at any site that has a controller 4, and never opens at a site that does not.

A screen that mixes controllers is a contract with the network: list every controller it references and treat all of them as required whenever that screen is open. Give a site its own copy of any mixed screen it cannot satisfy.

While you are in there, keep the request count down. Where the driver allows it, collect a screen's tags into one block read instead of several small polls, and the controllers that do exist answer faster.

Find the references hiding outside screens

Inventory the project before you edit anything:

1. List every tag and mark the controller behind it.
2. Mark every place the tag is used: screen fields, trend graphs, event triggers, alarm conditions, tag logging.
3. Circle the uses that are not tied to a screen. Those are the uses that keep polling.

Then re-source what you can. An alarm condition that watches a controller some sites lack can be evaluated inside a controller every site has, with a single result bit handed to the panel. The alarm history then lives in a circular event buffer in the controller, and the panel reads one bit from a device that exists instead of chasing one that does not.

Example: commissioning the one-PLC site

Inputs. The universal project references controllers 1 to 5, and every site installs the same program in the same slot number, so controller 3 is controller 3 everywhere; these come from your project brief. The smallest site installs controller 1 only, because site sizes run from 1 to 5 controllers, so 5 - 1 = 4 controllers are absent. The alternative under consideration is one project file per site size, which today means 5 files.

Rule under test. The poll list is the active screen's tags plus trend graphs, event triggers and alarm logging. A clean project therefore raises no absent-controller error anywhere on this site, on any screen.

Arithmetic. One fix landing in the site-file route means 1 edit x 5 files = 5 edits, with 5 chances to miss a site. The same fix in one universal project means 1 edit x 1 file = 1 edit. The one-PLC site exposes 4 of the 5 controller references at once, which is why it is the test site.

Walk-through. Connect controller 1, load the project, and open every screen in order, graph screens included. Note the controller number named in each PLC Communication Timeout error.

Result and decision.

• Every error names a controller from 2 to 5: a reference to an absent controller survives. Find it in the inventory, move it onto a screen this site never opens, or re-source it from controller 1, then repeat the pass.
• Any error names controller 1: an installed controller is not answering. Stop editing the project structure and chase the wiring, the address or the network.
• Zero errors across a full pass: the structure holds at the hardest site. Larger sites only add controllers, and each added controller should light its screens up with no new error.

Test the smallest site first

The one-controller site is the sharpest test because 4 of the 5 controller references fail there at once. A screen split that passes there survives every larger site, where more of the referenced controllers exist.

1. Connect only the controllers the site actually has.
2. Walk every screen, graph screens included, and note each timeout error with its controller number.
3. Record the project revision and the exact controller set tested, so the next engineer can repeat the same pass.
4. Move up one site size and repeat. The added controller should bring its screens alive with no new errors.

At sites running all five controllers, the panel chases five devices at once. Letting a master PLC aggregate the tags cuts the poll list to one device and frees poll time for the screens that matter.

When to split into site files

Split only when a screen cannot be satisfied: it needs a controller a site will never have, and its tags cannot be re-sourced from a controller the site does have. When you split, keep a shared change checklist, because every fix now lands in 5 files and the checklist is what stops one site running last month's logic. Deliver each variant from a memory card or USB drive at commissioning and keep the programming software with you, so the project stays yours to change.

The decision

Recommendation: Keep one universal project. Group screens by controller so a site only opens screens for the controllers it has, source trend graphs, event triggers and alarm logging from controllers every site runs, and commission at the smallest site first, where 4 of the 5 references fail at once. Split into per-site files only when a screen cannot be re-sourced from an installed controller, and keep a shared change checklist when you do. Leave the PLC Communication Timeout alarm visible: at a complete site it is the alarm that catches a controller that really has stopped answering.

Questions