Yes: put the controller's Ethernet interface and both panels on one small unmanaged switch, or fit a second Ethernet module and cable each panel directly. No plant network is required, and extra update delay appears only when the second panel receives its values through the first.
Two operator panels can share one PLC with no plant network at all. The fastest wiring is three 100 Mbit/s copper ports on one unmanaged switch, straight patch cables, and static addresses in one subnet such as controller 192.168.10.1, panels 192.168.10.20 and 192.168.10.21, mask 255.255.255.0. The network in the usual wiring diagrams is only the building's existing Ethernet, and nothing about the panels requires it. A second Ethernet module builds the route without a switch, and a serial port can carry one panel when cabinet space is short. This article gives the parts list, the crossover rule by port speed, the serial bandwidth arithmetic, the delay a panel-to-panel path adds, a worked layout for a controller cabinet, and the sequence to configure and test the whole segment. The one arrangement to treat with care is data routed through a panel: it works, and it costs update time on the second screen.
Can two operator panels share one PLC without a plant network?
Yes, and the network in most wiring diagrams is just the building's existing Ethernet: you need a route into the controller's Ethernet interface for each panel, and a three-port local segment, one port for the PLC and one per panel, provides it.
The plant network in those diagrams is a convenience, not a requirement. Two wirings give both panels that route with nothing beyond the controller cabinet:
- One Ethernet interface plus a switch. Patch the controller interface, panel 1 and panel 2 into a small unmanaged switch and leave the uplink port empty. The switch needs at least three 100 Mbit/s copper ports for this, the figure one PLC vendor's commissioning guide states for exactly this topology, with unmanaged hardware accepted for commissioning.
- Two Ethernet interfaces with direct cables. The controller carries a second Ethernet module and each panel lands on its own interface, end to end with no switch. This is the wiring that uses crossover cables on older hardware, and the next section gives the rule by port speed.
Count interfaces in the controller's communications manual, not jacks on the cabinet door. Some controller families label two RJ45 jacks, X1 and X2, where both hang off one internal switch, so two jacks can still be one usable interface.
What hardware do I need for two panels on one PLC?
For the switch arrangement you need three things: a controller Ethernet interface documented to hold both panel connections, an unmanaged switch with at least three 100 Mbit/s copper ports, and one straight patch cable per device, plus a static address plan with three unique addresses.
Controller side
- An Ethernet interface or module whose manual documents concurrent panel connections; the published connection count covers this, and two panels use a handful of it.
- For the two-module wiring, a second Ethernet module with a free slot or port for it.
Switch
- An unmanaged five-port unit takes the three needed connections and leaves two ports, one for a service laptop running the panel software and one spare.
- Mount it at the controller; the segment is local and stays local.
Cables
- Straight-through patch cables to the switch. IEEE 802.3 allows 100 m per twisted-pair segment, so a two-panel layout around one deck or bay never comes close to the limit.
Addresses
- Static addresses on all three devices, because an isolated segment has no DHCP server. One working plan: controller 192.168.10.1, panels 192.168.10.20 and 192.168.10.21, mask 255.255.255.0, no gateway.
Mixed wiring only
- One serial cable to the controller's serial port, the matching driver selected in that panel's project, and the port settings the controller manual prints.
When is a crossover cable the right connection?
A crossover cable belongs to the two-module wiring: one Ethernet module per panel, each panel landing on its own controller interface with no switch in between. On 1000BASE-T ports any straight patch cable already works, because gigabit Ethernet requires automatic MDI/MDI-X crossover in both ports.
Port speed decides. Gigabit ports negotiate the crossover in hardware, so device-to-device or device-to-switch, one cable type serves. Ports fixed at 10 or 100 Mbit/s negotiate it optionally, so a direct panel-to-module link on that vintage of hardware needs a crossover cable, while panel-to-switch runs stay straight-through because a switch crosses its ports internally. Keep one crossover cable in the drawer for legacy modules and label it.
A separate walkthrough covers a legacy direct connection over crossover cable or serial protocol, port settings included.
Can one panel use serial and the other Ethernet?
Yes, if the controller communicates on its serial port and its Ethernet interface at the same time, a documented capability to confirm in the manual first. The serial panel needs a node address and the correct driver; the Ethernet panel needs an address in the controller's subnet.
The mixed wiring saves an Ethernet module when cabinet space is short. Its cost is serial bandwidth. One read exchange of an 8-byte request and a 12-byte reply moves 20 bytes, 200 bits with framing, about 10 ms of wire time at 19.2 kbit/s. Setpoints, alarms and slowly changing values ride that fine; dense animated screens do not. For symptoms and checks on the serial side, see why an HMI screen runs slow over serial with no errors; the port-by-port choices sit in connecting a PC HMI to a PLC over a serial protocol or Ethernet.
Distance closes the decision: RS-232's classic guidance is about 15 m at 20 kbit/s, RS-485 carries farther on a shared pair, and RS-485 multidrop lets several nodes share one port, which is how a third panel could join later.
How much delay does panel-to-panel sharing add?
Panel-to-panel sharing makes panel 2 read through panel 1, so a change can be three poll intervals old when panel 2 displays it: with 500 ms settings at each hop, the worst case is 1.5 s.
The hops stack because the value moves twice. Panel 1 polls the controller and stores the values; panel 2 polls panel 1's copy. A change can therefore wait one full interval at each of three places:
- Controller to panel 1: 500 ms poll interval
- Panel 1 refresh of its shared copy: 500 ms publish interval
- Panel 2 poll of panel 1: 500 ms poll interval
Worst case: 0.5 s + 0.5 s + 0.5 s = 1.5 s on panel 2, while panel 1 still shows the change within one interval of 0.5 s, because it reads the controller directly.
Route through a panel only for statuses and counts where a 1.5 s lag suits the job. Anything an operator must react to inside a second gets its own path: the switch wiring or a second module. As panels multiply, connecting many operator panels to one PLC without slow updates keeps the polling discipline straight.
How does an example layout look for two panels and one switch?
An example layout on a five-port unmanaged switch uses three ports in total: controller interface at 0.5 m, engine-room panel at 2 m, wheelhouse panel at 18 m, so 20.5 m of twisted pair against the 100 m segment limit and three static addresses in one subnet.
Scenario: a workboat with no network, controller and Ethernet interface in the engine-room console, one machinery panel at the console, one wheelhouse panel 18 m away. The same layout fits any plant annex without a network drop.
| Device | Address | Run to switch |
|---|---|---|
| Controller Ethernet interface | 192.168.10.1 | 0.5 m |
| Engine-room panel | 192.168.10.21 | 2 m |
| Wheelhouse panel | 192.168.10.20 | 18 m |
Mask 255.255.255.0 on all three, gateway blank, because no router exists on board. Total cable is 0.5 + 2 + 18 = 20.5 m, about a fifth of the 100 m limit, so cable grade is not a live concern. Three of five ports are in use; the laptop port and the spare port remain.
Both panels poll the controller directly, so a change lands within one poll interval, 250 ms in this project, plus well under a microsecond of propagation over 20.5 m of copper. Pull power from the engine-room panel and the wheelhouse panel keeps polling, because each holds its own switch port.
What order do I configure and test everything in?
Bring the segment up one device at a time: wire and verify panel 1 against the controller, then add panel 2 on its own verified path, and leave panel-to-panel sharing disabled until both direct paths read live values.
- Record the controller model, installed modules and free ports, then read its communications manual for two numbers: usable Ethernet interfaces and documented concurrent connections.
- Choose the wiring: one interface plus switch, two modules, or mixed serial and Ethernet.
- Set static addresses on all three devices in one subnet, unique last numbers, mask 255.255.255.0, no gateway.
- Cable panel 1, select its driver, download its project, and confirm it displays a value you force to change in the controller.
- Add panel 2 the same way on its own path with panel 1 powered, and confirm both follow the changing value.
- Enable panel-to-panel sharing only when the through-panel path is intended, measure its lag with the same changing value, and compare the measured lag against what the process needs.
- Record the wiring, addresses and poll intervals in the project file for the next engineer.
Then check the segment as a whole: pull power from panel 1 and confirm panel 2 keeps polling, because switch ports are independent. Test operator writes from one panel at a time with drives disabled or the machine otherwise in a safe state, starting from reads; testing operator-panel writes before motion is enabled gives that sequence in full. A lit link LED shows the cable, so judge each panel by values that change.
What if the second screen only shows notices, not live PLC data?
Then it needs no controller port at all: a self-contained sign that plays images and video from a microSD card or USB stick covers shift targets, safety notices and schedules with no PLC connection and no subscription.
Plants carry more of these boards than tag-driven panels: counters, goals, cleaning rounds, shift handover notes. A self-contained sign frees a controller connection for the true operator panel. A unit from our panel-mount range plays images and video built elsewhere, and shop-floor signage is the range made for this setting. The included player shows files, so live tag values stay on the operator panel where the driver lives.
Which wiring wins for two panels and no plant network?
The switch wins most two-panel builds: one Ethernet interface you may already own, three ports on an unmanaged switch, straight patch cables throughout, and each panel polling the controller directly with no added hop. The other two wirings cover the exceptions.
The two-module wiring earns its slot when a legacy controller already carries one Ethernet module and a second interface is free, or when two panels sit far apart and a switch at each end is awkward. The mixed serial wiring earns its slot when cabinet space blocks a module and the second panel shows slow-moving values.
Recommendation: For two operator panels on one PLC with no plant network, run one Ethernet interface into a small unmanaged switch, set all three devices static in one subnet, and verify each panel against a changing value before adding the next. Fit a second Ethernet module only when the installation already owns one, and route panel 2's data through panel 1 only for values where a 1.5 s lag is acceptable.
Questions
Do I need a managed switch for two operator panels?
No. An unmanaged switch forwards traffic between all its ports, which is everything a three-device segment needs, and one PLC maker's commissioning guidance accepts unmanaged hardware for this exact topology. A managed switch earns its cost later, for port diagnostics, VLAN separation or a ring recovery option; some industrial controller families support a ring topology only through managed hardware. Check the controller's communications manual before buying ring features.
How many panels can one PLC Ethernet interface serve?
The published connection count in the controller's communications manual is the limit, and two panels sit far below it, because each panel opens a small set of connections, typically one per driver topic or screen group. The consumer to watch is a PC client such as SCADA software joining the same interface later, so plan headroom in the published figure when a third consumer is possible.
Can several panels share one serial port instead?
Yes, on a multidrop serial network. On an RS-485 pair, the controller and every panel act as addressed nodes sharing one cable set, and Modbus RTU, a common protocol here, provides node addresses up to 247, so two panels on one port are ordinary practice. Each panel needs its own unique node address and driver settings, and all nodes share that port's bandwidth.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.