10 — REAL-WORLD: POLLING & PERFORMANCE
From "I understand Modbus" to "I can deploy Modbus."
Estimated 10 minutes.
Modbus is polled. Always.
A Modbus slave never pushes data. The master asks repeatedly — that is how you get fresh values. If a master stops asking, the slave never speaks. There is no subscription, no publish/subscribe, no event push.
Typical poll cycles.
Different parts of the system live at different cadences: 100 ms or faster for tight control loops, ~1 s for HMI screens, 10 s or slower for plant telemetry. Pick the slowest rate that still meets the requirement.
Three poll rates on one timeline.
100 ms fast loop · 1 s HMI · 10 s telemetry — all on the same plant network.
Bandwidth grows linearly.
Network load = polls/sec × bytes/poll. Double either lever and you double the load on the slave's CPU and the wire. Most plants strain because a careless master polls everything at 100 ms when 1 s would do.
Polling tuner.
A poll-rate slider drives a request rate, a bandwidth meter, a slave CPU bar, and a latency value. Past the slave's capacity, the response zone turns red.
Batch reads, every time.
Reading 100 contiguous registers in a single FC3 takes 1 round trip. Reading the same 100 with 100 separate FC3 requests takes 100 round trips and produces 100× the framing overhead. Batch — even if you ignore some of the values.
100 values, scattered.
You need 100 register values, spread across addresses 0 to 199 (gaps allowed). Best approach?
- 100 separate FC3 requests, one per address
- One FC3 request for all 200 registers, ignore the gaps
- Switch to FC16 to bulk-write a marker first
Most PLCs cap concurrent connections.
A Modbus TCP slave usually accepts only ~5–10 concurrent connections. Open one persistent connection per master and reuse it; do not open a fresh socket per request. Connection churn = wasted SYN/ACK roundtrips and exhausted slaves.
Do not out-run the slave.
If the master polls faster than the slave can answer, requests queue and latency drifts up until something times out. Always benchmark with realistic data sizes before committing to a poll rate.
Exceptions are signals, not noise.
If your steady-state polling produces exceptions, something is wrong with your config — wrong address range, wrong function code on a slave that does not implement it. Treat each new exception as an alert, not a routine event.
Wireshark is the troubleshooting tool.
Modbus has a great Wireshark dissector. Capture on the master's interface, filter on tcp.port == 502, and you can see every request and response decoded down to the field. Almost every "weird Modbus issue" gets diagnosed in 5 minutes with a capture.
A real Modbus capture.
TID + function + addr + qty are visible without any decoding work on your part.
The master times out, the PLC pings.
Your master is timing out on every Modbus request. The PLC pings fine on the same IP. Most likely cause?
- A Modbus PDU error in your request
- Modbus server is stopped or port 502 is firewalled
- The cable is unplugged
You can deploy Modbus on a real plant.
- Modbus is polled — no push, no subscription.
- Batch reads beat many small reads, every time.
- Watch connection limits and the slave's actual capacity.
- Exceptions in steady state are bugs, not noise.
- Wireshark + tcp.port == 502 = answers in 5 minutes.
Modbus TCP complete.
- You can hold a deployment-grade conversation about Modbus.
- You can pick poll rates and batch sizes that work in production.
- You can troubleshoot a Modbus link from the wire up.