CM 1241 Modbus RTU: Resolving 8200 Error with Multiple Slaves

Problem Overview

Engineers integrating a CM 1241 RS485 communication module into a SIMATIC S7-1200 CPU running Modbus RTU frequently encounter two related symptoms when scaling from a single-slave test bench to a multi-slave bus. The first symptom is that the on-board Tx and Rx LEDs of the CM 1241 blink at approximately 1 Hz while the MB_MASTER instruction never updates the DATA_PTR receive buffer. The second symptom, which appears once the bus is brought up, is that the MB_MASTER_DB.STATUS word returns 8200 cyclically when more than one slave is attached, and a parallel MB_CLIENT (or a second MB_MASTER) call returns 8220 indicating that a new request was issued before the previous transaction completed. This article documents the root causes, the proper interpretation of the S7-1200 status LEDs, the RS485 termination and topology rules that govern the bus, and the DONE/ERROR-driven polling pattern that resolves both symptoms in TIA Portal V17 and S7-1200 firmware 4.x and later.

CM 1241 RS485 Module and Instruction Set

The CM 1241 RS485 is a left-side expansion module that adds an isolated serial interface to a SIMATIC S7-1200 CPU. It is configured in the TIA Portal device view under Properties > Port configuration, where the engineer selects the protocol (Modbus RTU master, Modbus RTU slave, or Freeport), the baud rate, parity, data bits, and stop bits. Every change to the port configuration requires a project download and a power cycle of the module before the new parameters take effect, which is a common reason an apparently correct configuration appears not to be in force during commissioning. The module is supported by the S7-1200 instruction libraries installed with TIA Portal; the relevant Modbus instructions are MB_MASTER, MB_SLAVE, MB_CLIENT, and MB_SERVER.

For Modbus RTU master operation, the canonical instructions are MB_MASTER (the legacy master) and MB_CLIENT (the successor introduced in TIA Portal V14 SP1 and required for S7-1200 firmware 4.2 and later). Both instructions share a common output convention: DONE and ERROR are pulse outputs that are set for one scan when the transaction completes, BUSY indicates an active transaction, and STATUS returns a 16-bit word that combines a class identifier in the high byte with a detail code in the low byte. The application code must treat DONE, ERROR, and BUSY as dynamic outputs - that is, the values are only valid on the same scan that they are read, and they must be latched in a static flag if the application logic needs to evaluate them across multiple scans.

MB_MASTER and MB_CLIENT Parameter Summary

CM 1241 and S7-1200 Status LED Reference

Before chasing any Modbus fault, the on-board LEDs of the S7-1200 CPU and the CM 1241 must be read. The official Siemens S7-1200 documentation describes the LED states for the STOP/RUN, ERROR, MAINT, LINK, Rx, and Tx indicators. The relevant excerpt from the online help is reproduced in the table below. The Rx and Tx LEDs of the CM 1241 are located next to the D-sub connector and reflect the differential activity on pins 3 (B/B') and 8 (A/A') of the PROFIBUS connector.

The official Siemens reference is available at S7-1200 Status LEDs - Online and Diagnostic Tools. Per the Siemens manual, "Flashing red indicates an error, such as an internal error in the CPU, an error with the memory card, or ..." - the full enumeration is in the linked page.

Symptom Analysis: Rx/Tx Flashing at 1 Hz with Empty DATA_PTR

The classic case shows both LEDs of the CM 1241 blinking at exactly 1 Hz while the DATA_PTR buffer is never updated. This pattern is diagnostic of one of three root causes, listed in order of frequency seen in field service:

1. Slave Not Responding Because of Address, Baud, or Parity Mismatch

The master is transmitting correctly, the bus is properly biased, the slave is powered and configured, but the slave's address, baud rate, or parity does not match the master's request. The slave simply does not drive the bus, the 3.5 character silence timer at the master expires, and MB_MASTER reports a no-response timeout. The Tx LED flashes for the duration of the request, and the Rx LED shows no activity other than the master's own echo. Verify that the slave address in the MB_MASTER.MB_ADDR parameter matches the slave's DIP switch or configuration register, and that both ends use identical serial parameters.

2. RS485 Echo Due to Missing or Misplaced Termination

RS485 is a half-duplex multi-drop bus. The transmitter of the master and the addressed slave are both driving the differential pair during the request, and after the last byte of the master's frame the master must tri-state its transmitter to allow the slave to respond. If the bus is not terminated with 120 Ω at each physical end, the high-to-low edges of the master's last byte reflect back from the open end of the cable and re-trigger the master's receiver. The MB_MASTER instruction discards these echo bytes because they fall inside the silence window before the slave's response, but the receiver still logs Rx activity, hence the 1 Hz flash. The fix is to install 120 Ω between pins 3 and 8 of the D-sub at both the master and the last slave, and to verify that no other termination resistor is in the middle of the bus.

3. A/B Polarity Reversed on the D-Sub

Siemens follows the PROFIBUS convention where pin 3 is B (the inverting line, also called D- in RS485 parlance) and pin 8 is A (the non-inverting line, also called D+). Some Modbus devices, particularly those from Asian vendors, use the EIA-485 convention where A is the inverting line. If the master's Tx LED flashes but no slave responds and the Rx LED also flashes 1 Hz, swap the A and B wires at the slave D-sub or at the master end - whichever the vendor specifies in the device's installation guide. Reversed polarity does not damage the hardware because RS485 is differential, but it will prevent any slave from decoding the request.

RS485 Bus Termination and Topology

A Modbus RTU bus over RS485 must follow a daisy-chain (linear bus) topology. The maximum stub length depends on the baud rate, but the practical rule is that the entire chain length should not exceed 1200 m at 9600 baud. The two physical ends of the daisy chain must each be terminated with a 120 Ω resistor across the A and B conductors. The PROFIBUS D-sub connector used in the source case is a common way to switch this resistor in or out; the switch on the connector body toggles the termination. Only the two end connectors must have the switch set to ON - all intermediate connectors must be OFF.

The PROFIBUS connector at the master end has a switch that inserts 120 Ω across pins 3 and 8 when set to ON. The 120 Ω at the slave end is typically a switch on the slave's D-sub connector or a screw-terminal resistor that the installer mounts across the A and B terminals. If only one termination is in place, the bus will ring; if more than two are in place, the bus will be over-damped and may show rising-edge distortion. Verify with an ohmmeter across A and B with the master and all slaves powered off: the reading should be 60 Ω (two 120 Ω in parallel) at the master end of the cable, not 120 Ω and not 40 Ω.

Decoding MB_MASTER STATUS 8200

The STATUS output of MB_MASTER is a 16-bit word. In TIA Portal's online help the high byte identifies the error class and the low byte the detail code. Status 8200 decimal equals 0x2008 hex. The most common field interpretation is that 8200 is returned when the master has issued a request to a slave that is not present on the bus, or when the slave's address is set to a value that does not match the master's MB_ADDR parameter. The CM 1241 driver increments a no-response counter internally and returns 8200 on the next call cycle. Note: the exact class/detail decoding should be confirmed against the help context for the specific instruction version in the project; Siemens revises the class assignments between TIA Portal releases.

In the source case, the engineer reports that "data receiving for both slave according to RESP_TIME" - meaning the slave IS responding and DATA_PTR is being filled - but the STATUS word still returns 8200 every two to three seconds. The most likely explanation is that the master's poll cycle for the second slave is overlapping with the first slave's response window, and the MB_MASTER instruction times out waiting for the second slave's response because the bus is still busy. The fix is not in the slave configuration; it is in the application-level sequencing of the REQ inputs.

Per Siemens' official Modbus instruction documentation, the STATUS word follows the structure documented in the Modbus RTU master section of the TIA Portal help. The exact bit-field assignments may change between TIA Portal versions; consult the help context for the specific instruction version in the project to confirm.

Decoding MB_MASTER STATUS 8220: Request Collision Mechanism

Status 8220 (0x201C) in MB_MASTER and the equivalent error reported by MB_CLIENT means that REQ was re-triggered before the previous transaction completed. The Siemens instruction internally maintains a busy flag that is set when the request is dispatched to the CM 1241 driver and cleared when the response has been received and decoded. If the application code sets REQ to TRUE while the busy flag is still set, the instruction immediately aborts the previous frame, returns ERROR = TRUE, and writes 8220 to STATUS.

The root cause in a multi-slave application is almost always a free-running clock driving REQ. Consider a 1 Hz cyclic interrupt OB that drives the REQ input of two MB_MASTER instances, one per slave. The 1 Hz OB fires every 1000 ms, but the MB_MASTER instance can take 100-300 ms to complete a request at 9600 baud (depending on the number of registers being read). If the second OB cycle fires while the first instance is still in its response window, the first instance is forced to abort, returns 8220, and the data already received in DATA_PTR is discarded.

The fix is to drive REQ from the DONE/ERROR output of the previous instance, not from a clock. The 1 Hz clock is then used as a tick to start the first instance, and the DONE/ERROR chain handles the rest. This is described in the Siemens application example Modbus RTU Master with S7-1200 and is the canonical pattern for multi-slave polling.

Sequencer State Machine

The cleanest implementation is a state machine that holds the active slave ID, the active MB_MASTER instance, and a waiting for completion flag. The state machine advances to the next state on the rising edge of DONE or ERROR of the current instance. This guarantees that REQ is never raised while BUSY is TRUE.

1. State 0 (Idle): Wait for the 1 Hz tick. On tick, transition to State 1 and raise REQ of MB_MASTER #1.
2. State 1 (Slave 1): Wait for DONE or ERROR of MB_MASTER #1. On either edge, capture STATUS, clear REQ, and transition to State 2.
3. State 2 (Slave 2): Wait for DONE or ERROR of MB_MASTER #2. On either edge, capture STATUS, clear REQ, and transition to State 0.
4. State 3 (Error): Optional - if ERROR was reported, log the STATUS word to a data block and either retry or escalate an alarm.

Multi-Slave Polling Architecture

There are three common patterns for polling multiple Modbus RTU slaves from a single S7-1200 CM 1241. Each has trade-offs in terms of code complexity, scan time, and resilience to single-slave faults.

Option A: One MB_MASTER Instance Per Slave (Recommended)

Instantiate MB_MASTER once for each slave. Each instance is in its own instance DB (or as a multi-instance inside a parent FB). Each instance has its own REQ input, its own DATA_PTR pointing to a dedicated data block region, and its own RESP_TIME measurement. The application code drives REQ from a sequencer that waits for DONE/ERROR. This is the pattern recommended by Siemens and is the most resilient because a fault on one slave does not block the other slaves.

Advantages: clear separation of concerns, easy to add/remove slaves, fault on one slave does not stop polling of the others. Disadvantages: more instance DBs in the project, slightly higher scan time per cycle.

Option B: One MB_MASTER Instance, Sequential Slave IDs

Use a single MB_MASTER instance and change MB_ADDR between requests to walk the slave list. This requires a more complex sequencer because the MB_ADDR parameter must be written before REQ is raised, and the DATA_PTR must be reassigned to the correct region for the new slave. The MB_MASTER instance can be either in a global instance DB or inside a parent FB that is called once per scan.

Advantages: single instance DB, lowest memory overhead. Disadvantages: more complex code, more state to manage, single point of failure for the entire bus.

Option C: MB_CLIENT for S7-1200 Firmware 4.2+

For S7-1200 CPUs running firmware 4.2 or higher (TIA Portal V14 SP1 onward), MB_CLIENT is the recommended master instruction. MB_CLIENT has the same DONE/ERROR/BUSY semantics as MB_MASTER but adds a CONNECT parameter that holds the connection descriptor. For serial CM 1241 communication, the CONNECT parameter is set to a TCON_SERIAL_V4 structure that contains the port name, baud, parity, and the CM 1241 hardware identifier. The sequencer pattern is identical to Option A.

Advantages: future-proof, supports both serial and Ethernet partners with the same instruction, supports MB_CLIENT over TSEND/TRCV bridge. Disadvantages: requires firmware 4.2 or higher, requires careful configuration of the CONNECT pointer.

MB_CLIENT Output Behavior

The MB_CLIENT instruction (and MB_MASTER) reports its outputs as dynamic signals. Per the Siemens TIA Portal help, the outputs are displayed dynamically - they are updated only on the transition of REQ. This means that DONE, ERROR, BUSY, and STATUS are only valid for the scan in which they are read; on the next scan, BUSY may be FALSE because the instruction has completed and the CPU's online view has cleared the value. To use these signals in application logic that spans multiple scans, the application code must capture them in static flags (M-bits or DB tags) on the same scan they are read.

The standard capture pattern in SCL is:

// In OB1 - capture dynamic outputs to static flags
"Busy_Capture"   := "MB_MASTER_1_DB".Busy;
"Done_Capture"   := "MB_MASTER_1_DB".Done;
"Error_Capture"  := "MB_MASTER_1_DB".Error;
"Status_Capture" := "MB_MASTER_1_DB".Status;

Alternatively, the MB_MASTER or MB_CLIENT can be called inside a parent FB that processes the outputs on the same scan:

// In a parent FB that wraps MB_MASTER for slave #1
"MB_MASTER_1_DB".REQ       := #Start_Trigger;
"MB_MASTER_1_DB".MB_ADDR   := 1;
"MB_MASTER_1_DB".MODE      := 3;       // Read Holding Registers
"MB_MASTER_1_DB".DATA_ADDR := 0;
"MB_MASTER_1_DB".DATA_LEN  := 10;
"MB_MASTER_1_DB".DATA_PTR  := "Slave1_Data".Holding;

IF "MB_MASTER_1_DB".Done THEN
   #State := 2;                          // Advance to slave 2
   "MB_MASTER_1_DB".REQ := FALSE;
END_IF;

IF "MB_MASTER_1_DB".Error THEN
   #Last_Error := "MB_MASTER_1_DB".Status;
   #State := 2;
   "MB_MASTER_1_DB".REQ := FALSE;
END_IF;

The DONE and ERROR outputs are TRUE for exactly one scan when the transaction completes. The application's sequencer must read them on the same scan and then set REQ back to FALSE to prevent the next REQ edge from being interpreted as a new request.

Step-by-Step Resolution Procedure

Apply the following steps in order. Verify after each step before proceeding to the next. Do not skip steps - the symptoms in the source case are typically caused by a combination of factors, and a partial fix will leave residual errors.

1. Verify the physical bus topology. Power off the master and all slaves. Measure resistance across A and B at the master D-sub. The reading should be 60 Ω (two 120 Ω resistors in parallel). If the reading is OL, 120 Ω, or 40 Ω, re-terminate the bus.

2. Verify the A/B polarity at each slave. Consult the slave vendor's manual for the assignment of A and B. Siemens uses pin 3 = B, pin 8 = A on the PROFIBUS D-sub. If the slave uses the opposite convention, swap the wires at the slave end or use a crossover cable.

3. Verify the serial parameters match between master and slaves. Open the TIA Portal device configuration for the CM 1241 and confirm baud rate, parity, data bits, and stop bits. Open the slave's configuration tool and confirm the same. A typical Modbus RTU configuration is 19200 8E1 or 9600 8N1.

4. Confirm the slave address. Set the first slave to address 1 and verify with a Modbus scanner tool (such as the Modbus Poll utility or a CAS Modbus Scanner) that the slave responds to a read-holding-registers request. If the slave responds, the bus is healthy.

5. Add the second slave on a unique address. Set the second slave to address 2 and confirm with the scanner that both slaves respond independently.

6. Replace the free-running clock with a DONE/ERROR-driven sequencer. In the application code, remove the direct connection from the 1 Hz clock to the REQ input of the MB_MASTER instance. Add a state machine that raises REQ only when BUSY = FALSE and DONE/ERROR has been captured from the previous request.

7. Capture MB_MASTER outputs to static flags on the same scan. Use the pattern shown in the previous section. Do not rely on the online display of DONE/ERROR - capture them in M-bits or DB tags immediately after the MB_MASTER call.

8. Verify RESP_TIME for each slave. After the sequencer has run for at least one full cycle, monitor the RESP_TIME output of each MB_MASTER instance. The value should be stable and reflect the round-trip time at the configured baud rate. For 10 holding registers at 9600 baud 8N1, expect a RESP_TIME of 30-50 ms.

9. Monitor STATUS over a full polling cycle. With a 1 Hz tick and three slaves, expect 3 successful transactions per second with STATUS = 0 and zero 8220/8200 reports over a 60-second observation window.

Verification and Commissioning Checklist

Frequently Asked Questions