Initializing MODBUS_COMM_LOAD and MODBUS_MASTER for S7-300

Overview

The Siemens Modbus RTU library for the S7-300/ET 200SP family separates the port configuration (FB MODBUS_COMM_LOAD) from the master polling logic (FB MODBUS_MASTER). This split is intentional: configuration parameters are static and applied once, while polling transactions are dynamic and executed every cycle. The most common commissioning failure mode is calling MODBUS_COMM_LOAD repeatedly in OB1, which reconfigures the port on every scan, breaks the running MODBUS_MASTER transaction, and produces intermittent timeouts. This article documents the correct initialization timing for a CPU 315 controlling a CM PtP module in an ET 200SP station, including the role of COM_RST and REQ.

Prerequisites

• STEP 7 (TIA Portal) V15.1 or higher, or STEP 7 V5.5 SPx with the "Modbus" library installed.
• Modbus RTU master library installed; for S7-1200/1500/ET 200SP this is delivered as part of the standard Modbus instruction set. For S7-300 classic library, the FBs ship with the Modbus driver DVD.
• ET 200SP station configured in HW Config / device view with the CM PtP module in the slot used for serial communication.
• Logical HW identifier of the CM PtP module noted from the device properties (e.g. 269 for slot 1 in a typical ET 200SP head).
• RS-485 termination enabled at both line ends (typically 120 Ω) when wiring multi-drop slaves.

Function Block Architecture

The library implements Modbus RTU as two cooperating FBs plus the underlying PtP driver:

Per the official Siemens Modbus documentation, Modbus_Comm_Load is configured to "configure a communications module for communication by means of the Modbus RTU protocol" and must be executed once before the master block can issue transactions (TIA Portal: Modbus_Comm_Load – Configure communication module).

MODBUS_COMM_LOAD Parameters

Per the Siemens support note for Modbus_Comm_Load: "Call Modbus_Comm_Load from a startup OB and execute it one time or use the first scan system flag to initiate the call to execute it one time" (Siemens Support: Modbus_Comm_Load initialization). Executing it more than once is supported only when port parameters genuinely change.

MODBUS_MASTER Parameters

Outputs: DONE pulses for one cycle on success, BUSY=TRUE while the request is outstanding, ERROR=TRUE with non-zero STATUS on failure.

Why the Split Between Configuration and Polling Exists

Modbus RTU is a single-master, multi-drop protocol with strict timing requirements: a 3.5-character silent interval marks the start and end of every frame. If the port is reconfigured between frames, the character timer is restarted, the transmitter direction toggles, and an in-flight frame is corrupted. Therefore the library enforces a strict ordering:

1. Configure the port once.
2. Wait for the configuration to complete (DONE=TRUE, ERROR=FALSE).
3. Begin issuing Modbus transactions; the master FB manages all frame timing internally.

Reconfiguring mid-traffic is a programming error, not a feature. The library does not prevent it; the user program must.

When to Set EN, COM_RST, and REQ

All three FBs use EN (enable) and REQ/COM_RST for different purposes. The lifecycle is:

EN – block enable

EN must be TRUE every time the FB is called. In ladder this is wired to a constant 1 or to the OB scan flag. The FB does no work when EN=FALSE; leaving it FALSE effectively disables the block.

COM_RST – instance reset

COM_RST is a level/edge input that clears the instance DB: pending frames are aborted, internal state machines return to idle, the port is forced back to its default (pre-configuration) settings. Use it:

• On cold/warm restart, typically in OB 100, to ensure no half-finished transactions from a previous run survive a reboot.
• After a fatal error that leaves the bus stuck (STATUS=0x80C8 or similar unrecoverable codes), to bring the FB back to a known state.
• Never pulse it in normal cyclic OB 1 unless you are intentionally recovering from a fault – doing so will halt any active MODBUS_MASTER transaction.

REQ – execute / re-execute

For MODBUS_COMM_LOAD, REQ is a rising-edge trigger that re-applies the static configuration to the port. Apply it once after COM_RST has been released, then never again unless parameters change. A common pattern is to drive it from a one-shot (positive edge of a "first cycle" flag).

For MODBUS_MASTER, REQ controls transaction issuance. Two valid patterns exist:

1. Continuous polling: tie REQ=TRUE permanently; the FB auto-issues the next request as soon as DONE/ERROR fires and BUSY falls. Use this when the cycle time to one slave is the desired refresh rate.
2. Triggered polling: pulse REQ from a timer or event; the FB completes one transaction and waits for the next edge.

Step-by-Step: Correct Initialization on OB 100 + OB 1

The following sequence matches Siemens' recommended procedure for the S7-300/ET 200SP Modbus library.

Step 1 – Declare instance data blocks

For each call to MODBUS_COMM_LOAD and MODBUS_MASTER, declare a separate instance DB (e.g. DB_MB_LOAD, DB_MB_MASTER) and select "Instance" in the FB call. Multi-instance is also valid on S7-300/400 CPUs that support it.

Step 2 – OB 100 (startup)

In OB 100, on the first (and only) cycle:

• Set MB_Load_COM_RST := TRUE and MB_Master_COM_RST := TRUE for one cycle.
• Reset the MB_ConfigDone and MB_MasterStarted flags.

Step 3 – OB 1, network 1: complete configuration

Wait for the COM_RST signals to return to FALSE (they self-clear inside the FB on the cycle after being processed), then pulse REQ on MODBUS_COMM_LOAD:

|   --[ NOT MB_Load_COM_RST ]--[ NOT MB_Master_COM_RST ]--|
|        [ MB_Load_DONE OR MB_Load_ERROR ]--[ MB_ConfigDone ]--|
|                                                               ( FP )-- MB_Load_REQ := TRUE

Wait for MB_Load_DONE=TRUE and latch MB_ConfigDone := TRUE. If MB_Load_ERROR=TRUE, capture MB_Load_STATUS and abort.

Step 4 – OB 1, network 2: poll slaves

Once MB_ConfigDone=TRUE, enable the master FBs:

• Set MB_Master_REQ := MB_ConfigDone (continuous) or pulse from a timer.
• Chain the FBs for the 10 slaves one after the other; only one transaction is active per scan because each FB sets BUSY=TRUE until the response arrives.

Step 5 – Optional: watchdog

Start an IEC timer (e.g. TON with PT=5 s) on every REQ rise. If the timer expires without DONE or ERROR, pulse COM_RST on the affected FB and re-issue.

STATUS Code Reference

ET 200SP CM PtP Specific Notes

• The CM PtP module appears in the device view at a fixed slot (slot 1 by default). The HW identifier of the submodule providing the serial interface (e.g. CM PtP rather than the interface module) is the one to use in PORT.
• RS-485 mode requires the FLOW_CTRL=0 setting. Hardware flow control is RS-232 only.
• Set the RTS_OFF_DLY to a small positive value (e.g. 10 ms) if the bus master is unable to release the line cleanly between frames and slaves see residual characters.
• The CM PtP requires firmware ≥ V2.0 for full Modbus RTU master support; older firmware only supports the ASCII variant. Verify with HW Config / device properties.

Verification

1. Online: watch MB_Load_STATUS return to 0000 after OB 100 and stay there.
2. Watch MB_Master_BUSY toggle TRUE while a transaction is outstanding and back to FALSE within RESP_TO.
3. Confirm MB_Master_DONE pulses once per successful transaction; count pulses in the online monitor – it should match the expected number of polls per second.
4. For 10 slaves at 9600 baud with FC 3 reads of 10 registers each, expect roughly 8 to 12 transactions per second, depending on slave response time.
5. Disconnect one slave and confirm the FB returns ERROR=TRUE with STATUS=0x80C8 for that slave only, while the others continue.

Troubleshooting Matrix

Common Mistakes to Avoid

• Calling MODBUS_COMM_LOAD in OB 1 with REQ driven by a constant 1. Every cycle reconfigures the port and corrupts frames.
• Forgetting to pulse COM_RST on the first call after a download. The instance DB is freshly initialised but the underlying port state may still carry parameters from a previous project.
• Sharing one instance DB between two MODBUS_MASTER FBs. Each FB needs its own instance; otherwise the state machines collide.
• Using MW/QW addresses in DATA_PTR that overlap with the inputs of the FB itself – the FB will overwrite its own control bits.
• Leaving REQ=FALSE on MODBUS_MASTER after start-up. The master will never issue a transaction. REQ on the master is not a one-shot – it is the run enable.

Sample Ladder Snippet (S7-300, FBD-style)

Network 1 – OB 100 startup: pulse COM_RST
      OB100_FIRST_CYCLE  --[ P ]--  MB_LOAD_COM_RST
      OB100_FIRST_CYCLE  --[ P ]--  MB_MASTER_COM_RST

Network 2 – OB 1: trigger MODBUS_COMM_LOAD after COM_RST cleared
      NOT MB_LOAD_COM_RST
      AND NOT MB_MASTER_COM_RST
      AND NOT MB_CONFIG_DONE
      ----------------------------------( P )-- MB_LOAD_REQ

Network 3 – OB 1: latch "configuration done"
      MB_LOAD_DONE   --[ S ]--  MB_CONFIG_DONE
      MB_LOAD_ERROR  --[ S ]--  MB_CONFIG_ERROR

Network 4 – OB 1: continuous master polling
      MB_CONFIG_DONE
      AND NOT MB_CONFIG_ERROR
      --------------------------------------- MB_MASTER_REQ

FAQ