Resolving Slow CM PtP Modbus RTU Master Response on S7-1500

Problem Definition

A Siemens S7-1500 system using a CM PtP (Communication Module, Point-to-Point) configured as a Modbus RTU master reports a 100 ms latency between raising the REQ input on the MB_MASTER instance DB and the assertion of the DONE output. The slave response itself is correct (8-byte request, 7-byte reply), but the polling cycle observed at the master is dominated by what appears to be ~90 ms of dead time per transaction. With 17 slaves on the bus, the full scan reaches 1.7 seconds at this rate, which is unacceptable for any time-sensitive application.

Modbus RTU Timing Analysis at 19200 Baud

Modbus RTU mandates a 3.5 character inter-frame silence between consecutive frames. At 19200 bit/s with 10 bits per character (1 start + 8 data + 1 stop, no parity), one character time is:

t_char = 10 / 19200 = 0.5208 ms (520.8 µs)

The required silent interval between frames is:

t_silent = 3.5 × t_char = 1.823 ms

The 100 ms observed at the master therefore contains ~89 ms of unaccounted latency. This is not a baud-rate problem; the wire transaction itself completes in ~11 ms. The remaining 89 ms is spent inside the controller, not on the bus.

Root Cause Analysis

The observed latency arises from three independent sources that stack on top of the wire transaction. Disaggregating these is the key to fixing the problem.

1. MB_MASTER state-machine processing in OB1: MB_MASTER is a multi-instance instruction that advances one internal state per call (REQUEST → WAIT_FOR_REPLY → READ → DONE). In OB1 (10–15 ms cycle), the maximum throughput is one state transition per cycle. Each transition involves a handshake with the CM PtP over the backplane bus, which itself takes 1–3 ms. Four state transitions per transaction therefore consume 40–60 ms before DONE is asserted.
2. Default character-delay end-of-message detection: when the receive end condition is set to "After character delay time elapses", the CM PtP must observe 3.5 character times of silence AFTER receiving the last byte of the response before signalling the buffer complete. The firmware also adds a debounce window on top of this timer, inflating the close-out phase to ~4–6 ms even when the slave response is exactly the expected length.
3. Receive-condition interaction: pairing "Start of any character" with the default character-delay end condition prevents the CM from optimising the receive state machine for short, fixed-length responses. Some CM PtP firmware revisions offer "Message end after receipt of n characters" or "Receive complete after character delay (configurable)" modes that shorten the close-out phase to <0.5 ms.

CM PtP Receive Condition Configuration

Open the CM PtP device configuration in TIA Portal and navigate to Port configuration → RECV conditions. The following parameters directly control the end-of-message evaluation and overall per-transaction latency:

For a 17-slave poll with fixed response lengths, switching the end condition to "After receipt of n characters" typically reduces the close-out phase from ~5 ms to <0.5 ms. This configuration is documented in the official Siemens Modbus RTU application example at Siemens application example 68202723 (S7-1500 Modbus RTU DOC v21) and in the TIA Portal reference at Overview of Modbus communication (S7-1500).

MB_MASTER Call Placement Strategies

The MB_MASTER instruction must be called cyclically. The OB in which it runs controls how fast the state machine advances:

Recommended procedure:

1. Add a new cyclic interrupt OB (e.g., OB32 or OB35) with a 5 ms time interval in the device configuration under CPU properties → Cyclic interrupts.
2. Move the MB_MASTER call from OB1 into the new cyclic OB.
3. Keep all other cyclic logic (HMI update, alarming, etc.) in OB1.
4. Ensure the cyclic OB priority is higher than OB1 priority 1 (typical priority 8–12).

// OB32 (Cyclic interrupt, 5 ms)
// MB_MASTER call example for one polled slave
#MB_MASTER_DB.MODE      := 0;          // 0 = RTU
#MB_MASTER_DB.MASTER_ID := W#16#0001;  // CM PtP hardware ID from device config
#MB_MASTER_DB.SLAVE     := #current_slave;
#MB_MASTER_DB.READ_LEN  := 1;
#MB_MASTER_DB.WRITE_LEN := 0;
#MB_MASTER_DB.WRITE_PTR := P#M 100.0 BYTE 20;
#MB_MASTER_DB.READ_PTR  := P#M 200.0 BYTE 20;
#MB_MASTER_DB.REQ       := #req_pulse;
#MB_MASTER_DB();

IF #MB_MASTER_DB.DONE OR #MB_MASTER_DB.ERROR THEN
    #req_pulse := FALSE;
    #current_slave := #current_slave + 1;
    IF #current_slave > 17 THEN
        #current_slave := 1;
    END_IF;
END_IF;

Polling Strategy for 17 Slaves

Sequential polling of 17 slaves at 15 ms per transaction yields a 255 ms scan time at the wire. To shrink this further, consider the following tactics:

• Grouped requests: many slaves support FC 15 (Write Multiple Coils), FC 16 (Write Multiple Registers), or FC 23 (Read/Write Multiple Registers) that consolidate several logical requests into one frame. One FC 16 request for 16 coils replaces 16 single-coil reads.
• Asymmetric polling: poll critical slaves every cycle, slow-changing slaves every 5th or 10th cycle. Use a modulo counter in the sequencer to skip non-critical slaves.
• Baud-rate increase: 115200 bit/s reduces wire time per transaction from ~11.5 ms to ~1.9 ms. Combined with the above, the full 17-slave scan fits in <40 ms.
• Broadcast writes: Modbus slave address 0 is reserved for broadcast. Use FC 5/FC 6/FC 15/FC 16 with slave address 0 to push common setpoints to all slaves in a single frame.

Step-by-Step Optimization Procedure

1. Capture baseline: connect an oscilloscope or logic analyser (Saleae, PicoScope) to the RS-485 A/B differential lines and measure t_REQ→DONE using a digital input wired to the DONE bit of the MB_MASTER instance DB.
2. Verify baud rate: in CM PtP configuration, set 19200 bit/s (8E1 or 8N1 per slave datasheet). Mismatched parity is the most common cause of phantom latency on first deployment.
3. Tune receive end condition: switch from "After character delay" to "After receipt of n characters" if response length is fixed, or shorten the character delay to 1.823 ms explicitly (instead of relying on the firmware default).
4. Move MB_MASTER to a cyclic OB: create OB32 with a 5 ms period; transfer the MB_MASTER call from OB1. Verify the cyclic OB is not overloaded by adding OB32 runtime measurement via the OB1_DATE_TIME stamping or a TON block.
5. Increase baud rate: 38400 or 115200 bit/s if cable length (<100 m) and all slaves permit. Verify RS-485 termination (120 Ω at both ends) and bias resistors (fail-safe bias, typically 680 Ω to +5 V and GND on the master) are installed.
6. Group slaves: combine coils/status into multi-bit FC 15 / FC 16 transactions where the slave firmware supports it.
7. Re-measure: confirm per-transaction latency <25 ms (at 19200 baud with OB32) and full-scan latency <500 ms for all 17 slaves.

Verification and Measurement

Use the following checklist after optimisation. The wire-time value must match the baud-rate calculation within ±10 %.

Reference for STATUS codes and Modbus RTU parameter structure: TIA Portal Modbus RTU documentation for S7-1500 (V20).

CM PtP Firmware and Hardware Considerations

Firmware updates on the CM PtP have resolved receive-state-machine timing issues in earlier revisions. Check the firmware version in the device properties (online → diagnostics → module information) and update to the latest release available via TIA Portal's online support. The Siemens Modbus RTU application example referenced above includes version notes for each firmware revision that affects timing behaviour.

Troubleshooting Matrix

FAQ