Multidropping 20 operator panels on one PLC serial port fails because a small panel is the serial master and the role does not reverse. Distance is fine: RS-485 and RS-422 both cover runs like this with room to spare. Use Ethernet panels to one switch, or a small PLC at each machine, with counts, goals and button writes owned centrally.
No. You cannot multidrop 20 operator panels onto one PLC serial port, and no adapter changes that. A small serial panel is the master of its link: it polls, the PLC answers. One panel polling many PLCs is a supported, documented arrangement; many panels onto one polled port has no protocol behind it. Distance is not your problem either: both RS-485 and RS-422 cover runs like yours many times over. The fix is an architecture change: Ethernet panels to one switch, or a small PLC at each machine feeding one network. This page gives the numbers for both, the data ownership that decides it, and the checks for the first station.
Can you multidrop 20 operator panels on one PLC serial port?
No. In the small serial panels used at machine stations, the panel is the master of the link and the role is fixed: one panel can poll several PLCs, but 20 panels cannot share one PLC port as addressed slaves. The direction that works, one panel reading many PLCs, is covered in connecting multiple PLCs to one HMI over an RS-485 network; the reverse direction has nothing to answer it.
Here is the test that settles it for the panel in front of you. Open the communication setup and look for a station, node or slave address the panel itself can be given. A master never needs one; it only configures the addresses of the PLCs it polls. If the panel's manual offers no address for the panel, there is nothing for a shared bus to talk to, and the multidrop question closes before cable enters the discussion.
Trying it anyway fails the way two-talker buses fail: the panel transmits a poll, the PLC port transmits a poll, and the line turns into collisions that show up as framing errors and timeouts. Two panels on one port fail long before twenty do, which is why two HMI panels failing on one PLC serial port traces to the same root.
Why doesn't an RS-422 adapter or a longer cable fix it?
Because the adapter converts the electrical layer and leaves the conversation alone: the panel still initiates every read and write, so a converter at the PLC changes the wiring, not who talks first. The role lives in the protocol and the panel's communication setup, and cable has no vote in it.
A serial converter is a real tool with a real job: it puts a short-range port on a long cable. It hands you no slave address. An address is something the panel's protocol either offers or lacks, and no converter adds one. The same goes for re-drawing the cable as a daisy chain, adding termination, or splitting pairs: those repairs signal quality on a bus whose members already agree on roles.
The four-wire RS-422 multidrop mode points the same way. Its documented arrangement is one master device holding the full-duplex pair over multiple slaves, which is the PLC-as-master direction, and it still needs slaves that answer. Your panels ask. No wiring makes an asker into an answerer.
How far can RS-485 and RS-422 actually carry panel traffic?
Far past your run: RS-485 is specified to 4000 ft of cable at 100 kbps and to 10 Mbps at 40 ft, and RS-422 spans the same 4000 ft with its full 10 Mbps rate kept to a 15 ft cable. Those endpoints come from the physical layer standards and the semiconductor design guides, and they trade length against speed in the obvious direction: the long cable gets the low rate.
A production display refreshing every 5 s generates a trickle of data, so the long, slow end of those ranges still carries this job with room to spare. Distance was never the blocker; the panel's role is. Where the distance ratings earn their keep is the machine-to-machine link: put a small PLC at every station and one RS-485 trunk at the conservative end of the range ties them all back to a master.
What can you build instead of the serial multidrop?
Four architectures cover this job, and all of them keep your panel count: Ethernet panels on one switch, a small PLC at each machine, paired serial cards at the central controller, or the machine network you already have.
| Architecture | What it changes | Pick it when | Watch out for |
|---|---|---|---|
| Ethernet panels, one switch | Every panel gets its own cable and its own connection to the central PLC | Stations only show goals and counts and take a few button writes | 20 home-run cables; switch port count |
| Small PLC at each machine | The panel talks to its own PLC; the PLCs share data over a network | A machine needs local I/O or local counting, or must run with the network down | 20 more programs to maintain; a polling scheme between PLCs |
| Serial cards at the central PLC | Two panels per communications card | The station count stays at a handful | 20 panels means 10 cards; only one port per card is the long-run port |
| The machines' existing network | Goals, counts and requests ride data that already flows | Machines already have PLCs and a network | Write access needs designing, station by station |
The first row is the usual answer for a display-and-buttons station; the wiring rules for several panels on one controller are covered in multiple HMI panels on one PLC without port conflicts. The second row is the answer when counting belongs at the machine: the panel sits on the station PLC's local port and the PLCs talk among themselves. Polling each site over Ethernet from one master is a worked pattern for that shape. If the site links must be serial instead, configuring a comms card for an RS-422/485 multidrop covers the port settings that arrangement needs.
Ethernet panels or a small PLC at each machine: which one?
Pick Ethernet panels when each station only shows data and takes buttons; put a PLC at the machine when the station must count cycles locally, hold state through a network drop, or control I/O of its own. One question decides the whole architecture: where is the count computed?
In this layout the cycle counts arrive at the central PLC and the stations read them, so nothing at a machine needs logic. The panel choice carries the design: one cable per panel back to one switch, one connection per panel, and each panel refreshes on its own connection instead of waiting for a turn on a shared bus. Holding the update rate up at panel counts like this is its own subject, covered in connecting many operator panels to one PLC without slow updates.
Recommendation: For 20 stations up to 300 ft out that display a goal and a count and carry a reset button and a material button, buy Ethernet-capable panels, one switch at the central station, and keep every count, goal and output in the central PLC. Add a small PLC at a machine only when that machine needs local I/O or must keep producing with the network down.
The serial-card row only makes sense if the station count collapses: two panels per card is tidy at four stations and absurd at twenty.
Who owns the goal, the count and the reset button?
The central PLC owns the goals and the material-request outputs, each machine's counter is owned wherever its counting input lands, and every reset button writes one bit that clears exactly one machine's count. Write that list before you draw the network, because ownership decides which writes get allowed.
Three marks cover every value in the system: central-owned, like the goal a supervisor enters; machine-owned, like the cycle count; and display-only, like a computed rate on a panel screen. A goal travels down to one station. A count travels up from one machine. A reset travels up from one station and must land on one counter. The material button is the one that touches hardware: it drives a real output at the central PLC, so the path from 20 buttons to 20 outputs has to stay separated per station.
Keep anything that stops or starts a machine off this network. It carries operator requests to the logic that owns the action, and it is not a safety function.
What does an example 20-machine build come to on paper?
Twenty-two Ethernet devices, 20 home-run cables, one switch with 2 ports spare and zero serial adapters: that is the whole bill for the recommended architecture, and here is the arithmetic. The plant has 20 machines with the farthest panel 300 ft from the central desk, one central PLC holding every count and goal, and one 8 to 10 in panel for the supervisor.
The supervisor enters a goal per machine, say 400 pieces per shift, and every remote display refreshes to a 5 s target with two buttons at each station. Count ports: 20 remote panels + 1 central panel + 1 central PLC = 22 devices, so a 24-port switch carries the system with 2 ports spare for the plant uplink and a bench panel. Count cables: 20 home runs, the longest 300 ft, all landing on that one switch. Count writes: 2 bits per machine, one reset and one material request, each momentary, each landing on one tag.
Now the dead end for comparison: 20 panels at 2 panels per serial card is 10 cards, and 10 cards need 10 expansion slots in one chassis. That arithmetic closes the serial route before you price a single card.
How do you prove one station works before wiring all 20?
Wire one remote station, then run five checks in order, each with a value you read off the screen or off the PLC: goal down, count up, reset, material request, network drop. Expand to the other 19 only after all five pass.
- Enter a test goal of 400 at the central panel. The remote station should show 400 inside the 5 s target, so time it.
- Force or run one cycle on machine 12. The count on the central view and on station 12 should step together from the same counter: one increment, both places.
- Press reset at station 12. Machine 12 goes to 0; machines 1 through 11 and 13 through 20 do not move.
- Press the material button at station 12. The central PLC drives only machine 12's notification output; check the output itself, not just the screen.
- Pull station 12's cable. Note what the panel shows with the link down, press reset while it is down, restore the link, and confirm the offline press was refused outright or needs repeating, never half-applied.
The last check is the one most installs skip and most complaints trace to: the operator has to know whether a button press counted.
What should you confirm before ordering 20 panels?
Four answers in writing from the panel vendor: that the panel supports multiple simultaneous connections to one controller, the update behavior at your station count, that panel writes can be limited tag by tag, and which exact model carries the Ethernet port. A panel family that cannot answer the first question is out of this job.
Ask with numbers, not adjectives: how many simultaneous connections to one PLC, what refresh rate at 20 panels reading 2 tags each, and what the long-run cable limit is per connection. Buy the switch against the port arithmetic from the example, not against the panel count.
Size the central desk panel by reading distance: what size digital signage screen you need works from 20 ft of viewing distance per inch of capital height, the figure for fast reading, so a supervisor at arm's length is the easy case and a board the whole floor reads is the one to size. If the floor also wants one big read-only target board, a plain signage display looping the shift's goals from a memory card does that job beside the panel network; see shop-floor signage displays.
Questions
Can I put two panels on one PLC serial port instead of twenty?
Two fails the same way twenty does: both panels try to initiate on a port that serves one master. Panels that support sharing do it through a mode the vendor documents, with a connection count stated as a specification. If the panel's communication manual shows no station or node address the panel can take, it cannot share the port, and that is a fact about the panel, not the wiring.
How do I size the Ethernet switch for this system?
Count devices, not panels: 20 remote panels plus the central panel plus the central PLC is 22 ports, so a 24-port switch leaves 2 spare. Add the plant uplink and any bench panel before you decide, and step up one size if the total passes the port count. An unmanaged switch is enough while everything sits on one flat network; go managed when the panels share a network with other traffic.
Is RS-422 or RS-485 the right link between the machine PLCs?
Use RS-485 two-wire for a polled party line where one master talks to many slaves in turn, and RS-422 four-wire when the master needs a full-duplex pair out to every slave. Both reach 4000 ft below about 100 kbps, so the choice follows the ports your PLCs already have. Your runs sit far inside either limit.
Can a plain signage screen do any of this job?
Only the half that never changes live. A signage display playing content from a memory card can loop the shift's targets where the whole floor sees them, but it cannot read a counter or take a button, so live counts, resets and material requests still belong to the panel network. It is a second screen, not a substitute panel.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.