S7-1200 CM1241 RS-485: Resolving Zero-Byte Transmission to Modbus Pressure Sensors

The S7-1200 family paired with a CM1241 communication module is one of the most common point-to-point Modbus RTU masters in mid-sized machine automation. When the module suddenly stops communicating with a previously working sensor and a serial sniffer or USB-RS485 adapter on the bus shows the controller transmitting only 0x00 bytes at a fixed interval, the failure is almost always configuration-related rather than hardware damage. This reference covers the root cause, the field-proven repair path, and the verification steps that should be performed on every CM1241 RS-485 link after any re-commissioning event.

1. Problem Statement and Observable Symptoms

The fault pattern reported in the field is highly specific and points to a deterministic root cause:

• Controller: Siemens SIMATIC S7-1200 (CPU 121xC or 121x FC, firmware 4.x or later).
• Module: CM 1241 communication module, RS-485 variant (6ES7241-1CH30-1XB0, 6ES7241-1CH32-1XB0, or the newer 6ES7241-1CH40-1XB0).
• Slave: Industrial pressure transducer using Modbus RTU, typically configured for 9600 8N1.
• Behavior after the PLC is re-energised: A PC running a Modbus master (e.g., Modbus Poll, QModMaster, or simply a USB-RS485 adapter and serial terminal) sees the CPU emit a steady stream of 0x00 0x00 0x00 ... at one-second intervals, with no response from the slave and no valid Modbus request frame on the bus.
• Physical layer proven good: The same cable, the same sensor, and the same RS-485 adapter have already been verified on a third-party PLC, so the wiring, biasing resistors, and sensor are exonerated.

The 0x00 flood is a signature. The CM1241 is generating a transmit request on the wire, but the data it is sending is null. This is what the firmware does when the MB_MASTER block is called with an illegal or uninitialised data pointer, or — far more commonly — when the COMM_LOAD block has not been executed with the correct MODE value for the RS-485 variant of the module.

2. Hardware Identification: Which CM 1241 Do You Have?

Siemens ships the CM 1241 in three RS-485-capable variants and one RS-232-only variant. Each requires different configuration of the MODE input of COMM_LOAD. Confirm the catalog number on the side of the module before proceeding.

The MODE parameter selects the electrical interface and the half-duplex/full-duplex behaviour. For every RS-485 variant listed above the parameter must equal 4. MODE values 0 through 3 select RS-232 operation; selecting 0, 1, 2, or 3 on a true RS-485 module results in a driver mismatch that produces exactly the 0x00 flood symptom described in the field report.

3. Required Software and Firmware Versions

Before changing any code, confirm the engineering software matches the controller firmware. Mixing versions is the second most common cause of silent Modbus failure on the CM1241.

The library block names changed between TIA V14 and V15: MB_COMM_LOAD became COMM_LOAD, and MB_MASTER kept its name. Old instance DBs from V13/V14 do not retain their configuration when migrated to V15+. Always delete the instance DBs of COMM_LOAD and MB_MASTER before re-instantiating, otherwise stale MODE = 0 or MODE = 1 values from a previous RS-232 project will persist.

4. The Root Cause: COMM_LOAD MODE ≠ 4

Every PtP communication sequence on the S7-1200 requires two blocks in a strict order:

1. COMM_LOAD (formerly MB_COMM_LOAD) — configures the CM 1241 hardware interface, baud rate, parity, flow control, and crucially the MODE value. The block is a one-shot: it must be executed exactly once on CPU cold start, usually in OB100 (warm restart) or the first scan of OB1 with a positive-edge REQ trigger.
2. MB_MASTER — performs the Modbus RTU transactions. It must not be called until COMM_LOAD.DONE = TRUE and COMM_LOAD.ERROR = FALSE.

If COMM_LOAD is called with REQ and completes successfully (DONE = TRUE, ERROR = FALSE, STATUS = 0), the CM 1241 is armed and ready. If MB_MASTER is then called and the bus shows only 0x00 bytes, the issue is one of the following, in order of probability:

5. Step-by-Step Repair Procedure

Execute these steps in order. Do not skip the verification block at the end of each step.

Step 5.1 — Open the Project in TIA Portal

1. Open the project that previously worked with the pressure sensor.
2. Open the device configuration of the S7-1200 station and confirm the CM 1241 is in slot 101 of the PLC with the correct MLFB.
3. Right-click the CM 1241 → Properties → Port configuration. Set the baud rate, parity, and stop bits to match the pressure sensor. For a typical 9600 8N1 sensor, leave the defaults.
4. Under Hardware identifier, note the value. It will be a hex constant such as 271 (decimal 625). This is the HW_ID input of COMM_LOAD.

Step 5.2 — Open the Instance DB of COMM_LOAD

1. Navigate to the program block that contains COMM_LOAD (often OB1 or a dedicated init FB).
2. Right-click the MODE input tag → Go to tag or open the instance DB directly.
3. Verify MODE = 4 (decimal) for any RS-485 CM 1241 module.

Step 5.3 — Force-Cold-Start the Project

1. Perform a full download of the project, not a delta download. TIA Portal may otherwise skip the instance DB if its interface signature is unchanged.
2. After download, power-cycle the S7-1200 (MRES is not required, but a clean power cycle ensures the instance DBs are re-initialised).
3. Monitor the instance DB of COMM_LOAD online. DONE should transition to TRUE within one PLC cycle, and STATUS should equal 0.

Step 5.4 — Verify COMM_LOAD Status Online

Connect online to the PLC, open the COMM_LOAD instance DB in monitor mode, and check the following tags:

Step 5.5 — Trigger MB_MASTER After COMM_LOAD is DONE

Wire MB_MASTER with the following minimum parameters:

// MB_MASTER call parameters (example for a 9600 8N1 pressure sensor, slave ID 1)
MB_MASTER_DB.MODE       := 0;                  // 0 = Modbus RTU
MB_MASTER_DB.SLAVE      := 1;                  // Slave address 1
MB_MASTER_DB.FUNCTION   := 3;                  // Read Holding Registers
MB_MASTER_DB.DATA_ADDR  := 0;                  // Starting Modbus register 40001
MB_MASTER_DB.DATA_LEN   := 2;                  // Read 2 registers (16-bit pressure + status)
MB_MASTER_DB.DATA_PTR   := P#DB20.DBX0.0 WORD 2; // Pointer to a 2-word data buffer in DB20
MB_MASTER_DB.REQ        := _Trigger;           // Rising-edge trigger, NOT level
MB_MASTER_DB.BUSY       := _Busy;              // Latched while transaction in progress
MB_MASTER_DB.DONE       := _Done;              // One-cycle pulse on success
MB_MASTER_DB.ERROR       := _Error;             // One-cycle pulse on failure
MB_MASTER_DB.STATUS     := _Status;            // 0 on success, error code on failure

6. RS-485 Wiring and Polarity

Siemens uses non-standard A/B pin naming on the CM 1241. This is the most common installation error in the field and is worth verifying before any software change.

Siemens' T/R+ corresponds to the generic D+ signal. The bus will function with either polarity, but if a half-duplex device is on the same bus with a third-party master, the polarity conventions may collide. Confirm with a multimeter: between T/R+ and T/R- the bus should idle at ≥ +200 mV differential on a healthy RS-485 segment terminated with 120 Ω at both ends.

Termination: the CM 1241 does not include internal termination resistors. For a 9600 bit/s link under 10 m, no termination is required. For 115.2 kbit/s or cable runs above 10 m, add a 120 Ω resistor between T/R+ and T/R- at both ends of the bus, and a 680 Ω pull-up to +5V on T/R+ and a 680 Ω pull-down to GND on T/R- at exactly one point on the bus. Many third-party pressure sensors have DIP switches for these resistors.

7. Freeport vs. Modbus: Why You Cannot Mix MODE Values

A common misconception is that MODE controls only the electrical standard. In reality, MODE also selects the framing protocol interpreted by the firmware. The valid combinations are:

Selecting MODE = 0 on an RS-485 module tells the firmware to use the RS-232 line driver. The RS-485 line driver, however, is the only one physically wired to the bus pins. The result is a configuration race: the firmware is shifting out Modbus bytes through the wrong driver, and the line driver is held in receive-only mode. The bus idles at 0x00.

8. Common COMM_LOAD and MB_MASTER Error Codes

After applying the fix, monitor the STATUS outputs in online mode. The following codes are the most frequently encountered on CM 1241 Modbus links:

Modbus exception codes reported in the first byte of the data buffer when STATUS = 16#8184:

9. Verification Procedure

After applying the MODE = 4 fix and re-downloading, perform the following three-level verification. Do not declare the link healthy until all three pass.

9.1 LED Verification

The CM 1241 RS-485 has a single bi-colour LED per port. Observe it with the project running and a Modbus REQ pulse active:

9.2 Online STATUS Verification

With the PLC online, force REQ on MB_MASTER via a watch table. Confirm:

1. COMM_LOAD.STATUS = 16#0000
2. MB_MASTER.DONE = TRUE on the cycle following the trigger
3. MB_MASTER.ERROR = FALSE
4. The data buffer at DATA_PTR contains the expected sensor value

9.3 Bus-Side Verification

Connect a USB-RS485 adapter to the bus (temporarily disconnect the CM1241 to avoid contention, or use a 3-port RS-485 tap with appropriate impedance). Run Modbus Poll or QModMaster and issue a Read Holding Registers request to the slave address. The sensor should respond identically to the CM1241 query — proving the slave and cable are good. Then reconnect the CM1241 and confirm the PLC receives the same data.

10. Avoiding the 0x00 Flood in the Future

Three engineering practices will eliminate the recurrence of this specific failure mode on any S7-1200 / CM1241 site:

1. Standardise the project template. Build a master project with the correct MODE = 4 baked into the COMM_LOAD instance DB. Any project cloned from this template inherits the correct value. Mark the MODE tag with a comment such as // 4 = RS-485, do not change without verifying module type.
2. Make COMM_LOAD execution mandatory in OB100. Use the warm-restart OB to call COMM_LOAD with a latched REQ and a watchdog timer that flags a station if DONE is not TRUE within 5 seconds of power-up. This protects against the case where the OB is later removed during a code cleanup.
3. Use a one-shot trigger for MB_MASTER. Never drive MB_MASTER.REQ with a level signal. Latch it with a rising-edge detector and verify that BUSY transitions to FALSE and back to TRUE for each transaction. A level-driven REQ on a mis-configured CM1241 produces the 0x00 flood exactly once per second, which is the symptom reported in the original incident.

11. Extended Diagnostics: When MODE = 4 Still Fails

If the MODE parameter is correct and the bus is still silent or still transmitting 0x00, escalate to the following diagnostics in order:

12. Frequently Asked Questions