Why the HMI panel must be the serial master to the PLC

Why must the HMI panel be the serial master?

A Modbus RTU bus allows exactly one master, the device that starts every transaction, and the panel that has to show process data has to start them, because a slave can only reply when it is polled and a read can never begin anywhere else. That one-master shape comes from the Modbus serial specification itself: a single master triggers the whole communication, and a responder speaks only when a request carries its station address. RS-485 gives the bus a shared pair of wires, and when two devices drive the pair at the same moment their bits overwrite each other, so both frames are lost. RTU has no arbitration and no retry rule for that situation, which is why the design puts exactly one initiator on the wire.

"Let the PLC send its values to the panel" is therefore not a program change you can make: the direction of initiation is fixed in the protocol, and a PLC port running responder logic has no transaction of its own to open. Most PLC serial protocols keep this same shape, whatever the brand of either box, so the role check comes before any tag work.

What do you need before you set the roles?

You need the PLC driver that matches the PLC, the cable drawing for the two ports you will actually use, both devices' current station addresses, and the serial settings both ends will share, the Modbus RTU default being 19,200 baud, 8 data bits, even parity and 1 stop bit.

• The matching driver. The panel project carries a driver that must match the PLC family and the port in use; when a connection will not come up, the driver list is the first place to look, and checking the panel driver list before tuning serial settings shows how.
• The cable drawing for the two ports actually fitted. Take it from each device's own manual; RS-485 and RS-232 wiring drawings differ from port to port, and a drawing borrowed from another interface wires the bus wrong.
• Both station addresses. Many devices reach the job set to address 1 or 2, fixed by DIP switch or by a parameter, and the panel's driver needs the number the PLC actually holds.
• The shared serial settings. The Modbus RTU default of 19,200 baud, 8E1 is a safe starting pair, and when parity is off the specification asks for 2 stop bits; both ends must match exactly.
• A plan for a second panel, if one is coming later: the bus still allows one initiator, and why two HMI panels fail on one PLC serial port explains what the second panel must do differently.

Does station address 1 make a device the master?

No: role and address are separate settings, so the note that reads "master is address 1, panel is 2" tells you who owns which number and nothing about who initiates, and either device could hold address 1 within the Modbus RTU range of 1 to 247. The role lives in the communication settings: a master selection in the panel project's driver, a mode selection in the PLC serial port parameters. The station address lives in the device itself, on a DIP switch or in a parameter list, which is why the two numbers in a job note are so easy to misread.

Copying the numbers without checking who owns which is the usual mistake. If the PLC holds address 1 and the panel's driver targets address 2, nothing answers, and the fix is to make the target match the PLC's actual address. If two responders end up on one station number, both answer a single poll and the frames collide. And a responder set outside the 1 to 247 range is simply not addressable on an RTU bus.

How do you set master and responder on the two devices?

You set the role where each device's own communication settings live: the panel's project driver gets the master selection, the PLC's serial port parameters get the responder selection, and the exact field names differ by software, so your two manuals print them.

1. Read the current state first: open the panel project's driver settings and note the role selection and the target station address; open the PLC's serial port parameters and note its mode and station address.
2. Set the panel's connection to master and enter the PLC's station address as the target in the same settings.
3. Set the PLC's serial port to responder mode (slave in most manuals) at the address the panel now targets; if the two devices hold the same number, change one device and update the target to match.
4. Match the serial settings at both ends: 19,200 baud, 8 data bits, even parity, 1 stop bit is the RTU default, and any shared speed the two ports both support works, with 2 stop bits whenever parity is off.
5. Build the cable from the two manuals' drawings for the ports actually fitted: an RS-485 bus uses the A and B lines plus a common, and an RS-232 cable follows its own wiring table.
6. Download the panel project, power the bus down and up once, and run the single-register test in the next section before building the rest of the screens.

Worked example: how long does one poll of 10 registers take at 9600 baud?

About 46 ms of line time: an 8-byte request plus a 25-byte response at 11 bits per character comes to 363 bits, which is 37.8 ms at 9600 baud, and the two 3.5-character silent intervals between frames add another 8 ms. Scenario: one panel at 9600 baud, 8E1, polls station 2 once a second for 10 holding registers with function code 03.

The arithmetic: a character at 8E1 is 11 bits, so one character at 9600 baud takes 11 / 9600 = 1.15 ms, and the 3.5-character silence the specification requires between frames is 4.0 ms. The request is 8 bytes: station address, function code, start address, register count and CRC. The response is 25 bytes: three header bytes, 20 data bytes and the CRC.

What the number buys you: a 1-second refresh loads the bus for 46 of every 1,000 ms, about 4.6%. The same master reading 50 registers once a second moves 113 bytes per poll, 1243 bits, about 138 ms with the silences, 14% of the bus. Polling 10 registers every 200 ms instead of every second raises the load to 23%. The responder's own turnaround time, which its manual states, adds on top of every poll. Three things move the number: the bit rate scales everything, each extra register adds 2 bytes or 22 bits to the response, and the refresh interval divides the load.

How do you check that the roles and addresses are right?

Bind one display object to one known holding register, change that register's value from the PLC programming software, and expect the new value on the panel within one poll cycle, about a second in the example above.

• The value changes on the panel within a poll cycle: roles, addresses, settings and cable are all right. Add the remaining objects one register at a time and re-check each.
• The object is empty and the panel shows a no-reply or timeout status: the panel is polling and nothing answers in a way it accepts. Work through port settings, then target address, then cable, in that order; fixing a Modbus RTU master's no-reply and address errors walks both faults.
• The diagnostics look healthy but the object shows nothing: the read is reaching the PLC and landing on the wrong data reference; checking the tag address first when a numeric display shows nothing sorts that out.
• The PLC was powered down and back: the panel's master should resume polling on its own once the port is up; make a Modbus master reconnect after a slave outage covers that recovery.

Finish with a power cycle of both devices: the same value should come back on its own, with nothing re-downloaded and no PLC logic changed. A setup that needs a re-download to reconnect is telling you which setting was wrong.

Can the PLC ever be the master and the panel the slave?

Only when the panel's own documentation offers a slave mode for the exact driver you are using, because that mode has to exist in the panel's software; if its manual lists only master operation for that PLC family, no PLC program change will reverse the roles.

The one-master rule is a property of the bus, so the master can be a different device: a supervisory computer or a gateway that collects PLC data initiates and the PLC responds, exactly as the panel would. What no bus allows is a second initiator on the same RTU line. Peer-to-peer PLC links use protocols designed for that job, not RTU. Slave-mode panels do exist for some drivers: the panel holds a register map and answers polls, so the PLC or gateway writes values into it, and that mode is a documented feature or it does not exist. When the PLC's serial ports are already committed, the panel question is a port question first; add another operator interface when the PLC ports are full covers the ways to free one up.

Recommendation: for any panel whose job is showing live PLC values over a serial line, set the panel's driver to master, target the PLC's actual station address, and leave the PLC port in responder mode; look for a panel slave mode only when an application truly needs the PLC to push values, and only where the panel's driver manual names that mode explicitly.

What if the screen only needs a notice board, not live PLC data?

Then skip the serial bus entirely: an offline signage display plays files loaded on it, asks the PLC for nothing, and fits a notice board, shift schedule or safety message where no register values are needed. The master and responder settings never enter the job, because the board holds its own content and shows it on its own. We build shop-floor screens for exactly that role, and the two jobs sit side by side on the floor: the notice board carries the loaded content, the operator panel carries the live values.

Questions