S7-1200 Modbus Master: Configuring 2 Stop Bits with MB_COMM_LOAD

Problem: S7-1200 Modbus Master Cannot Read 2-Stop-Bit RTU Slaves

A S7-1200 CPU configured as a Modbus RTU master reads a 1-stop-bit slave correctly, but the same program returns no data, no exception responses, and no error flags when pointed at a Modbus RTU slave configured for 2 stop bits, no parity. The slave is known to be functional (verified with a third-party master or analyzer). The error persists across baud rates from 9600 to 115200 bit/s and across both RS485 and RS485/232 communication modules.

Per the TIA Portal V20 Modbus RTU error messages documentation for S7-1200/S7-1500, the first diagnostic action is to confirm that identical baud rate, parity, and stop-bit count are configured on both sides of the link. When the S7-1200 side silently ignores the requested 2-stop-bit frame format, the root cause is internal to the Modbus library, not the wiring.

Root Cause: MB_COMM_LOAD Does Not Propagate 2 Stop Bits

The S7-1200 MB_COMM_LOAD instruction (FB 1080 in the standard Modbus RTU library) writes serial port parameters through the PtP port configuration structure. Field experience and Siemens Modbus RTU library documentation show that the STOP_BITS value placed in the MB_COMM_LOAD_DB port configuration is not consistently applied when the value is 2. The underlying physical interface (CM 1241 RS232 / CM 1241 RS422/485 / CB 1241 RS485) supports 2 stop bits at the hardware level; the issue is the configuration transfer path, not the serial transceiver.

Resulting symptoms:

• Slave returns no reply — the master waits for the configured response timeout and reports ERROR = 1, STATUS = 0x80C8 (no response received within timeout) on the MB_MASTER instance.
• No Modbus exception code is generated, because the master is transmitting with the wrong framing and the slave discards the frame silently.
• Switching to 1 stop bit on the slave resolves the issue immediately, confirming a frame-format mismatch.

Affected Hardware and Firmware

Modbus RTU Frame Format Reference

Modbus RTU defines a 3.5 character silent interval between frames, slave address (1 byte), function code (1 byte), data (N bytes), and a 2-byte CRC. The stop-bit count is per-byte, not per-frame. Configuring 2 stop bits is legal under the Modbus spec and is commonly used with devices that require an extended inter-character gap or where the receiver uses 2 stop bits for clock-recovery margin.

Solution 1: Override Stop Bits with PORT_CFG After MB_COMM_LOAD

The reliable workaround uses the PORT_CFG instruction (FB 1130 in the PtP library) to write the port configuration structure after MB_COMM_LOAD completes initialization. PORT_CFG writes directly to the port's hardware-level parameter block and overrides any stop-bit value that MB_COMM_LOAD left in an invalid state.

Step-by-Step Procedure

1. Open the S7-1200 project in TIA Portal (V16 or later, V18+ recommended for current library revisions).
2. In the project tree, add the Modbus library and the PtP (Point-to-Point) library from "Options → Manage Libraries" if not already present.
3. In the main OB (typically OB1), call MB_COMM_LOAD as normal. Set the input MODE to 4 (or 5 for half-duplex RS485 4-wire, depending on the module). Configure baud, parity, and data bits to match the slave exactly. Leave STOPBITS at the default 2 value — it will not be applied correctly, but the other parameters will.
4. Place a second network in OB1 that runs after the MB_COMM_LOAD call. Use a one-shot rising edge on the DONE output of MB_COMM_LOAD to trigger PORT_CFG exactly once per startup.
5. On the PORT_CFG block, wire the same PORT HW identifier (the system constant of the CM/CB 1241 port), the same baud rate, parity, and data bits, and set the stop-bit input to 2.
6. Call MB_MASTER on a cyclic trigger (e.g., 100 ms clock bit from the system clock) to issue the standard Modbus read/write requests.

PORT_CFG Parameter Wiring

ST Snippet for PORT_CFG Trigger

// One-shot trigger from MB_COMM_LOAD completion
#LoadDoneEdge := #MB_COMM_LOAD_DB.DONE AND NOT #LoadDonePrev;
#LoadDonePrev := #MB_COMM_LOAD_DB.DONE;

IF #LoadDoneEdge THEN
    PORT_CFG.REQ := TRUE;
END_IF;

PORT_CFG(
    REQ := #LoadDoneEdge,
    PORT := "CM1241_RS485",
    PROTOCOL := 1,            // 0=full-duplex, 1=half-duplex RS485
    BAUD := 19200,
    PARITY := 0,              // 0=None
    DATABITS := 8,
    STOPBITS := 2,            // 2-stop-bit override
    FLOWCTRL := 0,
    XONCHAR := 16#11,
    XOFFCHAR := 16#13,
    DONE => #CfgDone,
    ERROR => #CfgError,
    STATUS => #CfgStatus
);

Verification of the Override

Confirm PORT_CFG completes with DONE = 1, ERROR = 0, STATUS = 0 on the first scan after startup. If ERROR = 1, the status word identifies the cause:

Solution 2: Reconfigure the Slave to 1 Stop Bit

If the slave supports selectable framing (most modern Modbus RTU devices do), the simplest fix is to change the slave to 1 stop bit, no parity, 8 data bits. This is the most common Modbus RTU framing and is fully supported by MB_COMM_LOAD with no further workarounds.

Procedure:

1. Access the slave's configuration tool (vendor-specific software, DIP switches, or web interface).
2. Set: Baud 19200, Parity None, Data bits 8, Stop bits 1.
3. Save and power-cycle the slave.
4. On the S7-1200, set the same values in MB_COMM_LOAD and cycle the CPU power.
5. Verify MB_MASTER returns DONE = 1 on the first request.

This is the recommended approach when the slave vendor permits reconfiguration, because it eliminates the workaround maintenance burden and ensures the S7-1200 program follows the standard Modbus RTU library call flow.

Solution 3: Use a Protocol Converter

If the slave cannot be reconfigured and the workaround above is rejected by site standards, place a Modbus RTU-to-Modbus RTU converter in line that re-frames 2-stop-bit to 1-stop-bit transparently. Devices such as the Anybus Communicator, Moxa MGate, or HMS Ewon gateways handle this in hardware. Configure the converter's "upstream" (S7-1200-facing) port to 1 stop bit, no parity, and the "downstream" (slave-facing) port to 2 stop bits, no parity. The S7-1200 talks standard Modbus RTU to the converter; the converter manages the non-standard framing to the slave.

Verification: Confirming the Communication Path

After applying Solution 1 or Solution 2, run the following checks in order:

1. Status word sanity check. Confirm MB_COMM_LOAD finishes the first scan with DONE = 1, ERROR = 0, STATUS = 0x0000.
2. Frame check with oscilloscope or protocol analyzer. Probe the RS485 A/B lines. With Solution 1 active, the idle-to-data transition should show a 2-bit stop period after each byte. With Solution 2, the stop period should be 1 bit. Tap on a 2-stop-bit byte (e.g., the last data byte of function code 03) to confirm visually.
3. MB_MASTER response. Issue a Modbus function code 03 (read holding registers) request. Expected output: DONE = 1, ERROR = 0, DATA_PTR populated with the slave's response. If ERROR = 1 and STATUS = 0x80C8, the slave is still not receiving a valid frame — re-check the wiring and the PORT_CFG STATUS.
4. CRC verification. Capture a frame with a Modbus RTU sniffer (e.g., Modbus Poll, CAS Modbus Scanner) and confirm the CRC matches the slave's expected response. A valid CRC with no slave response points to a slave address mismatch, not a framing issue.
5. Long-term stability. Leave the link running for 24 hours with a watchdog counter incremented on every successful MB_MASTER.DONE. The counter should not decrement over time.

Troubleshooting Matrix

Best-Practice Recommendations

• Use 1 stop bit for new installations unless the slave documentation explicitly requires 2 stop bits. Most Modbus RTU slaves default to 1 stop bit and only use 2 for legacy compatibility with non-Motorola-derived UARTs.
• Document the chosen framing (baud, parity, data, stop) in the HMI or program header comments so that future maintenance engineers do not have to dig through the MB_COMM_LOAD and PORT_CFG calls.
• When 2 stop bits are required, place the PORT_CFG call in the same OB that contains MB_COMM_LOAD, triggered by its DONE edge, to prevent re-init conflicts.
• Add a status display of MB_MASTER.STATUS to the HMI. Operators can read the error code without needing to attach TIA Portal online.
• Keep the master request cycle slow enough for the slave to respond (typical minimum 50 ms between requests on multidrop RS485).

FAQ