Match an HMI driver to a PLC Ethernet interface on one switch

Which protocol should the HMI driver use for a PLC on the same switch?

Use the driver for a protocol that the PLC-side Ethernet interface's own manual lists; the switch's brand and the shared cabling decide none of it. The switch is a courier. It reads the hardware address on each frame and sends it toward the right port. It holds no concept of a register, a tag or a protocol, so two devices on one switch share a wire and nothing else.

The overlap lives in two documents. On the controller side it is the manual of the exact Ethernet interface wired to the switch: a CPU with built-in Ethernet, a network module in the rack, or a separate gateway. On the panel side it is the driver list in the panel's configuration software, where every entry names a protocol and the interfaces it was written for. Read both lists and pick from the overlap. The same discipline governs a serial link: check the PLC serial protocol before replacing a legacy HMI when the new panel hangs on an RS-232 or RS-485 port.

What do you need before you configure the driver?

Collect five things: the PLC-side Ethernet interface model and its manual, the panel software's driver list, an IP plan for both devices, one safe test register, and a laptop for ping tests.

• The model of the PLC-side Ethernet interface, read from the module label or the controller's module configuration, plus that model's manual.
• The panel's driver list, opened in its configuration software on your laptop.
• An IP plan: one address and one subnet mask per device, and gateway values if the site routes between subnets.
• One test register: a 16-bit holding register in the PLC, or the closest status area the driver speaks, that the program writes for information only.
• A laptop on the same switch, so you can ping the interface before the panel is involved.

The test register earns its place on the list: it drives nothing and carries no interlock, so a wrong read costs a wrong number on screen and no more.

How do you find the protocols the PLC-side Ethernet interface supports?

Read the protocol list in the manual for the exact Ethernet module or card wired to the switch, because the processor family name on the cabinet door is not the interface and names none of its protocols. Open that model's manual at its section on application protocols, Ethernet services or socket services, and write the list down before you open the panel software. It usually contains some of these:

• Modbus TCP server: the interface accepts connections from clients, and an HMI is a client.
• EtherNet/IP adapter or scanner: the interface plays one role and pairs with the opposite role on the far device.
• A vendor protocol: reachable by the driver written for that interface family, or by a gateway in front of it.

Roles matter as much as names, and an EtherNet/IP device manual shows the pattern. The device's own documentation states the roles it supports and the communication rates it handles, and the far end must supply the matching role. If the list holds no Modbus TCP and nothing your panel ships, a gateway module that serves Modbus TCP to the panel while speaking the controller's protocol joins the same switch and carries the link.

Which IP settings must match before you touch the driver?

Put both devices on one subnet before the first test: addresses from one network block, the same subnet mask, no duplicate address on the network, and link lights lit at the panel, the switch and the interface. Walk the layers in order, because each one gates the next.

Link lights confirm cable, port and power, and a dark light sends you to the cable first. Twisted-pair segments are limited to 100 m between a device and its switch port, the twisted-pair Ethernet limit. Then compare addresses. A duplicate address anywhere on the network shows up as intermittent delivery that mimics a protocol fault. The check is arithmetic: address AND mask for each device, and the two results must be equal.

Last, ping the interface from the laptop. A reply means the IP path is open and whatever remains lives in the protocol settings. A timeout is an addressing or cabling problem first; some controllers answer ping only when their network services are enabled in the controller's configuration, so read that setting before you condemn the cable.

Which service port does each protocol use?

Modbus TCP servers listen on well-known TCP port 502, the port the protocol reserves for that job, while the panel as the client picks its own local port and needs no fixed number configured. A Modbus TCP introduction states the server port, and a vendor FAQ on the ports a CPU releases for Modbus TCP fills in the panel side: the client sets its own local port as it wishes, so nothing on the panel's outbound side needs to match.

EtherNet/IP explicit messaging is a registered service on TCP port 44818, and vendor protocols use the ports their manuals state. Two rules keep this layer honest. Read the port from the interface's documentation; do not infer one from the word Ethernet. And if the switch is managed, check its port filtering before blaming the driver, because an access list that omits TCP 502 blocks every Modbus TCP read while link, addresses and ping all look healthy.

Which driver do you pick from the panel's driver list?

Pick the driver whose documentation names both the protocol and the interface you identified, and pick Modbus TCP only when the interface's manual lists Modbus TCP server support.

• The interface lists a Modbus TCP server: use the panel's Modbus TCP driver, destination set to the interface's IP address, service port 502 unless its documentation states another port.
• The interface lists EtherNet/IP and the panel ships that driver: use it, and pair the roles, panel as scanner against an adapter interface.
• The interface lists only a vendor protocol: use the driver named for that interface. If the panel has none, the gateway from the section above carries the link.
• Neither side shares a protocol: check the controller for a serial port that speaks Modbus RTU and move the link to the panel's serial port, or budget the gateway.

Match the data type as well as the address; a 16-bit read of a register the program holds as something else returns a wrong value on a working link.

Recommendation: Select the panel's Modbus TCP driver when the PLC-side interface's documentation lists Modbus TCP server support; enter that interface's IP address as the destination and leave the service port at 502 unless the documentation says otherwise. Choose the driver named for a vendor protocol when that is all the interface lists, and when no driver on either side shares a protocol, put a Modbus TCP gateway on the switch instead of hoping a different switch will change anything, because no switch translates protocols.

Worked example: what does a correct setup look like on one 8-port switch?

An HMI panel at 192.168.1.20 with mask 255.255.255.0 talks to a PLC Ethernet card at 192.168.1.10 through one 8-port switch, both devices landing on the 192.168.1.0 network, with the panel's Modbus TCP driver aimed at TCP port 502. The scenario: Modbus TCP server support documented for the card.

• Addressing: 192.168.1.20 AND 255.255.255.0 = 192.168.1.0, and 192.168.1.10 AND 255.255.255.0 = 192.168.1.0. Equal results mean one network, so no gateway entry matters to this test.
• Cabling: 12 m of patch cable from panel to switch and 25 m from switch to card, 37 m in all, each segment inside the 100 m twisted-pair limit.
• Driver: Modbus TCP client, destination 192.168.1.10, service port 502, client local port left at its default.
• Test tag: holding register 40001, protocol address 0, data type 16-bit unsigned. The program writes a line count into that register; it holds 1234.

Bring the link up in layer order. Link lights lit on all three ports, ping answered, driver connected, and the panel shows 1234. Change the line count in the PLC to 5678 and the panel follows on the next poll. Each layer was checked separately, so a failure at any step has one place to look.

How do you configure the device entry, step by step?

Create one new device entry in the panel's communication setup, select the driver you settled on, and enter the destination address, the service port and a single test tag before touching anything else in the project.

1. Retire the wrong entry. In the panel's communication setup, remove or disable the device entry aimed at the wrong protocol or connection, so only one definition targets the interface.
2. Add a new device entry and select the driver settled above, Modbus TCP client or the vendor driver.
3. Enter the destination address, the PLC-side interface's IP, and the service port, 502 for a Modbus TCP server.
4. Create one test tag: holding register 40001, 16-bit unsigned, at an address the program writes for status only. A tag aimed at an output or an interlock can move equipment on a stray write, so keep the first tag read-only.
5. Save the project and download it to the panel.
6. Watch the panel's communication status come up in order: link, connect, first read.

How do you check the link without guessing?

Read the test tag, change the value in the PLC, and watch the panel follow, because a value that tracks a controlled change from the PLC side closes the job with evidence at every layer. Branch on what the panel reports:

• Ping fails: cabling, address, mask, or a disabled network service in the controller's configuration. Nothing above that layer can work yet.
• Ping passes and the driver times out: the protocol or its port is wrong, or a managed switch is filtering it. HMI pings the PLC but reads fail: check the protocol driver is this branch in detail.
• The driver connects and the value is wrong or frozen: the register address or the data type, and why HMI tag address formats change between PLC protocols explains how one register reads differently across protocols.
• The driver reports a protocol error on the Ethernet link: what PLC-011 invalid function code means on an Ethernet HMI link covers the case where the interface answers but refuses the function the driver sent.
• Every test passes and the panel's own link indicator still shows offline: red offline link indicator when the TCP port test passes explains that mismatch.

For a link that has to stay healthy after commissioning, plant a heartbeat: have the program increment a counter register, put it in a corner of the panel, and use a PLC heartbeat counter to confirm polls keep arriving once the laptop goes home. Test any write last, on a safe address, after reads have behaved.

The decision, one line per case: a documented Modbus TCP server means the panel's Modbus TCP driver at TCP port 502; a documented vendor protocol means the driver written for that interface; no shared protocol means a gateway or the controller's serial port. A cabinet that also owes the line a notice board can take a separate shop-floor signage display beside the HMI, a screen for targets and downtime doing a different job.

Questions