One RS-485 port can carry thirty text panels electrically, 32 unit loads per TIA/EIA-485-A, yet refresh too slowly because the port polls panels one at a time. Size each port by polled bytes and scan time: at 9600 baud with 40-byte exchanges, about eight panels per port keeps each screen under half a second, so thirty panels split over four ports.
Thirty keypad text panels on one PLC is a plan that passes its electrical checks and still disappoints on the floor. The bus is fine; the polling scan is not. This article gives the numbers behind that gap: what the RS-485 standard actually limits, how to compute a port's screen-refresh time from bytes, baud and panel count, and how to split the panels across several PLC serial ports so every screen updates fast enough for the line. The control load barely matters here. Thirty-five discrete inputs and thirty-five discrete outputs at 24 VDC is a small I/O job, and the communications design, not the I/O count, should drive which PLC you buy.
How many operator panels can one PLC serial port serve?
Plan on eight text panels per PLC serial port, not thirty: the RS-485 electrical limit of 32 unit loads is not the constraint, the polling scan is, and a port carrying thirty panels updates each screen about three to four times slower than a port carrying eight.
A polled serial bus is a queue. The PLC port addresses one panel, waits for its reply, then moves to the next, and a screen only changes when its turn comes around. The time between turns is the scan:
scan per port = panels x ( (bytes per exchange x 10 bits per byte / baud rate) + driver turnaround )
Two documented layouts show the spread. Multidrop multiplexer arrangements for text panels were specified at five panels per PLC port. A communications master built for text displays was documented carrying thirty panels on a single port, with the vendor's own warning that this is a heavy traffic load and the panels should be split as much as possible. Both layouts are electrically legal: thirty panels sit under the standard's load cap, and most modern transceivers present only one-eighth of a unit load each, so the electrical count passes while the scan quietly grows. That is why the port count is a timing decision, not a wiring decision.
What does the RS-485 standard actually limit?
TIA/EIA-485-A, the standard behind every RS-485 port, requires a driver to develop at least 1.5 V of differential signal across at most 32 unit loads in parallel with two 120 Ω termination resistors, and it says nothing about panel addressing, polling order or update time.
RS-485 is the physical layer: differential signaling over a single twisted pair, shared by every station on the bus. The driver test is the number to remember, and it is why a thirty-panel bus wires up without complaint.
Termination is the part installers get wrong. Fit the resistor across the pair at the two cable ends only, one per end. Many PLC serial ports carry the 120 Ω resistor inside and expose a jumper or a dedicated termination terminal; jumpering that terminal to signal ground switches the internal resistor in. Enable it at both cable ends and leave every mid-bus panel unterminated. Daisy-chain from panel to panel and keep each drop spur short; a star of long branches reflects signals back down the pair. At the kilobit speeds text-panel buses run, cable length is rarely what limits you.
Everything else that makes the panels work, addressing, the poll format, the reply format and how often the port cycles the stations, lives in the panel protocol above the standard. A datasheet that says RS-485 answers the wiring questions and none of the timing questions.
How do I split thirty panels across several PLC ports?
Give each serial port its own group of panels and keep the groups balanced: on a PLC whose CPU has two serial ports, add plug-in communication modules to create more ports, as one common rack family does with up to six modules for a documented 40-interface layout.
| Arrangement | Panels per port | Scan per port, example figures | What it costs you |
|---|---|---|---|
| All panels on one port behind a master that advertises thirty | up to 30 | about 1.4 s | Simplest wiring, slowest screens; the documented warning says split the load |
| Multiplexer groups, one group per PLC serial port | 5 | about 0.23 s | One port per group; the documented 40-interface layout needs two CPU ports plus six plug-in modules |
| ASCII multidrop terminals, terminal logic in the PLC program | 10 to 20 | about 0.5 to 0.9 s | Cheapest hardware; the ladder program arbitrates operators pressing keys at the same time |
| Ethernet text panels on a switch | no shared serial scan | set by the PLC's connection limit | Needs PLC Ethernet support, a switch and a checked connection count |
The multiplexer route is the conservative one: five panels per port matches the layout the panel family documented, and it scales by adding ports. On a PLC whose CPU provides two serial ports, one documented rack arrangement added up to six plug-in communication modules, carried forty text interfaces at five per port, and kept those modules out of the first rack slot. Reserve that slot for I/O and spread the rest across the panel groups.
The ASCII multidrop route trades hardware for ladder logic. The terminals share one port cheaply, and the PLC program owns every interaction: what happens when two operators press keys at the same time, which terminal may write a shared setpoint, and how each screen is identified. Decide those rules before you buy; they are the whole cost of this option.
Ethernet text panels remove the shared serial scan entirely, and each new panel becomes a switch port instead of a delay. The PLC still caps how many concurrent connections it serves, so ask for that number too. When the serial ports you have are already committed, the walkthrough of adding another operator interface when the PLC ports are full covers both routes. The same divide-the-load arithmetic appears when several PCs poll one PLC directly or through a relay.
Worked example: how much refresh time does a four-port split save?
With the assumptions in this example, thirty panels on one 9600 baud port refresh each screen about every 1.4 s, and the same thirty panels split over four ports refresh about every 0.4 s, nearly four times faster, because each panel waits behind seven others instead of twenty-nine.
The example inputs are assumptions for a typical text panel, declared so you can swap in your own: 9600 baud, 10 bits per byte on the wire, one exchange of a 10-byte request and a 30-byte reply, and 5 ms of driver turnaround per exchange.
Per panel:
- (10 + 30) bytes x 10 bits per byte = 400 bits
- 400 bits / 9600 bits/s = 41.7 ms
- 41.7 ms + 5 ms = 46.7 ms per panel
One port with all thirty panels: 30 x 46.7 ms = 1401 ms, so each screen updates about every 1.4 s.
Four ports of seven or eight panels: the worst port carries eight, 8 x 46.7 ms = 374 ms, so each screen updates about every 0.37 s.
Six ports of five panels: 5 x 46.7 ms = 234 ms per scan, which is why the five-per-port layouts felt comfortable.
What moves the result: bytes and panel count move the scan linearly, baud moves it inversely, turnaround barely counts. Let a trend screen grow the reply to 130 bytes: (10 + 130) x 10 / 9600 = 145.8 ms, plus 5 ms turnaround, and the one-port scan stretches to about 4.5 s. Data volume, not device count, is what sinks a port. When the scan grows past a panel's reply timeout, screens start reporting intermittent communication timeouts, so the failure announces itself before the operators do.
Recommendation: split thirty text panels over four or more PLC serial ports, about eight panels per port, and size each port so its calculated scan stays under half a second. Use six ports of five when any screen polls more than about 40 bytes per refresh, and accept a single port only when the panel count is eight or fewer and the process tolerates a one-second refresh.
When is one port still the right choice?
One port still works when the process tolerates a slow screen: at the example's 40-byte exchange, twenty panels keep the scan just under one second and eight keep it under half a second, so sparse alarm-and-count screens can share a port at the higher count.
Alarm lists, batch counters and setpoint entry are light traffic, and operators do not need sub-second freshness to act on them. Machine-control screens are the other case. If an operator presses Start and watches for the machine's state to change, that feedback rides the same scan, and a 1.4 s wait reads as a fault. Give screens that drive actions the fast target.
One safety rule outranks all of it: every stop function that protects a person stays hardwired. An emergency stop runs through its own safety circuit, and no polled register on a shared serial bus belongs in that path.
What should I ask vendors before ordering panels and PLC ports?
Get the recommended panel count per port, the bytes your busiest screen exchanges per refresh, the baud rates every device shares, and the PLC's port expansion rules in writing before you order, because those four numbers decide the split and everything else is wiring detail.
- The recommended panel count per port for your screen mix, not the maximum the datasheet advertises.
- The bytes exchanged per screen refresh for your busiest screen, so you can run the scan calculation instead of guessing.
- The baud rates every panel and the PLC port share, since the scan divides by it.
- How the port count grows: total serial ports with plug-in communication modules, and any slot a module may not occupy, such as the first slot in the documented rack arrangement.
- What termination the port provides: a jumper, a dedicated terminal or a resistor you fit yourself.
- Whether the multidrop master appears on the bus as one node or one node per panel, because that decides the unit-load count.
- The concurrent connection limit on the Ethernet side, if you are considering Ethernet panels.
The first two numbers turn the sales conversation into arithmetic you can run.
How do I prove the update rate before go-live?
Prove the split with the whole line connected: power every panel at once, put a register that changes every second on each screen, time the slowest panel's refresh, and record the measured scan as the baseline you judge later screen changes against.
- Wire the bus as a daisy chain with termination switched in at both cable ends, then test with every panel connected and powered, because a scan that looks fine with five panels crawls with thirty.
- Watch one panel and time how long its displayed value takes to step, then repeat panel by panel and record the worst.
- Have several operators press keys at the same time on the ASCII multidrop and multiplexed layouts, since concurrency is where these designs fail.
- Write down the accepted baseline: panels per port, bytes per screen, baud rate and measured scan time.
More on screens along the line, from choice to mounting, sits in the shop-floor screens and boards section.
Questions
Does the 32-unit-load limit decide how many panels I can connect?
The standard counts unit loads, and many modern RS-485 transceivers present one-eighth of a unit load, so a bus can carry far more than 32 nodes before the driver struggles. The electrical count almost never decides refresh speed first. Size ports with the polling scan: bytes per exchange, panel count and baud rate set the scan time, and the split rule stays the same.
Should I just raise the baud rate instead of adding ports?
Raising the baud rate helps: at 19200 baud the example's 41.7 ms of frame time per panel drops to 20.8 ms, so the thirty-panel scan falls from about 1.4 s to about 0.8 s. The 5 ms of driver turnaround does not shrink with baud. Doubling the baud roughly halves the scan, and adding ports divides it, so a faster bus plus four ports is the strongest combination.
What actually happens if all thirty panels stay on one port?
Nothing fails electrically and the layout wires up easily, but every screen waits out a full scan, about 1.4 s in the example and longer on data-heavy screens. The documented thirty-panel, one-port layouts carried a warning that updates turn slow and the load should be split. Expect sluggish screens, and on tight poll cycles, intermittent communication timeouts.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.