Runtime errors that survive a baud-rate match are usually a serial framing problem, most often parity. Read the PLC port's actual baud, parity and stop bits in the controller setup, enter the same values in the HMI driver, and prove the link with one pushbutton and one output coil before building screens.
An HMI that transfers its project cleanly and then throws communication errors the moment one control touches a PLC address is almost always showing a serial framing problem, and parity is the setting that bites most often. Both ends can sit at 19200 baud and the link still fails when one port sends a parity bit and the other expects none. Stop guessing at settings: open the PLC programming software, read the serial port's actual baud rate, parity and stop bits, and enter those values in the panel's driver settings. On a 19200 baud link that behaved exactly this way, the PLC port had been left at parity None. Setting the PLC to Odd and matching the panel cleared every error on the first try.
What parity does to a serial character
On an RS-232 link, every character travels as a small frame that the UART assembles bit by bit. At the usual panel setting of 8 data bits, odd parity and 1 stop bit, one character is 1 start bit + 8 data bits + 1 parity bit + 1 stop bit = 11 bits on the wire. The sender counts the 1s in the data byte and sets the parity bit so the total comes out odd. The receiver runs the same count and discards the character when it disagrees; the page on odd parity configuration for Modbus RTU frames shows the check as the UART hardware performs it.
A port set to parity None sends no parity bit at all. Its frame is 1 start + 8 data + 1 stop = 10 bits, a different frame instead of an 11-bit frame carrying a wrong value. That is why the settings travel as a set: the baud rate says where the bits sit in time, and parity decides how many bits there are, so baud rate, data bits, parity and stop bits have to be compared together.
Symptoms and what each one points to
| What you see | What it points to |
|---|---|
| Project transfers to the panel with no error; the first screen with a PLC address raises communication errors | The transfer never polled an address. A blank screen asks the PLC for nothing, so the runtime link gets its first real test only when a control reads or writes one. |
| You changed the baud rate at both ends several times and the errors never changed | Framing, most often parity. A None-versus-Odd mismatch fails identically at 19200 and at 9600 baud, so no speed will fix it. |
| Timeout or checksum errors on most polls, with replies that look partly right | A framing mismatch drops some characters and lets others through. Timeout and checksum errors are its usual signature; the article on HMI PLC timeout and checksum errors covers the rest of that pattern. |
| Both setting screens look identical and there is still no reply | The cable may enter the wrong physical port. Controllers with two serial ports keep separate settings per port, so confirm which one the cable lands on. |
| A homemade cable or a borrowed adapter in the path | Use the premade cable the panel maker sells for the protocol; the link in the case below ran on a 15-pin premade cable. Pin faults read like framing faults. |
Read the PLC port before touching the panel
- Confirm the physical path. Find which serial port on the PLC the cable enters and check both connectors are seated. If the PLC has two ports, each carries its own settings, and the panel may belong on the second one; the article on using the second PLC serial port for an HMI covers that layout.
- Select the driver that speaks the PLC's protocol. The panel project needs the driver matching the PLC's native serial protocol, SNP-X in this case. The protocol also fixes the roles: the panel is the master and the PLC is the slave, and neither role is adjustable. If you are unsure which protocol the port speaks, check the PLC serial protocol before replacing the panel.
- Read the PLC port's actual settings. In the PLC programming software, open the setup for the connected port and write down the baud rate, parity, data bits and stop bits as configured. SNP-X defaults to 19200 baud, odd parity and 1 stop bit on the PLC side, and those values are a starting guess only: the port holds whatever it was last left at.
- Enter the same values in the panel driver. Open the driver's serial port settings in the project (port DEV001 in this case) and set the baud rate, parity and stop bits to the values from step 3. The method is the same as matching serial settings when an HMI and PLC will not talk; the difference is where the values come from: the PLC's setup screen, not a default.
- Transfer, then test one address with the one-address test below before building any more screens.
Example: a 19200 baud link failing on parity None
Scenario: a panel and a PLC are connected by a 15-pin premade cable. Both serial ports run 19200 baud, 8 data bits and 1 stop bit. The panel driver uses odd parity; the PLC port has been left at parity None. The screen has one pushbutton writing to memory bit %M0001, and the PLC has one rung passing %M0001 to output coil %Q0001. Every press raises a communication error.
The frames disagree. The panel sends 1 + 8 + 1 + 1 = 11 bits per character; the PLC expects 1 + 8 + 1 = 10. At 19200 baud, one bit takes 1/19200 s ≈ 52.1 µs, so each 11-bit character occupies 11 × 52.1 µs ≈ 573 µs and the port carries 19200 ÷ 11 ≈ 1745 characters per second in each direction.
The PLC, expecting no parity bit, reads the panel's parity bit where it needs a stop bit. Odd parity sets that bit to 0 for exactly half of the 256 byte values, the 128 values with an odd count of 1s, so about half of the panel's characters fail the framing check and are discarded. A 20-character poll survives intact with probability (1/2)^20 ≈ 1 in a million, so the PLC almost never assembles a request and sends no reply. The reply direction fails the same way: the panel reads the PLC's stop bit as a parity bit and rejects about half of each response.
Fix and result: set the PLC port to odd parity and leave the panel at odd parity, both ends still at 19200 baud with 1 stop bit. Every character now carries a checked parity bit in both directions, the poll arrives, %M0001 toggles and %Q0001 follows, and the communication error is gone. One setting changed.
The one-address test
One pushbutton and one rung are enough to prove the link. Address the pushbutton to a memory bit and write a single rung that passes it to a spare output coil, %M0001 driving %Q0001 in the example above. Keep the machine in a state where energizing that output moves nothing: use a spare point or watch the rung's logic state with the output unwired. Press the button and watch three things: no communication error during the request, the memory bit changing state in the controller, and the coil following the rung. When that passes, add the remaining addresses and record the commissioning settings with the project: PLC port, driver, baud rate, parity, data bits, stop bits. If errors return after a later edit, compare those two setting screens again before touching any logic.
Recommendation
Recommendation: When a panel errors on the first screen that touches a PLC address, read the PLC port's actual baud rate, parity and stop bits from the controller setup, enter those values in the panel driver, and run the one-address test before building more screens. If the PLC port reads parity None and nothing else shares the port, set the PLC to odd parity, the protocol's default, and mirror it in the panel driver. Change one end at a time so you always know which side holds the reference settings.
Questions
Which end should I change when the parity settings disagree?
Change whichever end you control, and record the choice. If other equipment shares the PLC port, change the panel driver and leave the PLC port alone so the other device keeps communicating. If the project is new and nothing else uses the port, set the PLC port to the protocol's documented default and enter the same values in the panel. The two ends only have to agree with each other; neither value is more correct than the other.
Why did the project download finish with no errors if the link was broken?
Because the download never asked the PLC for anything. A screen with no PLC addresses gives the panel nothing to request, so the serial link is never exercised during a transfer. Depending on the panel, the project may not even travel over that serial cable; many panels also accept transfers on USB or Ethernet. The link is demonstrated only when a control that reads or writes a PLC address runs without a communication error.
Does parity matter at lower speeds like 9600 baud?
Yes. The failure is in the frame layout, so a None-versus-Odd mismatch drops the same share of characters at any speed. At 9600 baud, an 11-bit character line carries 9600 ÷ 11 ≈ 872 characters per second, so the link just runs slower while failing the same way. Match parity first, then choose the baud rate for how quickly the screens need to poll.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.