Run the same polling client on every floor PC, each with its own connection and a scan interval in seconds sized to what that screen shows: 1 to 2 seconds for live values, 5 for count boards. One documented Ethernet module carries 64 simultaneous connections, so a typical floor polls directly. Build a relay PC only when clients pass the documented limit, and keep a spare if you do.
You have one PLC and several screens on the floor. The first design that comes to mind is a single PC that reads the controller and hands the values on to the rest, and the worry behind it is that PCs polling directly will plug up the connection. The numbers say otherwise on a typical floor: a documented Ethernet interface module takes dozens of simultaneous connections, poll load is set per PC in seconds, and a relay tier adds one custom server whose failure blinds every screen at once. This page gives you the deciding numbers: the connection limit to read from the manual, the interval each screen actually needs, what a poll costs the controller's scan, a worked six-screen example, and where each design wins.
Should one PC read the PLC for every floor screen?
Give every floor PC its own connection to the PLC and pace it in seconds, because one documented Ethernet interface module carries 64 simultaneous connections and a floor of two to ten screens uses a fraction of that budget. A relay PC earns nothing on a floor that size.
The relay plan costs a server program to write, debug and keep alive, plus client code that talks to that server. The direct plan costs one client configuration copied to each PC. Failure exposure moves the same way: a dead PC takes one screen down in the direct design, while a dead relay PC takes every screen down at once.
The relay also saves none of the resource you were worried about. It still polls the PLC at some interval, so the controller work is the same; the only change is that the screens now depend on one extra machine.
If a screen only shows values and takes no commands, you are building a status display, not an operator interface, and the polling decision is the same for both; the split between those two jobs is its own choice (factory status display or operator HMI).
How many connections can the PLC take at once?
Read the rating from the controller's Ethernet interface manual before you count clients, because every client that stays connected, a programming laptop included, holds one connection for as long as it polls.
The figure lives in the Ethernet chapter of the manual, usually printed as simultaneous connections. Count the steady consumers: each floor PC, any Ethernet operator panel, a logger or historian, and the laptop during a commissioning job. Display vendors document sharing schemes in the double digits on one controller, one reaching 16 display units on a single PLC, so the ceilings are not single-digit numbers.
The decision on this count: if the steady client list, laptop included, fits inside the printed rating, the connection budget argues for direct polling. If it does not fit, the relay design later in this page comes back into play.
How many seconds between polls does each screen need?
Size each client's interval to what its screen shows: 1 to 2 seconds for live process values, 5 seconds for production counts and status boards, 10 to 30 seconds for slow boards such as shift totals and notices, because poll load is controlled per PC in seconds.
| Screen content | Interval | Basis |
|---|---|---|
| Live values the operator acts on | 1 to 2 s | a change older than that misleads a hands-on decision |
| Count boards, andon, status boards | 5 s | the crew acts on a count a few seconds old without losing pace |
| Shift totals, notices, slow counters | 10 to 30 s | nothing on the board moves faster |
OPC server documentation gives the same advice from the server side: a slower scan interval gives the server time to gather data from the device before the next poll, so a rushed interval buys stale values, not fresh ones.
Build it in this order. Set every client slow. Add clients one at a time. Tighten a screen's interval only when an operator reports lag, and when lag appears, work down the factory screen update delay checklist before touching the PLC.
Read in blocks while you are at it. One poll of the word that holds a 16-point card costs one transaction; sixteen single-point tags cost sixteen. Same values, one-sixteenth the transactions, and a shorter start-up on the client.
Does polling slow the PLC's scan?
Each poll costs controller time, because at least one PLC family documents that its OPC UA server runs inside the program cycle and adds to cycle time, so keep the client count and the intervals inside what the manual prints and switch off communication the floor does not use.
The same vendor's optimization note states the countermeasure for its own server: disable or delete communication services the application does not need, which frees controller time for the clients you keep. Treat that as the general rule for any controller: the manual prints the limits, and unused services eat into them.
The cost is metered and you can see it. The programming software displays scan time. Note it before a second client connects, add the client, note it again. If scan time moves, slow the added client's interval first and trim its item list to block reads.
With intervals in seconds and one block per poll, a floor of screens is small change to a healthy controller. The printed limits, not the wire, are what bind.
Worked example: six PCs on one PLC?
Two live screens at 2 seconds, three count boards at 5 seconds and one notice board at 30 seconds make 98 polls per minute into the PLC and use 7 of a documented 64 simultaneous connections, so this floor polls directly with room to spare.
Setup: one PLC whose Ethernet module is rated for 64 simultaneous connections. Six PCs: two screens show live vessel values, three show production counts, one shows the shift notice. Each PC reads one block of 100 consecutive 16-bit registers. A programming laptop joins during jobs.
Polls per minute come from the interval: 2 s gives 30 polls/min, 5 s gives 12, 30 s gives 2. The floor total is 2 × 30 + 3 × 12 + 1 × 2 = 60 + 36 + 2 = 98 polls/min.
Connections: 6 PCs + 1 laptop = 7 steady clients, which is 7 of the rated 64, about 11% of the module's budget.
Traffic: each poll carries 100 registers × 2 bytes = 200 bytes of payload. 98 polls/min × 200 bytes = 19,600 bytes/min, about 327 bytes/s. That is a rounding error on a wired link.
Counter-case: all six PCs at 1 s. That is 6 × 60 = 360 polls/min, 3.7 times the controller work of the sized plan, while the wire traffic stays trivial. The wire never argues for a relay; the controller's cycle time argues for sizing the intervals.
Relay case, same floor: it still generates the same 98 polls/min into the PLC, adds a second network hop, adds a server program to maintain, and its failure blinds all six screens at once. Nothing on this floor improves. Direct polling wins on every count.
When does a relay PC actually win?
A relay PC wins only when the client count reaches the controller's documented connection limit or the path to the PLC is one serial port that a single reader must own, and you accept that one server failure blinds every screen it feeds.
Three cases put a reader PC back on the table:
- The client list reaches the printed connection limit: screens down every corridor, dozens of viewers on one controller.
- The path to the PLC is one serial port or a bridged gateway, so a single reader must own the link and everyone else reads from that reader.
- One machine has to log every value anyway. If that machine exists, letting it feed the screens is a design decision you make once, with a spare imaged and on a shelf.
In every case, take the failure mode up front: the server going down blinds every screen it feeds. Build the spare, and make every client show a fault state when the feed dies, which is the next section's rule.
What should the screen show when a poll fails?
Bind the screen's fault state to the OPC quality flag and read it with every value, because the specification delivers a quality code alongside each item, and a screen that keeps showing the last good number after the link dies is lying to the operator.
The check is cheap and it belongs in the build. Unplug the client's network path to the PLC, or stop the client, and confirm each screen trips to its fault state within one interval. A 5-second board must show the fault inside 5 seconds; if it keeps displaying the old count, the quality code is not bound to the display.
Keep the machine's behavior out of this layer entirely. Interlocks, sequencing and stop logic live in the PLC ladder, and controller manuals go further: they instruct you to configure safety circuits external to the controller so the system stays safe even when a fault occurs. A display PC that dies must never take a machine stop with it.
Which design should you pick for your floor?
Pick the same polling client on every PC with intervals sized per screen for anything up to the controller's documented connection limit, which covers the common case of 2 to 10 floor screens, and build a relay tier only when the count or the path forces it.
| Same client on every PC | Relay PC | Gateway serving browser screens | |
|---|---|---|---|
| Code you maintain | one client, copied to each PC | server plus client code | gateway configuration, no client installs |
| Connections into the PLC | one per PC | one | one |
| If it fails | that screen goes dark | every fed screen goes blind | every fed screen goes blind |
| Ceiling | the manual's connection rating | one server's capacity | one server's capacity |
| Pick it when | the steady client list fits the rating on a wired path | the count reaches the rating, or the PLC's port is serial | many thin clients, a spare gateway ready |
Every count in this page lands on the same side for a floor of 2 to 10 screens. Connections run 7 of a rated 64 in the example. Controller work is metered in polls per minute and settles once the intervals are sized. A relay saves none of it while adding a server program and a shared failure. The relay is a scaling tool, and scaling tools come out when the numbers demand them.
When the screen itself is signage on the wall, a count board or a sensor status display, the display side has its own planning: start from the offline sensor status display plan, see how to show a live dashboard on a signage screen, or browse the shop-floor screens category.
Recommendation: Run the identical polling client on every floor PC, each with its own connection and its own interval: 1 to 2 seconds for live values, 5 seconds for count and status boards, 10 to 30 seconds for slow boards. Read the simultaneous-connection rating from the controller's Ethernet manual and count every steady client, laptop included. Build a relay PC only when that count reaches the rating or the PLC's only path is serial, and keep an imaged spare on a shelf if you do.
Questions
How many display units can share one PLC connection over Ethernet?
One HMI product line documents a master-and-slave scheme: one master display unit plus up to 16 slave display units connected to one PLC simultaneously over Ethernet. That figure belongs to that display family's sharing feature. Read it as a sign that multi-screen sharing is a solved problem, then check the simultaneous-connection rating printed in your own controller's Ethernet manual before you rely on any of it.
How much network traffic does direct polling add?
Payload is registers times two bytes: a block of 100 16-bit registers is 200 bytes per poll. At the worked example's 98 polls per minute that is about 19.6 kB per minute before protocol overhead, roughly 327 bytes a second. A wired Ethernet link shrugs that off; the resource to manage is the controller's connection count and its cycle time.
Can two PCs write values back to the PLC?
Give each writable register one owner. If two clients write the same word, the last writer wins and operators overwrite each other. The usual pattern is a request bit per PC and a done bit back from the controller: the client sets its request, the ladder acts and clears it, and the next PC's turn follows. Interlocks and sequencing stay in the ladder, where no display link can remove them.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.