When a Modbus RTU link from an operator panel to a servo drive times out only while the motor runs, the cause is noise, not settings: move the panel connection from RS-232 to RS-485 and ground the cable shield at one end. Raising the timeout from 100 ms to 3000 ms does not repair the link; at 350 cycles per minute it leaves up to 18 cycles of frozen animation on screen.
A serial link between an operator panel and a servo drive that times out only while the motor is turning is a noise problem, and the fix is electrical. The numbers below come from a representative case: a 6-inch operator panel talking Modbus RTU to a servo drive over RS-232, clean with the motor stopped, throwing PLC-001: PLC Communication Timeout as the machine ran 350 cycles per minute. Raising the response timeout from 100 ms to 3000 ms made the symptom worse, because the panel freezes its animation for the whole timeout before it raises the alarm. The change that held was moving the panel connection to RS-485 with the cable shield earthed at one end, on a run under 2 m. This page gives the symptoms to sort, the timing arithmetic, and the rewiring order.
What each symptom points to
- Timeouts only while the motor runs. The fault tracks machine state, so the electrical environment around the drive and motor is the suspect: switching edges coupling into the cable, or the interface running out of noise margin. The wiring and parameters are close to correct, because the same link is clean with the motor off.
- Animation frozen for the whole timeout. The panel holds the last frame until communication has been missing for the entire timeout, then raises PLC-001. A longer timeout means a longer stale picture, not fewer drops.
- A new shielded cable changes nothing. Shield presence was not the limiting factor in this fault. Look at the interface type, the shield termination, and the cable route next.
- The banner appears with the motor stopped too, then constantly, then the panel locks up. That pattern points at the panel hardware itself. Use the maker's support or replacement path before touching anything else.
- You want to hide the banner. There is no setting for it in this class of panel. Keep it visible; it is what tells you whether the link is actually fixed.
Drops that come and go with no relation to machine state have their own causes: why an HMI shows an intermittent PLC communication timeout covers that separate case.
Why the running motor is the clue
RS-232 measures every bit against a signal ground wire. A servo drive and its motor move that reference every time they switch, so the bits arrive corrupted while the machine runs, at exactly the baud rate that was clean while it sat still. RS-485 sends each bit as the difference between two conductors, A and B, and the receiver reads that difference; noise that lifts both conductors together cancels. That is why the fix here is the interface, not the data rate and not the cable length: a 2 m run inside one cabinet can fail on RS-232 and run clean on RS-485 beside the same drive. The distance figures by interface, for the day you do plan a long run, are in RS-232 to RS-422 cable distance for an HMI panel link.
Keep the layers straight while you order parts. Modbus RTU is the protocol. RS-232 and RS-485 are the electrical interfaces underneath it, and a properly wired RS-485 bus resists noise and carries several devices on one twisted pair. DH-485 is a separate, proprietary PLC protocol and is not another name for RS-485; DH-485 operator interface connection to a PLC covers the links that genuinely use it. The change that fixed this fault kept Modbus RTU untouched and swapped the interface from RS-232 to RS-485.
Example: how long the animation freezes at 350 cycles per minute
Inputs: the machine runs 350 cycles per minute, and the panel's configuration software offers timeout settings where 1 equals 100 ms and 30 equals 3000 ms. The panel's manual states that the banner appears only after communication has been missing for the entire timeout, and the screen at the 3000 ms setting showed exactly that: the animation sat frozen for the whole timeout.
Rule in words: one machine cycle lasts 60 s divided by the cycles per minute, and the stale window on screen equals the timeout setting, because the panel shows the last frame until the timer expires.
Arithmetic: 60 s ÷ 350 cycles/min = 0.171 s per cycle, which is 171 ms. At the 100 ms setting, 100 ms ÷ 171 ms = 0.58, so a drop that outlasts the timeout shows up inside the first missed cycle, and drops shorter than 100 ms never raise the banner at all. At the 3000 ms setting, 3000 ms ÷ 171 ms = 17.5, so one drop freezes the picture for roughly 17 to 18 machine cycles before the banner appears.
Decision: the 100 ms setting tracked the machine closely, which is why it looked like the better setting; the 3000 ms setting handed the operator up to 18 cycles of a dead picture per drop. The threshold to hold: keep the timeout well under the time a stale screen would mislead anyone, a few hundred milliseconds at this speed, and spend the effort on the link instead of the timer. The conversion used here, from cycle time to cycles per minute, is the same one PLC programs do in integer math; cycle time to cycles per minute conversion shows that version. The 171 ms period is the yardstick for animation freshness; the panel's Modbus poll interval is a separate setting in its configuration software.
The rewiring, in order
- Record the working setup first: interface selection at both ends, baud rate, parity, stop bits, slave address, timeout value, cable route, and the machine condition that reproduces PLC-001.
- Confirm both devices have an RS-485 port and select it at each end. Do not reuse the RS-232 cable. If a converter sits in the path, RS-485 converter wiring troubleshooting when the link fails lists the wiring faults to rule out.
- Wire A and B as a twisted pair, add the signal common where the manuals call for one, and earth the shield at a single point. Either end of the run is acceptable when both devices are properly grounded.
- Leave the Modbus RTU parameters untouched: same slave address, same registers, same baud. Only the physical interface and its wiring change.
- Test at the failure condition: full sequence, 350 cycles per minute, watching the banner, the values, and the animation. A stopped-motor test will not reproduce this fault. Change one condition at a time, and never disconnect a device in a way that defeats a guard or an interlock.
- While the cabinet is open, give the panel its own low-voltage feed so it is not sharing power wiring with the drive. For a cabinet-mounted screen, a 24 V DC DIN-rail supply is the clean way to do that, and our cabinet power and mounting accessories include one.
- When the banner stays absent through a full production run, set the timeout back to the value that tracks the machine, about 100 ms on a link of this speed, and leave it there.
The check: at full rate the banner stays absent, the values stay current, and the animation advances with every cycle with no visible lag.
What the timeout changes
The timeout decides when the panel declares failure and how long it keeps showing the last frame before it does. It has no effect on the signal, cannot recover a response that was lost, and cannot make stale data current. That is why 100 ms to 3000 ms made this case worse instead of better. The same hold-last-state behavior applies on control links; fix an HMI communication timeout when outputs hold state covers the version where held outputs, not a frozen animation, are the risk. A firmware update noticed during this troubleshooting was never isolated as the fix, so do not credit one on your own link without a controlled test; the change that coincided with clean operation was the interface swap.
The decision
- Timeouts only while the drive runs: move the link to RS-485. On the case behind these numbers, the swap ended the recurring timeouts even though the run was under 2 m.
- Timeouts with the motor stopped too: work through wiring, grounding, and parameters first, then the panel hardware branch from the symptom list.
- The urge to raise the timeout: resist it. It stretches the stale window and hides nothing.
- The urge to hide the banner: not an option in this panel class, and not the goal. The goal is a link clean enough that the banner never fires.
Recommendation: When PLC-001 or its equivalent appears only while the servo motor runs, plan one electrical change: select RS-485 at both ends, wire A and B on a twisted pair with the shield earthed at one point, keep every Modbus RTU parameter as it was, and prove the fix with the motor at full rate. Keep the response timeout near the value that follows the machine, 100 ms on a 350 cycles per minute link like this one, and do not raise it to hide drops, because 3000 ms at that speed means about 18 cycles of frozen animation per drop.
Questions
Can you hide the PLC-001 timeout banner on the panel?
No. This class of panel has no setting that suppresses it. The banner is also the operator's only sign that the animation has stopped updating, so hiding it would leave stale values looking current. Treat the banner as the gauge for the repair: when it stays absent through full-rate production runs, the link is fixed.
Is RS-485 worth the rewiring when the cable run is under 2 m?
Yes, when the timeouts track the drive running. The pair of conductors rejects noise that lifts both at once, where an RS-232 link measures every bit against a single ground wire that the drive keeps shifting. Length is the wrong yardstick here. If the drive has no RS-485 port, a serial converter on a short tail is the fallback, and its wiring becomes the next thing to verify.
Which end of the shield should be grounded?
One end only, at a single point along the run; either end is acceptable when both devices are properly grounded. Grounding both ends lets shield current flow from the difference in ground potential between the two cabinets, which puts noise back on the line. Termination details differ between drives and panels, so wire the shield the way the manual for the hardware in front of you shows.
Does the drive have less time for serial communication while it is moving?
Sometimes, yes: the drive runs the motion profile and services its serial port in the gaps, so a heavy poll load at full rate can add drops of its own. The RS-485 swap tells the two causes apart. If the timeouts end at the same cycle rate, interface noise margin was the problem. If drops persist on a correctly wired RS-485 bus at full rate, slow the poll rate or trim the data requested per poll.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.