Connect an HMI to a PLC with Modbus RTU when no driver fits

Why a missing driver is not a dead end

An HMI driver list is a library of tag maps written for specific PLC families. A missing entry means no ready-made tag map, not a wall. Modbus RTU is the shared language both sides usually speak: the HMI side offers a generic Modbus RTU master driver, and most PLCs offer a Modbus RTU slave on a serial port, printed in the communication manual. The roles are the ones you already know from wiring an HMI panel to a VFD over Modbus RTU: the panel polls, the device answers.

Use the generic path in the right order. If a native driver exists for the exact PLC model, use it, because it maps tags and data types for you. The generic Modbus driver is the fallback that asks you to do the mapping by hand, and hand mapping is what the rest of this page covers. If the PLC manual shows no Modbus RTU slave anywhere, stop there: a generic driver has no way to reach it, and the wider choice of protocol and port is laid out in connecting a PC HMI to a PLC over a serial protocol or Ethernet.

The serial settings to match on both ends

Modbus RTU carries every message over plain serial settings, so the two ends must agree on five numbers:

Every device on the bus needs a unique address between 1 and 247, and 1 is the common factory setting on a slave, so start there unless the manual prints something else. For parity, take what the PLC's Modbus slave documentation states; devices ship at either no parity or even parity. With no documented format, set 9600 8N1 (9600 baud, 8 data bits, no parity, 1 stop bit) as the first attempt and change parity to even as the second, one change at a time.

Keep exactly one master on the wire. Two masters polling one RS-485 bus produce dropped and collided frames, a fault with its own diagnosis in two Modbus RTU masters on one RS-485 bus: why and the fix.

Map one known register before you build the screen

The PLC manual's Modbus section assigns its data to four register areas: coils, discrete inputs, input registers and holding registers. Numeric displays and most HMI objects read holding registers, the block entered with a 4-prefixed address: 40001 is the first holding register in a driver field that counts from one, and 0 in a field that counts from zero. Which convention your driver uses is printed in its own manual, and getting this one line wrong is the most common first-connection fault, the same one behind an HMI numeric display that shows nothing until the tag address is right.

Pick one value the PLC already changes every scan, a counter, a clock word or an analog average, find the holding register the manual assigns to it, and enter that single address in one numeric display object. Match the data type too: a plain 16-bit unsigned integer displays as-is, while a register that carries BCD or a scaled analog shows nonsense, the fault pattern explained in why an HMI reads a BCD analog register as garbage numbers.

Commission it in this order

1. Save a copy of the HMI project before touching its communications setup, so a bad half-hour ends in a restore instead of a rebuild.
2. In the PLC, enable the Modbus RTU slave on the serial port. The setting lives in the serial-port configuration; your model's manual names it and prints the port's station address, baud and format.
3. In the HMI project, add the generic Modbus RTU driver and enter the same station address, baud, parity and stop bits.
4. Wire the bus: A to A and B to B on RS-485 with the signal common joined, and a 120 Ω terminator across A and B at each end of the cable, the value that matches typical twisted-pair data cable. On RS-232, follow the wiring diagram printed in both manuals.
5. Put one numeric display on the HMI screen, pointed at the one holding register you mapped, with a 500 ms refresh.
6. Go online with the PLC, make the mapped value change, a forced bit or a running counter, and watch the display follow.
7. Write the working driver, address and register map into the project notes, then extend the map one register group at a time.

Worked example: bus time for one register polled every 500 ms at 9600 baud

Inputs, each from the setup above or from the RTU framing rules:

• 9600 bits/s, the line speed set in steps 2 and 3.
• 104 µs per bit at 9600 bits/s, because 1 ÷ 9600 s ≈ 104 µs.
• 11 bits per character, the RTU character frame: 1 start bit, 8 data bits, 1 parity bit, 1 stop bit.
• 3.5 characters of silence on each side of a message, the gap the RTU framing rule requires.
• 8 characters out and 7 characters back for a single holding-register read: station, function, start address, register count and CRC out; station, function, byte count, two data bytes and CRC back.

Rule in words: one poll takes the sent characters plus the received characters, plus 7 characters of framing silence, each character taking 11 bits at the bit time.

Arithmetic:

• Character time: 11 × 104 µs = 1,144 µs ≈ 1.14 ms.
• Message: 15 characters × 1.14 ms ≈ 17.2 ms.
• Framing silence: 2 × 3.5 = 7 characters × 1.14 ms ≈ 8.0 ms.
• One poll: 17.2 ms + 8.0 ms ≈ 25.2 ms of bus time.
• At a 500 ms refresh: 2 polls per second × 25.2 ms = 50.4 ms, about 5% of the bus.
• Ceiling at 9600 baud: 1,000 ms ÷ 25.2 ms ≈ 39 polls per second.

Result: a single-register poll takes about 25 ms of wire at 9600 baud, and a 500 ms refresh uses about 5% of the bus. Decision: one register at 500 ms leaves room for dozens more, so keep total polling under roughly 10 polls per second at 9600 baud, which holds the wire under a quarter busy, and move the line to 19200 baud, which halves every time above, when the map outgrows that.

How to check it worked

• The numeric display follows the PLC's online value within one refresh, 500 ms in this setup.
• Pull the RS-485 connector at the HMI: the display drops the number and shows a communications fault within its timeout, and reconnecting clears it. That shows the value arrives over the wire and is fresh, not held over from an earlier read.
• Read a second register from another part of the map before sign-off, so the first address was not a lucky one.
• Record the driver, station address, baud, parity, stop bits and register map in the project notes for the next person on this panel.

If the link stays dead, check in this order

Work down the list and change one item at a time, retesting after each change:

1. No reply at all: check the wiring first, because an A and B swap reads as silence on most ports, then the parity and stop-bit format, then the station address. The full pattern, including the address-error replies, is worked through in Modbus RTU master no reply and address errors: fix both.
2. An exception reply: the slave answered, so the wire and the address are good and the request itself is wrong, usually the function or the register offset. Correct the address in the driver field and retest.
3. Connected but wrong numbers: the offset or the data type, checked against the PLC's online value for the same register.
4. Works, then drops out: bus termination and the one-master rule.

Recommendation

Recommendation: commission the link at 9600 baud, the PLC manual's parity and stop bits, station address 1 unless the manual prints otherwise, one holding register on a 500 ms refresh, and grow the map only after the display tracks the PLC's online value. If the HMI vendor later ships a native driver for your PLC model, switch to it and point its tags at the same addresses you verified; the map you built over Modbus stays the reference for the whole project.

The HMI stays the live-data screen

A signage display is a different product for a different job. Our shop-floor signage plays a scheduled playlist from local storage, powered at 12 to 36 V DC and rated from -10 to 60 °C with an IP65 front face, which fits a notice board for schedules, safety messages and shift targets beside the machine. It has no Modbus driver and reads no PLC registers, so the HMI keeps the map above and stays the live-data screen.

Questions