Connect two HMI panels with a crossover cable, no switch

Can two HMI panels share one Ethernet cable with no switch?

Yes: two HMI panels can talk to each other over a single Ethernet cable with no switch and no router, provided each panel has its own static IP address and the link carries nothing but traffic between the two panels.

Ethernet at its simplest is a point-to-point link: one cable segment, two interfaces, nothing in between. A router does two jobs, handing out addresses and joining different subnets, and a two-panel cable needs neither job done. What the cable cannot do is grow: a third device has nowhere to plug in, so the arrangement is only correct while the panels are the entire Ethernet load.

Count the nodes before you buy anything:

1. Panel A and panel B only, with each PLC reached on a serial port or through one panel's pass-through: the direct cable works.
2. Any PLC, laptop, camera or plant network that also needs a port on that link: buy a switch.
3. The next project might add a node: fit the switch now. Abandoning a spare patch cord costs minutes; a line waiting for a free port costs a shift.

What IP addresses do two directly connected panels need?

Give each panel a different address in the same subnet, such as 192.168.10.10 and 192.168.10.11 with a 255.255.255.0 mask, and leave the default gateway blank because there is no router on a two-node link.

DHCP is out of play here: the box that normally runs a DHCP server is a router, and there is no router, so a panel left on DHCP never receives an address at all. Set both panels to static in their network setup screens, and while you are there make sure the two host numbers differ. If one panel previously ran on DHCP and nobody wrote its address down, the walkthrough on finding the address a DHCP panel actually took settles it before you wire anything.

The subnet check is one line of arithmetic. With a mask of 255.255.255.0, the first three numbers of the address name the network, so 192.168.10.10 and 192.168.10.11 both sit in network 192.168.10.0. Each panel therefore treats the other as directly connected and never consults a gateway, which is convenient because the gateway field is empty. On an isolated two-panel link any private range works; if one panel also carries an Ethernet path to a PLC on a second port, give the panel-to-panel link its own subnet so the two networks stay separate.

Do you still need a crossover cable with gigabit ports?

Usually no: a gigabit port crosses its own transmit and receive pairs automatically, so a straight patch cable works between two modern panels, and the crossover cable matters on older 10/100 ports that lack the auto swap.

The crossover cable exists because two ordinary ports both transmit on pins 1 and 2 and listen on pins 3 and 6; the crossed wiring carries each end's transmit pair into the other end's receive pair. The gigabit Ethernet standard builds that swap into every 1000 Mbit port, a feature usually labelled Auto-MDIX, so a plain patch cable links two gigabit panels without a second thought. The crossover cable still earns its place in the toolbag for the older panel whose 10/100 port cannot swap pairs.

Work it in this order on site: fit the straight patch cable, look at the link lights, and keep one crossover cable for the port that stays dark. A dead cable and a missing crossover both show as no link, so the cable swap is the cheapest test you own and takes about thirty seconds. One more gigabit quirk: 1000 Mbit needs all four pairs in the cord, so a damaged patch cable that links at 10 or 100 Mbit has an open pair and deserves replacement before commissioning.

When does a direct cable stop being enough?

The moment a third device needs that wire, the direct link is finished: an Ethernet cable joins exactly two interfaces, so a PLC that must be reached over Ethernet, a laptop used for project downloads or the plant network all call for a switch.

The rule is a count, not a judgement call: two interfaces per cable segment. A switch is simply a box that turns each port into a fresh two-node segment, and the table shows where each arrangement wins.

Distance sets the second limit: a copper twisted-pair Ethernet segment tops out at 100 m. A 15 m tray run between two panels sits comfortably inside it. A second panel mounted 1,500 ft away is a different job: 1,500 ft is about 457 m, more than four times the limit, and that run needs the treatment described in connecting a remote HMI screen 1,500 feet from the PLC.

So where each one wins. The direct cable wins on simplicity: one cord, no box to power, no switch to fail, addressing finished in two setup screens. The switch wins on growth: PLCs, laptops and future panels plug in without rewiring, and long runs split into fresh 100 m legs. Pass-through adds its own weight to the cable layout: the server panel becomes the middleman for the client's traffic, and a reboot of the server panel takes the client's PLC path down with it.

How does pass-through work between two panels?

Pass-through lets one panel reach the PLC behind the other panel across the cable, and the panel help sets the roles: one panel runs as the client and the other as the server, a documented configuration to check in the help before you depend on it.

Panels that offer the feature describe it in their help as a client and server arrangement. The panel that owns the PLC path acts as the server; the panel borrowing that path acts as the client, and its screens read and write the PLC's registers across the cable as if the PLC were local. Set the roles to match the wiring: the panel holding the PLC cable is the server, the remote panel is the client. If you want each panel to reach the other's PLC as well, the help for your panel family states whether chained pass-through is allowed; it is a heavier arrangement than one client and one server, and the update speed carries the load.

The same arrangement answers the one-PLC question. Two panels with matching screens can both control one PLC across a direct cable when one panel holds the PLC path and serves the other. A toggle behaves because both projects point at the same register: operate it on either panel and the other panel shows the register's new state. The care point is the write side, and two HMI panels writing one PLC: who wins the write covers the conflict rules to settle before handover.

Performance tracks the passed parameter count. Everything the client screen displays crosses the cable and the server panel, so update speed follows how many values are passed, not the cable length. Start with the few values the remote screen truly needs, add the rest in small groups, and watch update behaviour after each group; if a screen turns sluggish, cut the passed set back before touching the wiring.

What does a worked example look like: two panels, one PLC, no switch?

Here is the whole job with real numbers: two addresses in one 255.255.255.0 subnet, a 15 m cable against the 100 m segment limit, six passed values to start, and a two-way toggle test before handover.

Scenario: a packaging cell needs a second panel at the outfeed so either operator can start, stop and jog the line. The PLC lives in the main cabinet and speaks serial, this cell has no plant network, and the layout leaves no room for a switch.

Wiring and addresses:

• Panel A sits in the main cabinet; its serial port carries the PLC cable, so panel A is the pass-through server.
• Panel B sits at the outfeed; a crossover cable runs 15 m along the tray from panel A's Ethernet port to panel B's. Panel B is the client.
• Panel A: 192.168.10.10, mask 255.255.255.0, gateway blank. Panel B: 192.168.10.11, same mask, gateway blank.

Check the arithmetic once. The mask 255.255.255.0 fixes the first three numbers of both addresses, so 192.168.10.10 and 192.168.10.11 land in network 192.168.10.0 and each panel reaches the other with no gateway involved. The cable uses 15 m of the 100 m copper segment limit, which leaves 85 m of margin for the tray route and the terminations.

Say the outfeed screen needs six passed values: start, stop, jog, speed setpoint, line speed and one fault bit. Commission with exactly those six and confirm the screens update at operator speed before anything else joins the set; add later values group by group and retest after each group.

The link test is the pass-through value itself: if panel B's screen tracks the line speed register, the cable, both addresses and the server role are all verified in one observation. Toggle start from panel B and watch panel A's indicator, then toggle stop from panel A and watch panel B follow. One safety note: with two stations able to command the line, run the toggle tests under your site's lockout rules with nobody inside the machine, and treat the second panel as a real second point of operation from day one.

The dependency is the price of the no-switch layout: when panel A reboots, panel B loses its PLC path until the server panel is back. If the outfeed operator must never lose that screen, this requirement alone moves the job to a switch.

How do you prove shared control before handover?

Test both directions before handover: change a value from panel A and confirm panel B shows the new PLC state, then operate the same toggle from panel B and confirm panel A follows it back.

1. Write a known value into the shared register from panel A and read it back on panel B's screen.
2. Toggle the register off and on from panel B while a second person watches panel A's indicator and, where the machine allows it, the PLC output itself.
3. Reverse the direction: operate from panel A and confirm panel B follows.
4. Load the client screen's final, full parameter set and repeat steps 1 to 3; this is the test that catches a project that ran briskly with six values and crawls with sixty.
5. Power-cycle the server panel once and record what the client loses and how long it stays lost; that record is the commissioning note for the dependency you accepted in the layout.

A first-setup fault on this link has a short check order: link lights, addresses, roles, then the PLC path. The walk-through in fixing an HMI-to-PLC Ethernet timeout on a first setup follows the same order for the timeout case.

Crossover cable or switch: which do you buy?

Buy the crossover cable only when the two panels are the entire Ethernet load and the next project will not add a third node; buy a small unmanaged switch the moment a PLC over Ethernet, a laptop or the plant network needs a port on that link.

The decision repeats across plant work: a direct link is a finished design for exactly two interfaces, and a switch is a design that accepts the next interface without a rewiring job. Addresses stay static either way; the switch adds ports and asks nothing new of the panels.

Recommendation: set both panels to static addresses in one small subnet and run the direct cable when panel-to-panel is the whole Ethernet load and will stay that way; put a small unmanaged switch in the cabinet as soon as any PLC, laptop or plant network needs that link, and keep one crossover cable in the toolbag for the older 10/100 port that will not swap pairs on its own.

Questions