Timeouts on a panel that reaches Modbus controllers through another panel point at the relay path, not the controllers. Dropping the master panel's poll spacing from 30 ms to 5 ms cuts the alarms from three or four a minute to almost none, which shows timing is in the fault. The repair is a Modbus TCP gateway, with the panel polling documented register addresses directly.
A panel that reaches Modbus controllers through another panel logs a communication timeout every 15 to 20 seconds and works normally between alarms. That pattern points at the relay path, not at the controllers, the cable, or the register addresses. One test confirms it: shorten the master panel's poll spacing from 30 ms to 5 ms and the alarms drop from three or four a minute to almost none. The repair is different. Install a Modbus TCP gateway on the controller network, point the remote panel at it with a Modbus TCP driver, and map every object from the register chapter of the controller manual. In the field job that produced this pattern, that change stopped the timeouts.
What the pattern tells you
The job: a 12-inch panel served as Modbus master for two process controllers and ran no polling of its own. A 6-inch panel carried two PID faceplates and four numeric entry boxes aimed at those controllers through the 12-inch unit. The 6-inch panel raised PLC-018, a panel communication timeout, three or four times a minute, and communicated with the controllers whenever the alarm was clear.
Read each observation against the path it actually exercises:
- Works between alarms, fails a few times a minute. The devices, the wiring, and the addresses are good. Something in the relay loses an occasional race.
- An identical screen on the master panel runs clean. The master-to-controller side is good, and that local screen test never exercises the request the master forwards for the remote panel.
- Computers reach the master panel over Ethernet without trouble. The Ethernet segment is good. The loss sits in the panel-to-panel hop, where one panel handles another panel's controller requests.
- No trends, no data logging, and a polling-free screen on the master change the alarm rate by nothing. Background load on the master is off the suspect list.
- The alarm rate moves when the master's poll spacing moves. Timing is inside the fault.
A single panel on a direct link that fails this way is a different job; read why an HMI shows an intermittent PLC communication timeout for that case.
Checks before you change a setting
- Open the fault history first. On this panel line, touch and hold the upper-left corner of the screen to open the service menu, then open the fault history. It records what the panel was attempting when each timeout fired.
- Note which controller and which object each entry names, and whether the value recovers afterward. One controller only points at that device or its address. Both controllers together point at the shared path.
- Count alarms for 10 minutes with a stopwatch and write the number down. Three to four a minute is the baseline for every later comparison.
- Check each object's register against the controller manual before you touch timing, so a timing test never doubles as an address change.
Example: two panels, two controllers, one relay
The master panel at 192.168.9.233 owns the serial side of two controllers. The remote panel at 192.168.9.187 carries the six objects that reach them through the master. Poll spacing on the master is set to 30 ms.
At 30 ms, one forwarded request can leave every 30 ms. That is 1000 / 30 = 33 requests per second, about 2,000 per minute. The alarm log held 4 timeouts in that minute: 4 / 2000 = 0.2 percent of transactions. The path completes 99.8 percent of its requests, which is why the screens look healthy and the fault looks random.
Shorten the spacing to 5 ms and the ceiling becomes 1000 / 5 = 200 requests per second, about 12,000 per minute. The alarms fell to fewer than one a minute, on the order of one fault per 12,000 requests. The cadence figures are ceilings: the six objects on the remote panel set the real demand, and that exact count was never measured. The alarm rate moving with the spacing is the measured fact.
Poll spacing is a test, not the repair
The 30 ms to 5 ms change identified the fault class: a relay problem that responds to timing. It left the relay in place. The plan to try 0 ms was never reported back, so treat 0 ms as untested, and check the controller manual for a minimum silence between commands before going anywhere near it. Many Modbus RTU devices publish such a minimum, and dropping under it trades the relay fault for framing errors at the device.
Failures of exactly this shape also appear when a wait sits at the edge of what a device needs: a response timeout set just above a slow controller's answer time, or command spacing just under the documented minimum, both show up as random polling failures on otherwise healthy links.
The remote panel offered nothing to tune. Its software exposes no poll setting for a connection routed through another panel, so the idea that it polls the bridge at some fixed, unsettable rate stayed a guess. For what the two settings control on a direct link, read what the HMI timeout time and the poll time each do.
Run the test cleanly: record the original spacing, count alarms for 10 minutes at 30 ms, set 5 ms, count again for 10 minutes on the same objects. Revert if the screens lag or the entries turn sluggish, then move to the repair.
The repair: a gateway owns the serial side
Replace the panel in the middle with a Modbus gateway that converts between TCP and RTU. One serial network gets one master, the gateway, and every panel talks to it over Ethernet.
- Install the gateway on the controllers' RS-485 network and wire it to the gateway's own documentation. Modbus TCP servers listen on TCP port 502.
- In the remote panel's project, replace the native controller driver on that connection with the Modbus TCP driver.
- Re-enter every address from the register map chapter of the controller user manual: two PID faceplates and four numeric entry boxes, each checked against its own controller point. The method is in map controller addresses to Modbus for an HMI panel.
- Point the connection at the gateway's IP on port 502 and download the project through your normal change-control path.
- Move any other panel that polled the controllers directly onto the TCP side as well. Two masters on one RS-485 network is the arrangement you are removing.
The full architecture and its polling order are covered in poll Modbus RTU slaves through a Modbus TCP gateway. In the field job, the gateway, the driver change, and the manual addresses stopped the PLC-018 alarms.
Check it after the change
- Test a Modbus TCP gateway before you trust the data on its own first, then bring the panel onto it.
- Verify reads first: every displayed value tracks its controller through the gateway.
- Then verify writes, one object at a time, on a controller you can watch with the process in a state where a wrong value is safe. An entered value must land in the intended register.
- Keep the TCP side polling. Modbus TCP devices commonly close connections left idle for 10 seconds or more, so hold the panel's poll spacing on that side under 5 seconds.
- Soak test for 30 minutes with all six objects live. The old rate of one alarm every 15 to 20 seconds would have logged 90 to 120 timeouts in that window; zero alarms with all values updating is the pass mark.
- If two panels now write the same register, give that register one owner. For the write race itself, read two HMIs writing to one PLC: who wins the write.
Recommendation: Stop routing one panel's controller traffic through another panel. Confirm the diagnosis with the 10-minute count at 30 ms and again at 5 ms, then install a Modbus TCP gateway, switch the remote panel to the Modbus TCP driver on port 502, and map all six objects from the controller manual's register chapter. Keep a direct panel-to-controller link only where that panel is the sole master and the sole panel on the network, and add the gateway the moment a second panel needs the same controllers.
Questions
Can I fix this by setting the poll time to 0 ms?
No result for 0 ms was ever reported from the job that tested 30 ms and 5 ms, so treat 0 ms as untested. The remote panel also exposes no poll setting of its own for a connection routed through another panel. Before going below 5 ms, check the controller manual for a minimum silence between commands; many Modbus RTU devices publish one, and dropping under it causes framing errors on the device side.
Do the controller addresses change when I add the gateway?
Yes. The native controller driver and the Modbus TCP driver use different numbering, so re-enter every object from the register map chapter of the controller user manual, then check each one against its own controller point. Nothing carries over from the old connection.
Will the master panel still work after the gateway goes in?
Yes. Its screens keep their own driver and addresses. Give the serial network one master, the gateway, and move any panel that polled the controllers directly onto the TCP side as well. If two panels then write the same register, assign that register a single owner, because two writers race each other and the last one in wins.
How long should I watch before calling it fixed?
Run a 30-minute soak with every object live. At the old rate of one alarm every 15 to 20 seconds, that window would have logged roughly 90 to 120 timeouts, so zero alarms with all values updating is a real change. Confirm each numeric entry lands in its intended register before you hand the screen back to production.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.