Why Your Modbus Gateway Pings Fine but SCADA Still Goes Stale

The gateway pings fine and half the plant is stale

Ping answers, the gateway web page loads, a few registers still tick over — and yet three drives on the same trunk have been showing last-good values for two minutes. That combination fools people into replacing PLCs and re-terminating RS-485 shields that were never the problem.

The reason is structural. On the TCP side, Modbus multiplexes: every request in the MBAP header carries a 2-byte transaction identifier (0–65535), so a client can have many requests in flight at once (Modbus Application Protocol Spec V1.1b3, §4.1). On the RS-485 side there is no such thing. Modbus over Serial Line is strictly one transaction at a time — request, wait, response, then a 3.5-character silent interval before the next frame (Modbus over Serial Line V1.02, §2.5.1.1). The gateway's whole job is to funnel that fan-in of TCP requests down a single-file serial pipe. When the pipe can't keep up, the requests don't vanish. They queue, retry, age out, and come back as stale data.

So the number that actually matters at commissioning isn't ping latency. It's this: while the slowest downstream device is sitting in a serial timeout, how many other requests is the gateway holding, and are any of them yours?

Map the real request path

Before tuning timeouts, write down the path for each critical tag group.

Item	Example
SCADA client	Primary HMI server and standby HMI server
Protocol leg	Modbus TCP to gateway, then Modbus RTU to drives
Unit ID range	Unit IDs 1 to 24 on one RS-485 trunk
Serial settings	19200 baud, 8E1, 100 ms turnaround target
Poll class	Fast status every 1 s, diagnostics every 30 s
Write path	Operator start/stop commands through same gateway

This table exposes a common mistake: reads, diagnostics, standby server polling, and writes all share the same serial bottleneck. Adding a second SCADA client may double the TCP request rate even though the field bus has not changed.

Symptoms of queue saturation

Queue saturation does not always produce clean timeout alarms. Watch for these patterns:

• Values update in bursts instead of at the configured scan rate.
• One device timing out causes unrelated devices behind the same gateway to go stale.
• Writes appear accepted by the HMI but take several seconds to reach the device.
• Gateway diagnostics show increasing pending requests, dropped requests, or serial retries.
• Fast tags look acceptable until a standby server, historian, or engineering laptop connects.
• The problem is worse after a power cycle because all clients reconnect and browse at once.

If the gateway has per-port diagnostics, trend them during the test. A queue depth graph is often more useful than a single timeout counter.

Tune the client before blaming the wire

Bad wiring exists, but first remove avoidable traffic.

Practical SCADA driver checks:

1. Confirm whether the driver allows more than one outstanding request per gateway or per Unit ID.
2. Disable duplicate polling from standby servers if the platform supports hot-standby data sharing.
3. Put slow diagnostics, nameplate values, and energy totals in slower scan classes.
4. Group contiguous registers so the driver does not issue many small reads.
5. Keep command writes in a path that is not starved by long diagnostic reads.
6. Set timeout and retry values based on the serial segment, not only the TCP network.

Do the arithmetic on the serial timeout before you trust the defaults. At 19200 baud, 8E1, one character is 11 bits, so ~573 µs on the wire; a short holding-register read and its response are only a few milliseconds of actual traffic. But a dead slave doesn't answer at all — the gateway waits out the full serial timeout, then retries. Leave that at a vendor default of 1000 ms with three retries and a single unplugged Unit ID parks the trunk for three seconds per poll cycle, and every other device behind it goes stale in lockstep. I set serial timeouts to roughly 4–5× the measured healthy response time (often 200–300 ms, not 1000), with one retry, precisely so one weak device can't hold the whole bus hostage. Save the long, patient timeout for the one flaky meter that genuinely needs it — not the default applied to all 24 Unit IDs.

Separate fast control status from maintenance data

A drive gateway may expose run status, speed feedback, fault code, temperature, serial number, firmware version, and detailed diagnostics. They do not need the same poll rate.

A practical split:

Data type	Suggested handling
Run, fault, ready, speed feedback	Fast enough for operator display and alarm logic.
Fault detail words	Moderate rate or on-demand when faulted.
Energy totals and hours	Slow poll or historian calculation.
Serial number, firmware, parameter list	Manual refresh or maintenance screen only.

This split keeps the operator screen responsive when a technician opens a detailed faceplate.

Field test for a gateway change

When replacing or adding a gateway, do more than prove that one register reads.

• Connect the primary SCADA server, standby server, historian collector, and engineering tool if they are part of normal operation.
• Poll the largest normal screen and the most detailed maintenance screen.
• Power off or disconnect one downstream Modbus slave and watch whether other Unit IDs stay current.
• Issue a permitted test write and measure time from HMI command to device acknowledgement.
• Record gateway queue depth, serial retry count, exception count, and TCP client count.
• Restore the failed slave and confirm the queue drains without restarting the gateway.

Do the test during commissioning, not during the first production upset.

Common failure modes

Every device goes stale when one instrument is unplugged. The gateway serial timeout and retry count are too high, or the driver is issuing requests in a way that blocks the whole trunk behind one failed Unit ID.

The HMI is fine until the historian starts. The historian collector is polling the same registers separately instead of sharing the SCADA cache or using a slower scan class.

Writes are delayed during alarm floods. The same gateway queue is full of read retries. Reserve command priority if the product supports it, or reduce read pressure on that path.

Only the standby server sees bad quality. Both servers may be polling independently with different timeout settings. Compare client count and request rate at the gateway.

The issue appears after a gateway firmware upgrade. Default queue depth, TCP connection limit, or serial turnaround timing may have changed. Keep the previous configuration export with the project records.

What to document

Leave enough information for the next outage call:

• gateway model, firmware, IP address, and serial port settings;
• Unit ID list and device order on each trunk;
• SCADA clients allowed to poll the gateway;
• scan class assignment for fast, normal, and slow data;
• timeout, retry, and maximum outstanding request settings;
• expected queue depth under normal operation;
• recovery behavior when one downstream device is missing.

One more line worth writing down: the maximum number of concurrent TCP connections the gateway accepts. Many low-cost units cap it at 4 or 8, and a silent connection refused on the ninth client is exactly what you'll hit the day someone adds a second historian or an OT monitoring appliance. That limit belongs in the drawing, not in the vendor PDF nobody reopens.