Resolving S7-1200 CM1241 Modbus Master Idle After Firmware Update

Problem Summary: MB_MASTER Goes Idle with No Status Feedback

On a SIMATIC S7-1200 CPU (firmware V4.0.x or earlier) coupled to a CM 1241 RS485 / RS232 communication module (firmware V2.0.x), the MB_MASTER instruction in TIA Portal occasionally enters a latched "idle" state in which neither DONE nor ERROR is asserted. The BUSY bit is also cleared, so the polling sequence in the user program silently stalls. The fault manifests only when the Modbus slave is offline, late, or electrically disconnected.

The visible symptoms from the field are:

• BUSY = 0, DONE = 0, ERROR = 0 for indefinite periods
• The user task hangs at the MB_MASTER call and does not advance to the next request
• Power cycling or STOP/RUN of the S7-1200 CPU temporarily restores the link
• The fault reappears days or hours later when the slave drops again
• No diagnostic buffer entry is written by the CM 1241

A related symptom is reported on Modbus TCP between an S7-1200 CPU and a PC HMI/SCADA: after installing TIA Portal V13 SP1 Upd. 2, the TCP connection drops and only a CPU restart re-establishes it. Both symptoms are tied to firmware revisions on the S7-1200 platform rather than to user logic.

Affected Hardware and Firmware Matrix

For Modbus TCP applications, the issue is bound to CPU firmware V4.0.x running the MB_CLIENT or MB_SERVER blocks; the fix is delivered in CPU firmware V4.1.0 and is also included in all subsequent V4.x service packs.

Root Cause Analysis

The CM 1241 Modbus RTU engine in firmware V2.0.x implements an internal "line-idle" detector that times out when no valid Modbus response is received within the configured inter-character or response timeout. The detector was supposed to surface the failure through the ERROR output of MB_MASTER with status code 0x80C8 (response timeout). In V2.0.x, a race condition between the timeout interrupt and the bus-task scheduling caused the engine to consume the REQ edge without writing back any of the three output bits. The REQ latch inside the instruction was cleared, but no DONE/ERROR pulse was generated, so the user ladder saw a request that had "disappeared" without a verdict.

Modbus TCP behaves differently but with similar surface symptoms. In CPU firmware V4.0.x, the MB_CLIENT connection state machine was not robust against a TCP RST/FIN arriving from the partner while a transaction was in flight. The internal socket state was left in a half-open condition that did not transition to ERROR; subsequent REQ pulses were absorbed silently. The recovery required a CPU STOP/RUN to reset the connection table.

Both defects are corrected by:

• Firmware update V2.1.0 for CM 1241 — fixes the RTU idle state and guarantees that the ERROR output is set on any internal timeout.
• Firmware version V4.1 released for S7-1200 CPUs — fixes the MB_CLIENT TCP connection state machine and eliminates the silent disconnect on partner RST.

Diagnostic Procedure Before Updating

Capture the following evidence to confirm you are looking at the firmware defect and not at a wiring, termination, or program defect:

1. Read the CM 1241 firmware version: in TIA Portal, go to Online > Diagnostics > Module Information > Firmware for the CM 1241 slot. Note the version string (e.g. V2.0.2).
2. Read the CPU firmware version: Online > Diagnostics > CPU Information > Firmware. Confirm V4.0.x or V4.1.x.
3. Force the slave offline (remove the RS485 terminator, power the slave down, or unplug the Ethernet cable).
4. Watch MB_MASTER.BUSY, MB_MASTER.DONE, MB_MASTER.ERROR, and MB_MASTER.STATUS in a watch table for 5 to 10 minutes.
5. If all three control bits return to 0 with STATUS = 0 after the slave was offline, the firmware defect is confirmed.
6. Capture the diagnostic buffer (Online > Diagnostics > Diagnostic Buffer) and the CM 1241 diagnostic structure; absence of an entry corroborates the firmware path.

Solution A: Apply the CM 1241 Firmware V2.1.0 Update

The Siemens knowledge base article 108819199 ships firmware V2.1.0 for the CM 1241 RS232 (6ES7241-1AH32-0XB0) and CM 1241 RS485 (6ES7241-1CH32-0XB0) modules. The package includes the .upd file used by the TIA Portal "Online > Firmware Update" wizard.

1. Download the firmware archive from the Siemens support portal (Siemens ID and entitlement required; the file is bundled with the TIA Portal HSP for V13 SP1+ or available as a standalone SIMATIC update).
2. Open the TIA Portal project and connect online to the S7-1200 CPU.
3. Select the CM 1241 in the device tree, then choose Online > Firmware Update.
4. Browse to the unpacked .upd file and confirm.
5. Wait for the progress to reach 100%. The CM 1241 will reset; expect a brief loss of the Modbus RTU link to the slaves.
6. Re-read the firmware version to confirm V2.1.0 is active.
7. Repeat the slave-offline test from the diagnostic procedure. The MB_MASTER.ERROR output must now pulse with status 0x80C8 and the master ladder must advance to the next request.

Solution B: Apply the S7-1200 CPU Firmware V4.1 Update (Modbus TCP)

The Siemens knowledge base article 106200276 ships firmware V4.1.0 for the entire S7-1200 CPU family. The V4.1.0 image contains the corrected MB_CLIENT/MB_SERVER connection state machine.

1. Back up the project and the CPU's online program.
2. Download the V4.1.0 firmware package. Files are distributed as part of the TIA Portal V13 SP1 Upd. 2 / V13 SP2 / V14 update media.
3. Online-connect to the CPU, select the CPU device, and run Online > Firmware Update.
4. Accept the license and select V4.1.0. The CPU stops, flashes, and performs an automatic restart.
5. Re-download your user program (or, if the program is preserved, verify it with the project compare tool).
6. Cycle the partner Modbus TCP device and confirm that MB_CLIENT returns ERROR = 1 with a status from the documented TCP error set, not a silent stall.

Application Hardening: Watchdog Around MB_MASTER

Even on fixed firmware, a robust user program should never trust that MB_MASTER will always produce a verdict inside the polling window. Wrap the master in a watchdog so that a stalled BUSY latches a user-defined error that can be raised to the SCADA, used to skip the slave, or trigger a CM 1241 re-init.

Approach in SCL for an FB named FB_ModbusSupervisor:

FUNCTION_BLOCK "FB_ModbusSupervisor"
VAR
    busyTimer   : TON;       // 5-second window, configurable
    reqEdge     : BOOL;      // rising edge of MB_MASTER.REQ
    lastError   : WORD;      // captured MB_MASTER.STATUS on fault
    watchdogTrip: BOOL;      // latched fault
END_VAR

VAR CONSTANT
    WD_TIME : TIME := T#5s;
END_VAR

BEGIN
    // Track rising edge of REQ to arm the watchdog
    IF "mbMaster".REQ AND NOT reqEdge THEN
        busyTimer(IN := FALSE);
        busyTimer(IN := TRUE, PT := WD_TIME);
    END_IF;
    reqEdge := "mbMaster".REQ;

    // Accept normal completion
    IF "mbMaster".DONE OR "mbMaster".ERROR THEN
        busyTimer(IN := FALSE);
        IF "mbMaster".ERROR THEN
            lastError := "mbMaster".STATUS;
        END_IF;
    END_IF;

    // Watchdog: if MB_MASTER stayed busy past WD_TIME without verdict, latch a fault
    IF busyTimer.Q THEN
        watchdogTrip := TRUE;
    END_IF;

    // Optional automatic recovery: pulse MB_MASTER.REQ off for one cycle
    // after a watchdog trip. The CM 1241 V2.1+ will then re-arm cleanly.
    IF watchdogTrip AND NOT "mbMaster".BUSY THEN
        "mbMaster".REQ := FALSE;          // ensure REQ drops
        watchdogTrip := FALSE;            // user can clear via HMI
    END_IF;
END_FUNCTION_BLOCK

For Modbus TCP, apply the same pattern to MB_CLIENT. Pair the watchdog with a MB_CLIENT DISCONNECT followed by CONNECT in the next cycle on trip; CPU firmware V4.1+ guarantees that the connect state machine exits cleanly when the partner is reachable.

MB_MASTER and MB_CLIENT Status Code Reference

Use the table below to interpret the most common non-zero STATUS outputs. The codes are documented in the S7-1200 System Manual, chapter "Modbus communications".

Verification Steps After the Update

1. Re-read the CM 1241 and CPU firmware versions in TIA Portal to confirm V2.1.0 and V4.1.0 (or later) are active.
2. Force the slave offline and watch the master for 10 minutes. ERROR must pulse, STATUS must read 0x80C8, and the ladder must move to the next request.
3. Reconnect the slave. The master must recover on its own; verify by reading the next process data update in the SCADA.
4. For Modbus TCP, force the partner to send a TCP RST. The MB_CLIENT block must exit with a populated status and a fresh CONNECT must succeed.
5. Monitor for 24 to 72 hours with the watchdog trip flag exposed to the SCADA. Zero trips confirm the firmware fix and the application hardening are both working.

Known Limitations and Edge Cases

• If the CM 1241 is on a non-Siemens slave network that uses long inter-frame gaps (e.g. > 100 ms), raise the MB_MASTER timeout parameter rather than relying on the watchdog alone.
• Modbus RTU over RS485 with more than 32 device loads requires a repeater; the CM 1241 V2.1.0 firmware does not change the 32-unit physical-layer budget.
• CPU firmware V4.1 does not re-enable older CPU 1211C variants that lack the Modbus TCP instruction set. Verify the instruction is available for your MLFB in the S7-1200 System Manual.
• The Modbus RTU engine still uses the configured MB_MASTER cycle time. If the cycle time is shorter than the worst-case slave response, the engine will report 0x80C8; that is correct behaviour and not a regression.

Migration Checklist for Field Service

1. Capture a backup of the TIA Portal project and the online program.
2. Document current CPU and CM 1241 firmware versions.
3. Order or download the V4.1.0 CPU firmware and the V2.1.0 CM 1241 firmware packages from the Siemens support portal.
4. Schedule a maintenance window; inform operations that the CM 1241 will reset and the Modbus TCP socket will close briefly.
5. Apply CM 1241 V2.1.0 first, then CPU V4.1.0. Power-cycle the CPU if prompted.
6. Re-download the project if it was cleared by the firmware update.
7. Run the slave-offline verification procedure and the TCP RST verification procedure.
8. Record the new firmware versions in the asset register and update the maintenance plan.

Frequently Asked Questions