Hi folks.
Twelve wellpad RTUs polled by Modbus TCP over LTE modems, one modem per site on a private APN. Single master in the SCADA server, 5 s poll cycle, 2 s timeout per site.
Half the sites time out every cycle, and it's a different half each time. Ping from the server to any modem is 300 to 900 ms, sometimes 1.5 s. The RTUs themselves are fine, a laptop on the pad reads them instantly.
Somebody told me the far pads were marginal on signal, so we swapped the antennas at the two worst for directional ones and RSSI came up ten dB, but the timeouts didn't change at all. Carrier says their network is fine and so are the modems. Is this the modems, the carrier, or my polling? Is a 2 s timeout just never going to work on a link that pings at 900 ms, or am I at the wrong end of this?
How many registers per site, one block or several? And are the twelve polled one after the other, or all at once?
About 60 registers per site, in three blocks because the maps aren't contiguous. One after the other, the driver just works through them as a list. So that's 36 requests per cycle, back to back.
36 requests at 300 to 900 ms round trip is 11 to 32 s of waiting, into a 5 s cycle. Nothing to do with antennas. Every cycle the queue is already behind, the 2 s timeout fires on whichever site is at the back, and the next cycle starts late, which is why it's a different half each time.
Three changes. Poll each site on its own connection, most drivers call it a channel or a device thread. Timeout to 5 s so a slow LTE round trip doesn't count as dead. Cycle to 30 s for the analogs, wellpad pressures don't move in 5 s. There's a writeup with the numbers here: https://plctr.com/the-impact-of-plc-in-the-oil-and-gas-industry-upstream-and-downstream-applications/
One channel per site, timeout 5 s, cycle 30 s. Ten of twelve are clean now. The other two still time out about one poll in five, and they're the two that got the new antennas, which might be a coincidence.
It'll be the three blocks. Some RTUs are slow to answer a second request straight after the first. Merge them, read the whole span in one go and ignore the gaps, three requests become one.
Merged into one block of 110 registers per site and the RTUs don't mind the gaps at all. All twelve clean for two days.
It was a poll budget built for a wired network the whole time, 36 serial requests at LTE latency into a 5 s cycle. Parallel polling per site, 5 s timeout, 30 s cycle and one block per RTU sorted it. The antennas were never the problem.
Still not sure why those two were slower to answer a second request than the other ten, same RTU model and firmware. Cheers scott_m, marcob.
Two slow ones out of twelve is odd, check the modem firmware on those.