Resolving 16#8070 MB_MASTER Errors on S7-1200 CM 1241

Problem Description

On a SIMATIC S7-1200 CPU communicating through a CM 1241 RS422/RS485 communication module, engineers frequently encounter Modbus RTU error code 16#8070 when scaling the polling list past a single-digit number of slaves. The classic symptom pattern is reproducible:

• Slaves at addresses 1 through 7 respond correctly and return valid data.
• Slaves at addresses 8, 9, 10 — and any slave polled by an additional MB_MASTER instance — transition to STATUS = 16#8070.
• Removing the eleventh MB_MASTER instance makes the error disappear, restoring correct operation of the remaining ten.
• CPU diagnostic buffer shows the work memory at roughly 30% used and load memory at 9% used — well below the resource ceiling.

The condition is independent of the 32-device physical limit of the RS-485 bus. The fault is software-side, not electrical, and originates inside the MB_MASTER instruction instance itself.

Decoding Error Code 16#8070

16#8070 in the MB_MASTER.DONE / MB_MASTER.ERROR status word is defined in the S7-1200 Modbus RTU instruction set as "All internal instance memories are in use". The instruction is attempting to claim a temporary internal buffer (used to hold the request frame, the response frame, and the timeout/retry state machine) and the runtime cannot allocate it.

Root Cause Analysis

The S7-1200 legacy Modbus RTU instruction set — MB_COMM_LOAD and MB_MASTER documented in the SIMATIC S7-1200 Manual Collection — is built around a single-master, single-channel design. Several architectural constraints are commonly violated when scaling past a small number of slaves:

Cause 1: Multiple MB_COMM_LOAD Instances on the Same Port

MB_COMM_LOAD is a one-time port-configuration block. It sets the baud rate, parity, stop bits, flow control, and RTS-on-delay/off-delay for the CM 1241 point-to-point port. Once it has executed, the port is configured and remains configured. Calling MB_COMM_LOAD a second time with different parameters re-initializes the port mid-transaction and can reset the internal state of an active MB_MASTER instance, causing the request queue to corrupt. Multiple MB_COMM_LOAD blocks on the same logical port is unsupported and is the most common trigger for the 11th-instance failure.

Cause 2: Multiple MB_MASTER Instances Triggered Simultaneously

The official Siemens documentation states explicitly: "Pre-emption of a Modbus master instruction by another Modbus master instruction in a higher priority execution priority level will result in improper operation." Each MB_MASTER instance holds an internal instance memory block. If two or more instances see a rising edge on REQ in the same OB1 scan, or if the OB priority is not identical, the runtime cannot arbitrate the shared port and returns 16#8070 for the loser. The CM 1241 driver has a fixed pool; once that pool is exhausted by overlapping calls, additional instances fail.

Cause 3: Timer-Based Polling Architecture

Polling every MB_MASTER on a cyclic timer (e.g., a 100 ms clock OB) guarantees that several instances raise REQ in the same scan. The instances are not synchronized to the actual response time of the slaves, so a slow slave causes its instance to remain BUSY when the next timer tick re-asserts REQ. The instruction drops the new request, the instance counter advances, and after a small number of slaves the pool is fully consumed.

Cause 4: Overlapping Instance DB Memory

When the calling function block is created with optimized block access, the instance data block layout is automatic; when it is non-optimized, the engineer controls the offsets. Two MB_MASTER instances inside the same FB with hand-laid offsets that share a work-word can corrupt the internal status word of one of them, surfacing as 16#8070 on the next rising edge.

Solution: Single MB_COMM_LOAD + Single MB_MASTER Multiplexer

The supported and field-proven pattern on S7-1200 with CM 1241 is a single MB_COMM_LOAD + single MB_MASTER with parameter multiplex. The master is asked to talk to a different slave on each cycle; the slave list is iterated by a sequencer. REQ is asserted only after the previous transaction reports DONE or ERROR.

Architecture Diagram

Implementation Pattern (SCL / Structured Text)

The REQ input of MB_MASTER is edge-sensitive. A rising edge starts a transaction; holding REQ high does not start another. Use a single rising-edge auxiliary bit that the sequencer raises only after a previous DONE or ERROR:

// FB "ModbusPoller" — call in OB1, single instance DB
VAR
    iSlaveIndex : INT;            // 0..N, points into aSlaveList
    xReqEdge    : BOOL;           // rising-edge helper
    xReqPrev    : BOOL;           // previous scan of REQ
    xBusy       : BOOL;
    xDone       : BOOL;
    xError      : BOOL;
    wStatus     : WORD;
    aSlaveList  : ARRAY[0..31] OF INT := [1,2,3,4,5,6,7,8,9,10,11,12];
END_VAR

// ---- Edge detect on REQ ----
IF NOT xReqPrev AND mb_master.DONE OR mb_master.ERROR THEN
    xReqEdge := TRUE;
END_IF;
xReqPrev := mb_master.DONE OR mb_master.ERROR;

// ---- Single MB_MASTER call, multiplexed ----
mb_master.REQ     := xReqEdge;
mb_master.MB_ADDR  := aSlaveList[iSlaveIndex];
mb_master.MODE     := MB_MODE_READ;     // or MB_MODE_WRITE per slave
mb_master.DATA_ADDR := 40001;            // remap per slave if needed
mb_master.DATA_LEN  := 10;
mb_master.DATA_PTR  := pSlaveData[iSlaveIndex];
mb_master();

xDone   := mb_master.DONE;
xError  := mb_master.ERROR;
wStatus := mb_master.STATUS;

// ---- Advance sequencer only on terminal state ----
IF xDone OR xError THEN
    xReqEdge := FALSE;
    IF xError AND wStatus = 16#8070 THEN
        // log and continue — do NOT block the sequencer
    END_IF;
    iSlaveIndex := (iSlaveIndex + 1) MOD (MAX_INDEX + 1);
END_IF;

Single MB_COMM_LOAD

Place exactly one MB_COMM_LOAD in the startup OB (OB100) or in OB1 with a one-shot firstScan flag. After it reports DONE = TRUE, the port is configured and the block should never be called again until the next CPU restart.

// OB100, cold restart
IF "FirstScan" THEN
    mb_comm_load.REQ       := TRUE;
    mb_comm_load.PORT      := 1;            // CM 1241 port identifier
    mb_comm_load.BAUD      := 9600;
    mb_comm_load.PARITY    := 0;            // 0=None, 1=Odd, 2=Even
    mb_comm_load.FLOW_CTRL := 0;            // 0=None for RS-485 2-wire
    mb_comm_load.RTS_ON_DLY := 0;
    mb_comm_load.RTS_OFF_DLY := 0;
    mb_comm_load();
    "FirstScan" := FALSE;
END_IF;

Ladder Equivalent

For engineers working in LAD rather than SCL, the equivalent structure is well documented in the legacy sample project shipped with early TIA Portal versions and accessible through the CM 1241 entry in the Siemens Online Support. The pattern uses a STEP counter that increments on MB_MASTER.DONE or MB_MASTER.ERROR, a SHR or move ladder that maps STEP to slave address, and an explicit reset of the REQ coil after each terminal state.

Holding Registers Past Address 125 (Related Failure Mode)

A second failure mode that often surfaces when scaling Modbus polling is reading registers above address 400125. The Modbus RTU function codes 0x03 (read holding) and 0x06 (write single) address a 16-bit offset, but a historical limitation in some masters restricted reads to ≤125 words per transaction. The S7-1200 MB_MASTER itself does not impose this limit on the slave address range — registers at 40601 are read by setting DATA_ADDR = 601 with MODE = MB_MODE_READ. The 125-word DATA_LEN ceiling is per-transaction, not per-slave. If a slave requires 600 contiguous registers, split the request into multiple transactions across the sequencer rather than exceeding DATA_LEN.

Verification Procedure

1. Open TIA Portal, compile the project, and download to the CPU. Confirm the CM 1241 is in RUN and that the port LED shows activity when a slave is polled.
2. Open Online & Diagnostics → Diagnostics buffer. Verify no 16#8070 entries are added as the sequencer cycles through all slaves.
3. Place a watch table on the MB_MASTER.STATUS word. Expected values during healthy operation: 16#0000 idle, 16#7001 or 16#7002 while a request is in flight, then back to 16#0000 after a successful DONE.
4. Force the sequencer to address 11 (the previously failing index) by writing to iSlaveIndex. Confirm STATUS = 16#0000 and DONE = TRUE within the configured response timeout.
5. With a Modbus sniffer (e.g., a third-party RS-485 tap) confirm one and only one request frame is on the bus at any time. Frame spacing should match the configured RTS_OFF_DLY plus the slave response time.
6. Cycle the CPU power to confirm the single MB_COMM_LOAD in OB100 reinitialises the port cleanly on restart.

Workarounds If You Must Keep Multiple MB_MASTER Instances

There are cases where a sequencer is impractical (e.g., independent FB libraries per device, time-critical per-slave rate). In those cases, the following workarounds reduce — but do not eliminate — the risk of 16#8070:

Related Status Codes You Will See During Recovery

After moving to the single-master architecture, expect to see legitimate slave-side status codes that were previously masked by 16#8070. Recognising them is part of the fix:

• 16#82C8 — Slave response timeout. Confirm baud rate, parity, and that the slave address matches MB_ADDR.
• 16#82CA — CRC or framing error. Check termination, shielding, and the 2-wire A/B polarity.
• 16#8180 / 16#8181 — Modbus exception 02 (illegal data address) or 03 (illegal data value) from the slave.

Key Takeaways

• 16#8070 means local instance memory exhaustion, not a slave problem.
• Use one MB_COMM_LOAD and one MB_MASTER per CM 1241 port.
• Drive REQ from the DONE / ERROR state, not from a timer.
• Multiplex the slave address, mode, and data pointer through a sequencer.
• Validate with a Modbus sniffer that one — and only one — request is in flight at a time.