Gateways & Mixed Networks
▮ Overview
What you'll learn
TCP↔RTU routing, unit IDs, latency, and how to keep mixed deployments diagnosable.
Sections
11
Labs
1
Quiz
9 Qs
What you'll be able to do
- Route a TCP request to a serial server using the Unit ID.
- Predict gateway-induced latency and exception behavior.
- Diagnose 'works in dev, fails through the gateway' problems.
Why you'll need this
- "Your SCADA polls Unit ID 5 over TCP; the gateway holds three RTU buses. How do you confirm the routing is right?"
Three things people get wrong
- 1.Assuming the gateway forwards exceptions verbatimFix Some gateways synthesize their own exceptions on timeout. The exception code may not match the device's behavior.
- 2.Polling faster than the slowest serial busFix The serial side has a max throughput. Over-polling causes queueing and gateway-side timeouts.
- 3.Reusing Unit ID 1 for two devicesFix Each device behind the gateway needs a unique Unit ID — this is the gateway's only addressing handle.
From the field
The gateway with a 50 ms quiet window
A perfectly working integration started timing out after a firmware bump. The new gateway enforced a 50 ms gap between RTU polls; the SCADA was issuing back-to-back reads. Spacing the polls fixed it; the lesson was to always profile the actual round-trip after a gateway change.
Cited sources
Primary sources come from protocol and standards publishers. Secondary sources provide supporting tool, vendor, or reference context.
- Primary sourceModbus gateway design patterns (Modbus.org wiki) ↗
This module is paginated — step through the sections, run the labs, then take the quiz. Progress is saved locally.
Print one-pager →