How many HMI panels one PLC Ethernet card supports

How many HMI panels can one PLC Ethernet card handle?

Plan on 6 to 8 HMI panels per PLC Ethernet card: at the default loading a 20-panel job lands on 3 cards, and on 1 card if every panel stretches its poll interval toward a 3 to 4 second update target.

The number is a loading rule for the CPU, not a limit in the Ethernet standard. IEEE 802.3 puts no ceiling on how many clients address one interface; the card will hold dozens of sockets without complaint. The constraint sits in the PLC: every panel is a master that opens its own connection and reads or writes its screen's objects on its own schedule, and the CPU serves each of those transactions out of scan time. Twenty masters polling once a second means twenty streams of transactions competing with the scan, and every screen's update time starts to stretch.

Two numbers you set move the figure. The first is the poll interval in each panel's project: slower polls cut transactions per second in direct proportion. The second is how many separate address blocks each screen reads: a screen built on one contiguous block costs one transaction per poll, while the same data scattered over a dozen addresses costs a dozen. Many blocks, fast polls, or heavy write objects pull the figure toward 6. A few contiguous blocks and slower polls push it past 8, which is the lever the worked example uses.

Why can't 20 HMI panels share one serial line?

A serial multidrop network carries one master, and a panel that polls the PLC is a master, so twenty polling panels on one RS-485 line fight over the bus and the design fails before any card count matters.

RS-485, the TIA/EIA-485 standard, defines the electrical segment: a differential pair that carries up to 32 unit loads and leaves it to the protocol to sort out who talks. The protocols panels actually speak are master/slave. Slaves only answer. One master starts every exchange. Two panels that both act as masters on one PLC port collide over the wire, and the same collision scales straight up to twenty. Two panels on one PLC serial port fail exactly this way at small scale, and the HMI panel must be the serial master to the PLC because the protocol gives the master the right to start every exchange; why two HMI panels fail on one PLC serial port shows the collision, and why the HMI panel must be the serial master to the PLC explains which side owns the conversation.

The one-master rule is not a panel quirk. It is how a Modbus RTU multidrop works, and a guide to configuring a Modbus RTU master on an RS-485 multidrop network walks the arrangement end to end.

A serial-to-Ethernet converter changes the wire without changing the master count. Converters of this kind need a driver matched to the PLC's protocol, and master message relay in a Modbus RTU multidrop network only exists where the driver and the converter both support it, so a converter is not a route around the master limit.

How do you turn a panel count into a card count?

Divide the panel count by 8 and round up: 20 / 8 = 2.5, which rounds to 3 PLC Ethernet cards at the default loading, and to 1 card only if the poll arithmetic in the worked example holds for every screen.

Round up, never down: a card planned at 9 panels is a card planned past the figure, and the symptom arrives as stretched update times on every screen sharing it. Use 6 as the divisor instead when the screens carry many separate objects, several panels write to the PLC, or the CPU is small and already carries serial and remote I/O modules.

Three is a count of PLC interfaces, not switches. Eight panels on one card can hang off a single switch that feeds that card, so the switch count follows the layout and the cable runs, and it can be one switch or three. What matters at configuration time is which panel talks to which interface. The topology for networking many remote HMI panels to one PLC is its own design task, and the addressing rules that keep panels from fighting over one PLC's ports carry straight over to a multi-card layout.

Worked example: what does a 20-panel production-tracking line need?

At ordinary polling the answer is 3 cards, because 20 / 8 = 2.5 rounds up to 3, and at the 3 to 4 second update goal this line actually needs, stretched polls bring the same 20 panels onto 1 to 2 cards.

The line. Twenty machines feed cycle-count inputs to one central PLC. The supervisor enters a target per machine on a central panel that shows the department layout. Each machine gets a small panel showing its count, its target, and a full red or green screen. A department board shows totals for everyone to see. The stated goal: updates inside 3 to 4 seconds.

The inputs I assume. Each remote screen reads 2 contiguous blocks: one block with count and target, one status word. The baseline poll is 1 second. These are example values; read the real ones out of each panel project before you order.

Card count at the default loading. 20 / 8 = 2.5, round up to 3 cards. Check the traffic at that count: 20 panels x 2 blocks / 1 s = 40 block reads per second across the system, about 13 per card (40 / 3 = 13.3), under the roughly 16 reads per second that 8 panels draw at the baseline (8 x 2 / 1 = 16). The count fits.

Card count with stretched polls. The screen's job is a 3 to 4 second update, so set each panel's poll to 3.5 seconds: 40 / 3.5 = about 11 reads per second across the system, and 6 panels at the baseline draw 12 (6 x 2 / 1 = 12). Twenty stretched panels draw like 6 ordinary ones, inside the 6-to-8 figure on a single card. Worst-case display delay is one poll plus the draw, about 3.5 s plus a fraction of a second, which meets the goal, and a target entry lands in the PLC within one poll of the write.

The decision. Order 2 cards with 10 panels each: 10 x 2 / 3.5 = about 6 reads per second per card, roughly a third of the 16-read ceiling, with the central layout panel weighted as two ordinary panels on the first card. Trend the input-to-screen time under production load and add the third card only if the trend misses 4 seconds.

Can slower polling shrink 20 panels onto one card?

Yes, when every screen's job tolerates it: stretching the poll interval makes 20 panels draw about as much from the PLC as 6 panels at ordinary polling, which is the difference between 3 cards and 1.

The poll rate lives in each panel's project, set per screen group, and the cost is direct: a change shows up one poll late on average, and an operator's entry takes up to one poll to land in the PLC. Status boards, count displays, and tracking screens with seconds-scale goals absorb that. Screens that run a machine or take frequent operator input don't; keep those at their normal rate and count them at full weight.

Contiguous addressing is what makes the saving real. Group each screen's objects into blocks that one poll can read together; the same data spread across scattered addresses multiplies transactions and spends the saving. Laying each machine's count, target, and status into one consistent PLC data block gives every panel a clean read and keeps the traffic predictable.

A poll setting alone does not prove the update time. Measure the whole path, machine input to PLC count to panel screen, with the line in production; connecting many operator panels to one PLC without slow updates works through the same trade from the other side.

How many communication cards fit in the PLC rack?

Count usable slots, not total slots: one brick-style CPU family takes an Ethernet card in all 4 of its option slots, while a common modular family of the same era tops out at 7 cards because slot 0 and the expansion bases take none.

Those are two real families' limits, and your CPU's manual prints yours. Before ordering 3 cards, open the slot table for the CPU and every base, count the slots that accept a communications module, and subtract the serial, remote I/O, and specialty modules that want the same slots. A 20-panel design that needs 3 Ethernet cards, a serial module, and a remote I/O module needs 5 usable slots, not 3.

Check the CPU's list of supported HMI connection mechanisms too, panel family by panel family: a CPU that doesn't serve your panel's connection type won't be fixed by a third card. And if the I/O count is what pushes the project from a brick CPU to a modular one, the same move usually solves card slots in the same stroke.

Which option should you pick: 3 cards, stretched polls, or serial?

Pick stretched polls and 2 cards when the screens only report status, 3 cards at ordinary polling when any screen also takes operator control, and serial multidrop only for displays that are slaves behind a communications master module.

Serial wins exactly the case in the table: display hardware built as slaves, fed by a communications master module, which is how text-marquee style lines reach 32 devices on one RS-485 run. The moment a device has to poll as a master, and an HMI panel that reads tags and writes targets does, the line is Ethernet.

Recommendation: for 20 master-style panels on one PLC, budget 3 Ethernet cards at ordinary polling. If every screen is status-only with a 3 to 4 second update goal, order 2 cards, set the poll interval to about 3.5 seconds, keep each screen's data in contiguous blocks, and trend the update time under production load before deciding on the third card. Keep serial multidrop out of the panel design, because every polling panel is a master.

When should a status screen not be an HMI panel?

When the screen only shows what the PLC has already decided, it doesn't need to poll anything, and every screen you drive instead of poll is a screen that stops counting against the 6-to-8 figure.

Split the architecture by who touches the screen. HMI panels belong where an operator acts: the central panel where the supervisor enters targets, and any machine panel with controls on it. Boards that only display, the red-or-green machine screens and the department totals board, can be driven instead: the PLC or a small intermediary flips the content when state changes, and the board never opens a connection to the PLC.

That is the job our small panel-mount signage units are built for. They are Android all-in-one screens that play images and video from microSD or USB with no subscription and take a trigger over their RS232 port; the serial image command for memory-card playback documents the flip-between-two-status-images pattern exactly. For a dusty or washdown corner of the floor, the front face is IP65 and the operating range is -10 to 60 °C; see them in our shop-floor screens.

Drive the department board and the red-green screens this way and the card count shrinks with them: the panels left on the cards are the ones that genuinely need PLC drivers. One safety line belongs here: a red or green status board is advisory, and it never substitutes for the machine's own controls, alarms, or any indicator the machines' safety requirements call for.

What should you check before ordering the cards?

Bring four numbers to the order: the panel count including every master, the poll interval each screen can tolerate, the block count each screen reads, and the number of rack slots that accept communications modules.

On the panel side:

• The model list and each model's driver for your PLC's protocol, confirmed in the panel documentation.
• Which panels write to the PLC and what they write, because write objects weigh more than reads.
• Each screen's object layout, with an eye to contiguous blocks.

On the PLC side:

• The slot table for the CPU and every base, with slots that accept a communications module counted and everything else that wants a slot subtracted.
• The CPU's supported HMI connection mechanisms, checked against your panel family.
• The data map: each machine's count, target, and status laid out contiguously so one poll reads one block.

On the network:

• An IP plan that gives every PLC interface and every panel an address, and records which panel talks to which interface.
• A switch port count taken from the layout, cable runs included.

At startup:

• Bring up one card with a few panels, confirm live reads and writes, then add panels in stages.
• Trend machine input to screen change under production load and compare it to the goal, 3 to 4 seconds in the worked example.

Questions