Fix an erratic Modbus RTU response delay between HMI and PLC

Why one press is instant and the next takes 6 seconds

A Modbus RTU button write is two short frames. The HMI transmits a request, the PLC processes it inside a scan or two and transmits a response. At 38.4 kbit/s with 8 data bits, odd parity and 1 stop bit, those frames are a few milliseconds each, so a healthy press shows its result faster than the eye can follow. Every press that closes the relay instantly proves the port, the cable, the address and the PLC output are all capable.

The 5 to 6 second presses are made of waiting. A Modbus RTU master starts a response timeout on every transmission. If no frame with a valid CRC comes back in time, it retries, and after the configured retry count it marks the transaction failed and moves on. Silence costs the seconds; the traffic costs milliseconds. So the PLC did not get slow. Some requests are receiving no answer at all, or an answer the HMI counts as a failure.

Three causes produce that, and they cover nearly every RS-232 Modbus RTU link that behaves this way:

• An address outside the PLC's map. An object using the wrong function code, address or data type gets either a Modbus exception or silence, and either result feeds the retry chain.
• Noise on the cable. A corrupted frame fails its CRC check, so the master treats the exchange as unanswered and retries, even though the wire was busy the whole time.
• A ground difference. RS-232 judges each bit by the voltage between the signal wire and signal ground at the receiver. If the two boxes sit at different ground potentials, the levels shift, bits flip or whole frames vanish, and the fault comes and goes with whatever else is running.

An exception reply comes back in milliseconds, so a clean exception looks like a fast error on the screen. A 5 to 6 second pause means either the PLC is staying silent on some requests or the HMI is counting an exception as a failure and retrying through its timeout chain. The pattern test below tells you which one you have. The same three causes appear when the fault also throws checksum errors; that pairing is covered in Fix HMI PLC timeout and invalid checksum errors.

What the delay pattern points to

Read the shape of the fault before changing anything. Each pattern has one decision:

• One button lags, everything else is instant. That object's address, function code or data type sits outside the PLC's map. Decision: correct or delete that object against the PLC's address documentation and leave the cable alone.
• Any screen pauses at random, a few seconds at a time. The physical link is suspect: connector seating, cable damage, noise pickup or grounding. Decision: run the cable and ground checks below.
• The relay closes fast but the HMI lamp catches up late. The write is healthy; the read-back poll is the slow transaction. Decision: check the lamp object's address and the screen's update interval. The same split, for a value that never catches up, is walked in HMI display lags behind PLC values: find where the delay enters.
• The PLC bit changes only after the pause. The request is being lost or timed out on the wire. Decision: fix the exchange, address map first, cable and ground second.
• Delays cluster when a drive, welder or compressor starts. Noise is coupling into the unbalanced RS-232 line. Decision: reroute the cable away from that wiring. The drive-adjacent version of this fault is covered in Fix PLC communication timeout on an HMI servo link.

One test tells the three causes apart

Pick an output that is safe to cycle: a spare coil or a relay with no load connected. A communications test is no excuse to energize a machine 20 times.

1. Open the PLC programming software and put the target bit or register in a watch table.
2. Press the HMI button once and record the order in which three things move: the PLC bit, the relay or output indicator, the lamp on the HMI screen.
3. Repeat about 20 presses and note on each one which of the three came late or stayed put.
4. Read the result. The bit late means the serial exchange is failing, so work the address map and then the cable. The bit fast but the relay late means the delay sits in the PLC logic or the output path, past Modbus. Both fast but the lamp late means the write is healthy and the read-back object is the problem.

If the programming package shows communication status or a request counter, watch it at the moment of a pause. Nothing arriving points at the cable and its grounding. A request arriving with an exception going back points at the address map.

Worked example: where 6 seconds goes

Scenario: a small touch HMI writes one coil to a PLC over RS-232 at 38.4 kbit/s, 8 data bits, odd parity, 1 stop bit. A write-single-coil request is 8 bytes: slave address, function code 05, a 2-byte coil address, a 2-byte value and a 2-byte CRC. Each byte carries 1 start bit, 8 data bits, 1 parity bit and 1 stop bit, so 11 bits per byte. The request is 88 bits and takes 88 / 38,400 bit/s = 2.3 ms. The response is another 8 bytes, another 2.3 ms, plus one PLC scan, so a healthy press completes in under 10 ms. That is the instant case.

Say the HMI's device setup uses a 2 second response timeout with 2 retries, values these settings commonly take. One press whose request receives no answer waits 2 s + 2 s + 2 s = 6 s before the HMI reports the failure and carries on. That is the 5 to 6 second press. The arithmetic shows the wire is not the bottleneck: 4.6 ms of frames sit inside 6,000 ms of waiting.

Decision: a faster panel changes nothing, and a higher baud rate only shrinks the 2.3 ms frames while leaving the 6 seconds where it is. Remove the failed exchanges instead, by fixing the address map and the physical line, and treat the timeout as the last knob.

Checks on the settings, the cable and the ground

Work these in order. The first two cost nothing.

• Line format at both ends. 38,400 bit/s, 8 data bits, odd parity, 1 stop bit, RTU framing selected, slave address matching the HMI's device setup, and only one device transmitting as master. With odd parity every byte carries start, data, parity and stop bits, and both ends must load the identical format. The UART-level detail is in Modbus RTU odd parity: UART hardware configuration.
• The address map. List every button and lamp object the operator can reach, with its function code and address, and compare each against the addresses the PLC actually exposes. Correct the out-of-map and wrongly typed references, and include the screens you were not on when the fault appeared.
• The cable. The RS-232 standard was written around runs up to about 15 m (50 ft), so keep the run well inside that. Reseat both connectors, check for bent pins, and confirm the pin crossing matches what the two manuals require; the wiring basics are in Connect a Modbus RTU HMI to a legacy PLC RS-232 port. Reroute the cable away from motor, drive and welder wiring, and keep it out of the same conduit or tray as drive output cable.
• The ground. RS-232 levels are judged against signal ground, so both boxes need a common, clean reference. Bond the devices per their wiring documentation; improvising a bond on a live cabinet creates new faults.

The fix, and the 20-press verification

• Address fix: point the object at an address in the PLC's map with the correct function code, or delete the object. A deleted object stops generating requests and frees the link.
• Noise fix: reseat or replace the connectors, replace damaged cable, shorten the run, reroute it away from power and drive wiring.
• Ground fix: correct the bond per the documentation. The intermittent shape of this fault usually disappears the moment the reference is right.

Then verify with 20 presses and the watch table open. Every press should set the PLC bit within a scan or two, milliseconds at these speeds. The relay should follow immediately. The HMI lamp should agree within one screen update interval, which you set per screen, usually somewhere between 100 ms and 1 s. Then open the other screens and press each control once. One leftover out-of-map object can keep the whole pattern alive after the button you were testing is fixed.

Recommendation: Keep both ports at 38.4 kbit/s, odd parity, 1 stop bit and diagnose the pattern instead of retuning the link. Run the 20-press test on an unloaded output with the PLC bit in a watch table. If the bit lags, fix the address map first and the cable and ground second. If only the lamp lags, fix the read-back object and its update interval. Change the response timeout last, if ever: it sets the wait charged to each failed press, and a clean 20-press run is what tells you the link is healthy.

Questions