HMI protocol bridge limits with Modbus RTU and DF1

The pair check decides, and it comes first

Supported driver combinations are a published property of the panel's project software, not a hidden behavior. Open the Panel Manager screen and choose add protocols; the tool reports the pairs it cannot combine. Ethernet-plus-serial pairs are the broad case. Serial-to-serial pairs are a short list, and Modbus RTU beside DF1 is one of the pairs that gets ruled out, while Modbus RTU beside certain other serial PLC drivers is allowed.

Treat the verdict as final for that panel. Two drivers cannot share the hardware unless the tool says the pair combines, because one physical serial port carries one conversation at a time. Support for each protocol on its own says nothing about running both on the panel at once. If the exact two drivers are rejected, editing addresses cannot change the result: addresses select data inside a conversation, and the conversation itself has no driver to run on.

If the PLC link basics are the unclear part, start with connecting a PC HMI to a PLC over a serial protocol or Ethernet, then come back to the pair question.

Symptoms and what each one points to

• The add protocols screen rejects the pair. The combination is unsupported on that panel. The work left is architectural, a converter or a different panel, not tag edits.
• The project holds one driver per serial port and both devices are serial. Port capacity, not addressing. One physical port serves one driver.
• Drive values update, PLC objects show a communications error or hashed placeholders. The PLC driver was never added, or it is assigned to a port with no cable on it. Check the driver-to-port assignment.
• Each link works alone with one driver added, both fail with two. Resource contention between the two drivers on the panel. Checking each protocol on its own cannot reveal this conflict, so the combined configuration belongs in the plan from the start.
• Tags show bad address syntax after a driver swap. The tag database still carries the old driver's address format. Re-enter the tags in the new driver's format.

Checks, in order

1. Confirm each protocol from the device itself. Open the PLC's communication channel configuration and write down the protocol name, the port, the baud rate, parity and station address. A paper note reading "DH 1" is a guess for DF1; if the channel screen shows a peer network type instead, a DF1 driver and a DF1 converter both stop at that wall and the plan changes there. On the drive side, confirm RTU framing: Modbus RTU and Modbus ASCII frame every byte differently, so an RTU master cannot poll an ASCII device, and every device on the segment must be set to RTU.
2. Run the pair check before touching a tag. In the Panel Manager, choose add protocols, select the PLC driver and the Modbus RTU master driver, and read the report. Accepted: continue with step 3. Rejected: skip to step 4.
3. If the pair is accepted, assign drivers to ports and match settings. Point each driver at the physical port its cable reaches, and take baud, parity, stop bits and station address from each device's own configuration. The Modbus serial-line specification sets 9600 baud, 8 data bits, even parity, 1 stop bit as the default and calls for two stop bits when parity is off; many drives ship set to 8 data bits, no parity, 1 stop bit anyway, so read the drive parameters. Valid Modbus station addresses run 1 through 247, one master is allowed per RS-485 segment, and the usual RS-485 planning figure is about 1200 m of segment at a rate such as 9600 baud. When two drivers want the same wire, see two Modbus RTU masters on one RS-485 bus: why and the fix. Power the drives and PLC down and apply your site's lockout procedure before you break into the loop or move a shield termination.
4. If the pair is rejected, plan the converter. A dedicated protocol converter sits between the PLC and the Modbus segment, and its datasheet must name the PLC-side protocol and Modbus RTU on the other side, with the role of each port. If the PLC's serial port is already spoken for, the options are in adding another operator interface when the PLC ports are full. Build the address map on paper first: PLC register, Modbus register, scaling, one row per value.
5. Test each link alone, then both together. Bring the Modbus side up first; the Modbus RTU no-reply and address checklist gives the ordered checks when a station answers nothing. Bring the PLC link up alone the same way. Only then run both, and confirm the panel raises a communications error when you pull one side offline, so a dead path is visible instead of frozen numbers.

Worked example: six Modbus RTU drives and one PLC on DF1

Scenario: a panel already polls six drives on one RS-485 loop, 150 m long, at station addresses 1 through 6, set to 9600 baud, 8 data bits, no parity, 1 stop bit, the values this example's drive manuals state. The project needs 20 integers from a PLC whose channel screen reports DF1 full-duplex over RS-232 at 19200 baud. The add protocols report rejects Modbus RTU together with the DF1 driver.

The fix keeps the panel on its one Modbus RTU master driver and inserts a converter whose datasheet lists DF1 on the PLC side and Modbus RTU slave on the drive side. The converter takes station address 20, inside the valid 1 to 247 range, and maps the 20 PLC integers to holding registers 40001 through 40020.

The poll budget decides whether one sweep is quick enough. A 20-register read costs an 8-byte request and a 45-byte reply, 53 bytes in total. At 8N1, RTU sends 10 bits per byte, so one exchange moves 53 × 10 = 530 bits. At 9600 bits per second that is 530 ÷ 9600 ≈ 55 ms per station, plus a few milliseconds of turnaround inside the converter. Seven stations, addresses 1 through 6 plus 20, sweep in about 7 × 60 ms ≈ 0.42 s, so a 1 second update period on the panel is comfortable and a 250 ms period is not. The 20-register block also sits under the specification's limit of 125 registers in one read.

Decision: one driver, one master, seven stations, and the PLC data arrives at station 20 like any other node. The DF1 conversation never reaches the panel, which is exactly why the rejected pair stops mattering.

What to check on a converter before you buy

• Both protocol names, each tied to a side. The PLC protocol spelled out on one side, Modbus RTU on the other, and the physical interface named per side: RS-232 or RS-485, and which end supplies the cable pins.
• The role of each port. Slave toward the panel in the example above; master toward the drives if the PLC is the device that must poll.
• An explicit map. Source register, destination register, scaling, written as a table before any configuration screen is opened. A PLC register number and a Modbus register number are unrelated figures until this table relates them.
• Setup from the converter's own documentation. The panel never sees the PLC protocol at all, so the converter's manual is the only configuration reference for that side.

The decision

Recommendation: run the Panel Manager's add protocols check with the exact driver pair before you edit a single tag. If the pair is accepted, assign each driver to its own port, match every serial setting from the device configuration, and test each link alone before both run together. If the pair is rejected, as Modbus RTU with DF1 usually is, keep the panel on its single Modbus RTU driver, insert a converter that lists both protocols on its datasheet, give the converter a station address between 1 and 247, and map PLC registers to Modbus registers in a written table with the scaling next to each row.

This is a machine-interface job on the machine's own panel. If the floor also needs a notice or status board playing your own content, that is a separate screen with a separate question, and our shop-floor signage is where that side starts.

Questions