A cable only moves voltages; the protocol lives in each device's firmware. Put the panel's protocol list beside the PLC port's list, match the serial format and slave address in both projects, then order the cable. If the panel's list lacks the PLC's protocol, no wiring helps; choose a panel or PC client that supports it.
A cable can join two devices that will never exchange one useful byte, and that is the trap this checklist closes. Before you order a cable or draw its wiring, put the panel's documented protocol list beside the PLC port's list and read them together. The check takes about 10 minutes at a desk and it decides the whole job. If both documents name the same protocol, usually Modbus RTU, you match the serial format and the slave address in the two projects, then buy or build the cable. If they do not, no adapter or longer cable adds a protocol to a panel. The protocol is firmware inside it, and the cable only moves voltages between connectors.
Put the two protocol lists side by side
You need two documents: the protocol page of the panel's manual, or its configuration software's driver list, and the communications chapter of the PLC manual, read for the exact port you plan to use. A compact PLC can serve different protocols on different ports, so the chapter matters per port.
The three outcomes:
- Same protocol, same port type. Proceed. Match the serial settings and the slave address, then wire from the two wiring pages.
- Same protocol, different port type. One end RS-232 and the other RS-485 means a documented converter between the two electrical standards; the shared protocol alone is not enough.
- No shared protocol. Stop. Choose a panel or a PC client that lists a protocol the PLC port speaks.
Recommendation: Order a cable only after both lists name the same protocol and the ports can be wired together directly or through a converter both manuals document. If the panel's list has no entry the PLC port can serve, replace the panel or move the screen to a PC client, and skip the wiring trials entirely.
When the old panel is being replaced outright, the same check runs from the other side: check the PLC serial protocol before replacing a legacy HMI walks through the swap.
What to record from the panel manual
- Protocol names, exactly as printed. Modbus RTU and Modbus ASCII are two protocols; RTU frames carry 8-bit binary data, ASCII frames carry it as text, and a port set to one mode will not answer the other.
- Master or slave role. A panel that displays PLC values is normally the Modbus RTU master and the PLC answers as the slave. The manual states which role each protocol entry gives you.
- Port type and connector. RS-232 and RS-485 are different electrical standards, and the connector shape tells you nothing about which one the port uses. RS-232 is quoted to about 15 m of cable at full rate, the figure the TIA/EIA-232 standard is usually given with; RS-485 twisted pair runs to about 1200 m at 9600 bps.
- Address range. Modbus serial slave addresses run from 1 to 247; the manual states what the panel can target.
What to record from the PLC manual
The communications chapter lists, port by port, which protocols each port serves and that port's default serial format. The Modbus serial specification makes RTU the required default mode and 9600 bps the required default rate, and it requires 19200 bps as a second rate that every compliant device implements.
Then read the values configured in the PLC project, because a previous job may have moved them away from the shipping defaults. Write down the port's protocol, its rate, its format and its slave address exactly as the project holds them.
The serial settings both ends must match
Both projects must carry the same format before the first power-up:
- Baud rate. The same number at both ends. The specification's default is the rate to fall back to when a link will not come up.
- Data bits. 8 for RTU.
- Parity and stop bits. Even parity with 1 stop bit is the specification's default; a port set to no parity must send 2 stop bits.
- Mode. RTU at both ends, never one RTU and one ASCII.
- Slave address. The address in the PLC project must equal the address the panel's driver targets, especially on a link that carries other devices.
| Setting | What a mismatch does | Where to fix it |
|---|---|---|
| Baud rate | No replies at all | Serial page in both projects |
| Parity or stop bits | No replies, or errors that come and go | Same page at both ends; parity mismatches have a symptom pattern of their own |
| RTU vs ASCII | Garbled frames, CRC errors | Protocol selection in each project |
| Slave address | No reply, or the wrong device answers | Address field in the panel driver and the PLC project |
Worked example: a Modbus RTU panel on a PLC port at 9600 bps
Inputs. From the panel manual's protocol page: Modbus RTU master, RS-485 port, target addresses 1 to 247. From the PLC manual's communications chapter, built-in serial port: Modbus RTU slave, default 9600 bps, 8 data bits, even parity, 1 stop bit, slave address 1. From the Modbus serial specification's framing rules: one RTU character is 11 bits on the wire (1 start, 8 data, 1 parity, 1 stop), and a frame ends with at least 3.5 character times of silence.
Rule. The pair is compatible when both lists name the same protocol, the port types can be wired together, and both projects can carry the same serial format. The drivers then manage the frame timing themselves at any rate both ends implement.
Arithmetic.
- Character time at 9600 bps: 11 bits / 9600 bps = 1.146 ms per character.
- Frame gap: 3.5 x 1.146 ms = 4.01 ms of silence at the end of every frame, which is what tells the receiver the frame is over.
- Both required rates are inside the pair's range: 9600 bps as the PLC port's default and 19200 bps as the specification's second required rate.
Result. Protocol, port type and format all agree: 9600 bps, 8 data bits, even parity, 1 stop bit, RTU, address 1.
Decision. This pair passes, and the pass mark is the same protocol name on both lists. Order the cable for these two exact ports and copy the wiring from the two manuals, one page from each; a matching connector shape is not a wiring plan. A panel whose list lacks Modbus RTU fails at this same gate at any baud rate you set, and no cable changes that.
When no cable can fix it
If the panel's protocol list has no entry the PLC port serves, the job is a hardware choice, not a wiring job. The options, in the order they usually cost:
- A different panel. Choose one whose manual lists the protocol the PLC port speaks, and repeat the desk check with its manual before ordering.
- A PC client. HMI software that lists Modbus RTU will read a PLC port set as RTU slave, over the PC's serial port or a USB adapter; connect a PC HMI to a PLC over a serial protocol or Ethernet covers the setup.
- A documented converter. A protocol-conversion device that lists both protocols in its own manual can translate. It carries its own configuration and its own failure point, so its settings belong on your drawing.
Leave the PLC's communications alone while the process runs; change serial settings in a scheduled window, with the project backed up first.
One boundary worth drawing: if the screen's job is shift targets, safety notices or work orders that do not come from PLC registers, a shop-floor signage display serves that without touching the serial link; live register values still need a device that speaks the PLC's protocol.
Power-up checks with one test value
Once the lists match and the format is set, keep the first test small:
- Back up both projects and record every setting you found.
- Wire from the two wiring pages, and keep the run inside the length both manuals state for the port.
- Set both ends to the same format and the same slave address.
- Configure one field on the panel that reads a PLC value you can change from the PLC side, such as a counter or a setpoint.
- Change that value at the PLC and watch the field update.
- Power the panel down and up and confirm it reconnects on its own.
If nothing replies, work protocol, then wiring, then settings, in that order. The no-reply case and address errors have a documented pattern, and Modbus RTU master no reply and address errors works through both from the panel side. If the link comes up but the field shows the wrong number, the format and address are right and the error is in the data map: register area, register address or data type. A link that comes up doesn't prove the panel is reading the register you meant, so check that one field against the PLC's own display before you build the rest of the screen.
What to have ready before you order
Send these with the order, whether the cable is bought or built:
- The panel model and the protocol page of its manual.
- The PLC model, the exact port, and that port's page in the communications chapter.
- Port type at each end, RS-232 or RS-485, and the planned cable run length in m.
- The RTU master assignment and the PLC's slave address.
- The register addresses and data types the screen will read, taken from the PLC project.
A page of facts like that turns the compatibility question into a yes or no on paper, and the first power-up becomes the formality it should be.
Questions
Can a protocol converter connect a panel that lacks Modbus RTU?
Only a documented converter whose own manual lists both protocols. Translation is code running between its two ports, so the converter needs power, configuration and a settings record on your drawing, and it becomes one more device that can fail. A homemade adapter or a rewired cable cannot do the job, because there is nothing in a length of wire to translate.
The link is up but a value on the screen is wrong. What now?
The serial format and the address are right, so look at the data map. Check three things against the PLC project: the register address, the register area such as holding register or coil, and the data type. Reading a 32-bit value as two separate 16-bit registers, or a signed value as unsigned, links cleanly and still displays the wrong number.
Does adding a new panel require changing the PLC program?
Usually not. A Modbus RTU master only reads and writes registers the running program already holds, so the program stays as it is and the panel maps its fields to those addresses. Add one thing to the project file: a note of which registers the screen reads and writes, so the next compatibility check takes minutes, not hours.
What cable do you buy for Modbus RTU over RS-485?
Build to the wiring pages of the two exact manuals; there is no single Modbus cable that covers every pair of devices. Use twisted pair for the data lines, bond any shield or drain wire to ground at one end only, and keep the run inside the length both manuals state, commonly about 1200 m at 9600 bps.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.