One post tagged with "polling-optimization"

Modbus is 46 years old and still the most commonly deployed industrial protocol on the planet. It runs in power plants, water treatment facilities, HVAC systems, plastics factories, and pharmaceutical clean rooms. Its simplicity is its superpower — and its trap.

Because Modbus is conceptually simple (read some registers, write some registers), engineers tend to implement polling in the most straightforward way possible: loop through tags, read each one, repeat. This works fine for 10 tags on one device. It falls apart spectacularly at 200 tags across eight devices on a congested RS-485 bus.

This guide covers the polling optimization techniques that separate hobbyist implementations from production-grade edge gateways — the kind that power platforms like machineCDN across thousands of connected machines.

The Four Function Codes That Matter​

Before optimizing anything, you need to understand how Modbus maps register addresses to function codes. This mapping is the foundation of every optimization strategy.

The critical insight: You cannot mix function codes in a single Modbus request. A read of holding registers (FC 03) and a read of input registers (FC 04) are always two separate transactions, even if the registers are numerically adjacent when you strip the prefix.

This means your first optimization step is grouping tags by function code. A tag list with 50 holding registers and 10 input registers requires at minimum 2 requests, not 1 — no matter how clever your batching.

Address Decoding in Practice​

Many Modbus implementations use the address prefix convention to encode both the register type and the function code:

• Address 404000 → Function Code 3, register 4000
• Address 304000 → Function Code 4, register 4000
• Address 4000 → Function Code 1, coil 4000
• Address 104000 → Function Code 2, discrete input 4000

The register address sent on the wire is the address modulo the range base. So 404000 becomes register 4000 in the actual Modbus PDU. Getting this decoding wrong is the #1 cause of "I can read the same register in my Modbus scanner tool but not in my gateway" issues.

Contiguous Register Grouping​

The single most impactful optimization in Modbus polling is contiguous register grouping — combining multiple sequential register reads into a single bulk read.

Why It Matters: The Overhead Math​

Every Modbus transaction has fixed overhead:

For RTU at 9600 baud, each individual register read (request + response + delays) takes roughly 50ms. Reading 50 registers individually = 2.5 seconds. Reading them as one bulk request of 50 contiguous registers = ~120ms. That's a 20x improvement.

Grouping Algorithm​

The practical algorithm for contiguous grouping:

1. Sort tags by function code, then by register address within each group
2. Walk the sorted list and identify contiguous runs (where addr[n+1] <= addr[n] + elem_count[n])
3. Enforce a maximum group size — the Modbus spec allows up to 125 registers (250 bytes) per FC 03/04 read, but practical implementations should cap at 50-100 to stay within device buffer limits
4. Handle gaps intelligently — if two tags are separated by 3 unused registers, it's cheaper to read the gap (3 extra registers × 2 bytes = 6 bytes) than to issue a separate request (50ms+ overhead)

Gap Tolerance: The Break-Even Point​

When should you read through a gap versus splitting into two requests?

For Modbus TCP, the overhead of a separate request is ~2-5ms. Each extra register costs ~0.02ms. Break-even: ~100-250 register gap — almost always worth reading through.

For Modbus RTU at 9600 baud, the overhead is ~50ms. Each register costs ~2ms. Break-even: ~25 registers — read through anything smaller, split anything larger.

For Modbus RTU at 19200 baud, overhead drops to ~25ms, each register ~1ms. Break-even: ~25 registers — similar ratio holds.

Practical recommendation: Set your gap tolerance to 20 registers for RTU and 100 registers for TCP. You'll read a few bytes of irrelevant data but dramatically reduce transaction count.

Multi-Register Data Types​

Many industrial values span multiple consecutive registers:

A 32-bit float at register 4002 occupies registers 4002 and 4003. Your grouping algorithm must account for elem_count — reading only register 4002 gives you half a float, which decodes to a nonsensical value.

Byte Ordering Nightmares​

This is where Modbus gets genuinely painful. The Modbus spec defines big-endian register ordering, but says nothing about how multi-register values should be assembled. Different manufacturers use different conventions:

A temperature reading of 42.5°C stored as IEEE 754 float 0x42AA0000:

• AB CD: Register 4002 = 0x422A, Register 4003 = 0x0000 → ✅ 42.5
• CD AB: Register 4002 = 0x0000, Register 4003 = 0x422A → ✅ 42.5 (if you swap)
• BA DC: Register 4002 = 0x2A42, Register 4003 = 0x0000 → ❌ Garbage without byte-swap

The only reliable approach: During commissioning, write a known value (e.g., 100.0 = 0x42C80000) to a test register and verify that your gateway decodes it correctly. Document the byte order per device — it will save you hours later.

Production-grade platforms like machineCDN handle byte ordering at the device configuration level, so each connected machine can have its own byte-order profile without requiring custom parsing logic.

Intelligent Retry Logic​

Network errors happen. Serial bus collisions happen. PLCs get busy and respond late. Your retry strategy determines whether a transient error becomes a data gap or a transparent recovery.

The Naive Approach (Don't Do This)​

for each tag:
    result = read_register(tag)
    if failed:
        retry 3 times immediately

Problems:

• Hammers a struggling device with back-to-back requests
• Blocks all other reads while retrying
• Doesn't distinguish between transient errors (timeout) and permanent errors (wrong address)

A Better Approach: Error-Classified Retry​

Different errors deserve different responses:

Retry Count and Timing​

For batch reads (contiguous groups), a reasonable strategy:

1. First attempt: Read the full register group
2. On failure: Wait 50ms (RTU) or 10ms (TCP), retry the same group
3. Second failure: Wait 100ms, retry once more
4. Third failure: Log the error, mark the group as failed for this cycle, move to next group
5. After a connection-level error (timeout, reset, refused):
   • Close the Modbus context
   • Set device state to "disconnected"
   • On next poll cycle, attempt reconnection
   • If reconnection succeeds, flush any stale data in the serial buffer before resuming reads

Critical detail for RTU: After a timeout or error, always flush the serial buffer before retrying. Stale bytes from a partial response can corrupt the next transaction's framing, causing a cascade of CRC errors.

Inter-Request Delay​

Modbus RTU requires a 3.5 character-time silence between frames. At 9600 baud, this is approximately 4ms. At 19200 baud, it's 2ms.

Many implementations add a fixed 50ms delay between requests as a safety margin. This works but is wasteful — on a 100-tag system, you're spending 5 seconds just on inter-request delays.

Better approach: Use a 5ms delay at 9600 baud and a 2ms delay at 19200 baud. Monitor CRC error rates — if they increase, lengthen the delay. Some older devices need more silence time than the spec requires.

Multi-Device Polling Scheduling​

When your edge gateway talks to multiple Modbus devices (common in manufacturing — one PLC per machine line, plus temperature controllers, VFDs, and meters), polling strategy becomes a scheduling problem.

Round-Robin: Simple but Wasteful​

The naive approach:

while true:
    for each device:
        for each tag_group in device:
            read(tag_group)
    sleep(poll_interval)

Problem: If you have 8 devices with different priorities, the critical machine's data is delayed by reads to 7 other devices.

Priority-Based with Interval Tiers​

A better model uses per-tag read intervals:

Implementation: Maintain a last_read_timestamp per tag (or per tag group). On each poll loop, only read groups where now - last_read > interval.

This dramatically reduces bus traffic. In a typical plastics manufacturing scenario with 8 machines:

• Without tiers: 400 register reads every 5 seconds = 80 reads/sec
• With tiers: 80 critical + 40 process + 2 diagnostic = ~14 reads/sec average

That's a 5.7x reduction in bus utilization.

Change-Based Transmission​

For data going to the cloud, there's another optimization layer: compare-on-change. Many industrial values don't change between reads — a setpoint stays at 350°F for hours, a machine status stays "running" for the entire shift.

The strategy:

1. Read the register at its configured interval (always — you need to know the current value)
2. Compare the new value against the last transmitted value
3. Only transmit to the cloud if:
   • The value has changed, OR
   • A maximum time-without-update has elapsed (heartbeat)

For boolean tags (machine running, alarm active), compare every read and transmit immediately on change — these are the signals that matter most for operational response.

For analog tags (temperature, pressure), you can add a deadband: only transmit if the value has changed by more than X% or Y absolute units. A temperature reading that bounces between 349.8°F and 350.2°F doesn't need to generate 60 cloud messages per hour.

machineCDN's edge agent implements this compare-and-transmit pattern natively, batching changed values into optimized payloads that minimize both bandwidth and cloud ingestion costs.

RTU vs TCP: Polling Strategy Differences​

Modbus RTU (Serial RS-485)​

• Half-duplex: Only one device can transmit at a time
• Single bus: All devices share the same wire pair
• Addressing: Slave address 1-247 (broadcast at 0)
• Speed: Typically 9600-115200 baud
• Critical constraint: Bus contention — you MUST wait for a complete response (or timeout) before addressing another device
• CRC: 16-bit CRC appended to every frame

RTU polling tips:

• Set timeouts based on maximum expected response size. For 125 registers at 9600 baud: (125 * 2 bytes * 10 bits/byte) / 9600 = ~260ms plus overhead ≈ 300-500ms timeout
• Never set the timeout below the theoretical transmission time — you'll get phantom timeouts
• If one device on the bus goes unresponsive, its timeout blocks ALL other devices. Aggressive timeout + retry is better than patient timeout + no retry.

Modbus TCP​

• Full-duplex: Request and response can overlap (on different connections)
• Multi-connection: Each device gets its own TCP socket
• No contention: Parallel reads to different devices
• Speed: 100Mbps+ network bandwidth (practically unlimited for Modbus payloads)
• Transaction ID: The MBAP header includes a transaction ID for matching responses to requests

TCP polling tips:

• Use persistent connections — TCP handshake + Modbus connection setup adds 10-50ms per connection. Reconnect only on error.
• You CAN poll multiple TCP devices simultaneously using non-blocking sockets or threads. This is a massive advantage over RTU.
• Set TCP keepalive on the socket — some industrial firewalls and managed switches close idle connections after 60 seconds.
• The Modbus/TCP unit identifier field is usually ignored (set to 0xFF) for direct device connections, but matters if you're going through a TCP-to-RTU gateway.

Bandwidth Optimization: Binary vs JSON Batching​

Once you've read your registers, the data needs to get to the cloud. The payload format matters enormously at scale.

JSON Format (Human-Readable)​

{
  "groups": [{
    "ts": 1709330400,
    "device_type": 5000,
    "serial_number": 1106336053,
    "values": [
      {"id": 1, "v": 4.4, "st": 0},
      {"id": 2, "v": 162.5, "st": 0},
      {"id": 3, "v": 158.3, "st": 0}
    ]
  }]
}

For 3 values: ~200 bytes.

Binary Format (Machine-Optimized)​

A well-designed binary format encodes the same data in:

• 4 bytes: timestamp (uint32)
• 2 bytes: device type (uint16)
• 4 bytes: serial number (uint32)
• Per value: 2 bytes (tag ID) + 1 byte (status) + 4 bytes (value) = 7 bytes

For 3 values: 31 bytes — an 84% reduction.

Over cellular connections (common for remote industrial sites), this difference is enormous. A machine reporting 50 values every 60 seconds:

• JSON: ~3.3 KB/min → 4.8 MB/day → 144 MB/month
• Binary: ~0.5 KB/min → 0.7 MB/day → 21 MB/month

That's the difference between a $10/month cellular plan and a $50/month plan — multiplied by every connected machine.

The batching approach also matters. Instead of transmitting each read result immediately, accumulate values into a batch and transmit when either:

• The batch reaches a size threshold (e.g., 4KB)
• A time threshold expires (e.g., 30 seconds since batch started)

This amortizes the MQTT/HTTP overhead across many data points and enables efficient compression.

Store-and-Forward: Surviving Connectivity Gaps​

Industrial environments have unreliable connectivity — cellular modems reboot, VPN tunnels flap, WiFi access points go down during shift changes. Your polling shouldn't stop when the cloud connection drops.

A robust edge gateway implements a local buffer:

1. Poll and batch as normal, regardless of cloud connectivity
2. When connected: Transmit batches immediately
3. When disconnected: Store batches in a ring buffer (sized to the available memory)
4. When reconnected: Drain the buffer in chronological order before transmitting live data

Buffer Sizing​

The buffer should be sized to survive your typical outage duration:

For embedded gateways with 256MB RAM, a 2MB ring buffer comfortably handles 8-24 hours of typical industrial data at modest polling rates. The key design decision is what happens when the buffer fills: either stop accepting new data (gap in the oldest data) or overwrite the oldest data (gap in the newest data). For most IIoT use cases, overwriting oldest is preferred — recent data is more actionable than historical data.

Putting It All Together: A Production Polling Architecture​

Here's what a production-grade Modbus polling pipeline looks like:

┌─────────────────────────────────────────────────────┐
│                 POLL SCHEDULER                       │
│  Per-tag intervals → Priority queue → Due tags      │
└──────────────┬──────────────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────────────┐
│              REGISTER GROUPER                        │
│  Sort by FC → Find contiguous runs → Build groups   │
└──────────────┬──────────────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────────────┐
│              MODBUS READER                           │
│  Execute reads → Retry on error → Reconnect logic   │
└──────────────┬──────────────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────────────┐
│              VALUE PROCESSOR                         │
│  Byte-swap → Type conversion → Scaling → Compare    │
└──────────────┬──────────────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────────────┐
│              BATCH ENCODER                           │
│  Group by timestamp → Encode (JSON/binary) → Size   │
└──────────────┬──────────────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────────────┐
│           STORE-AND-FORWARD BUFFER                   │
│  Ring buffer → Page management → Drain on connect   │
└──────────────┬──────────────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────────────┐
│              MQTT PUBLISHER                          │
│  QoS 1 → Async delivery → ACK tracking             │
└─────────────────────────────────────────────────────┘

This is the architecture that machineCDN's edge agent implements. Each layer is independently testable, and failures at any layer don't crash the pipeline — they produce graceful degradation (data gaps in the cloud, not system crashes on the factory floor).

Benchmarks: Before and After Optimization​

Real numbers from a plastics manufacturing deployment with 8 Modbus RTU devices on a 19200 baud RS-485 bus, 320 total tags:

The unoptimized system couldn't even complete a poll cycle in under a minute. The optimized system polls every 6 seconds with headroom to add more devices.

Final Recommendations​

1. Always group contiguous registers — this is non-negotiable for production systems
2. Use tiered polling intervals — not every tag needs the same update rate
3. Implement error-classified retry — don't retry permanent errors, do retry transient ones
4. Use binary encoding for cellular — JSON is fine for LAN-connected gateways
5. Size your store-and-forward buffer for your realistic outage window
6. Flush the serial buffer after errors — this prevents CRC cascades on RTU
7. Document byte ordering per device — test with known values during commissioning
8. Monitor bus utilization — stay below 30% to leave headroom for retries and growth

Modbus isn't going away. But the difference between a naive implementation and an optimized one is the difference between a system that barely works and one that scales to hundreds of machines without breaking a sweat.

machineCDN's edge agent handles Modbus RTU and TCP with optimized register grouping, binary batching, and store-and-forward buffering out of the box. Connect your PLCs in minutes, not weeks. Get started →