S7-1200 MB_MASTER Always Busy: Modbus RTU Troubleshooting Guide

When a Siemens SIMATIC S7-1200 CPU executes an MB_MASTER instruction against a Modbus RTU slave (such as a temperature transmitter) and the block output remains permanently in the BUSY state with no transition to DONE or ERROR, the PLC program is generally not receiving a valid response from the serial line. The instruction is not "stuck" in the sense of a software deadlock; it is waiting for a response frame that never arrives or is corrupted at the physical layer. The most common causes on S7-1200 systems using a CB 1241 RS485 communication module are: (1) overlapping memory addresses between the master instruction's MODE, DATA_ADDR, DATA_LEN, DATA_PTR operands and unrelated tags in the user program; (2) incorrect REQ edge-handling logic; (3) mismatched serial parameters between master and slave; and (4) wiring, termination, or RS485 polarity faults. This guide walks through each of these layers, in the order that a field engineer should check them, with concrete parameter tables, ladder logic, and commissioning checks.

1. How the MB_MASTER State Machine Behaves

Per the Siemens legacy Modbus RTU instruction reference, MB_MASTER is a non-blocking, asynchronous instruction. On every PLC scan in which its EN input is TRUE and the REQ input detects a rising edge, the instruction copies its configuration operands (slave address, function code, starting address, length) into the point-to-point (PtP) transmit buffer of the underlying serial module and sets the BUSY output. The instruction then yields and waits for the serial port to:

1. Transmit the constructed Modbus RTU ADU (address byte, function code, payload, CRC16).
2. Release the bus for the 3.5 character inter-frame silence.
3. Receive a valid response from the addressed slave within the configured response timeout.
4. Validate the response CRC and copy the payload to DATA_PTR.

If step 3 or 4 fails, MB_MASTER raises the ERROR output and writes a non-zero status code to the STATUS output. If the slave does not respond at all (no bytes received on the RX line), most firmware versions leave BUSY = 1 until either a response arrives or a higher-priority error path (timeout, parity, framing) is triggered by the underlying PtP driver. A permanently set BUSY bit with no ERROR almost always indicates a physical-layer problem: the request is going out, but no valid frame is being received back.

2. Root Cause #1 — Overlapping Memory Addresses

The single most common programming defect on S7-1200 Modbus RTU projects is treating the bit/byte/word/dword memory map as if it were address-orthogonal. S7-1200 tags declared as Bool, Byte, Word, and DWord all share the same underlying bit-addressable memory. A classic, documented example of this confusion is the addressing of Merker (M) flags:

Consequences relevant to MB_MASTER:

• Writing the 16-bit STATUS output to %MW2 overwrites the low byte of the DATA_PTR word if DATA_PTR is also %MW2 or %MW3. The slave's response bytes are silently corrupted on the way into your DB.
• Using M30.1 as a control bit elsewhere in the program while MB_MASTER's STATUS is parked at %MW30 causes bit M30.1 to flicker unpredictably because STATUS writes MW30 on every scan, which sets the underlying M30.0...M30.7 bits.
• Storing the 16-bit DATA_LEN operand at an address that overlaps the receive buffer pointer corrupts the length on the next transaction.

Audit every operand of MB_MASTER and MB_COMM_LOAD against the global symbol table. The rule is simple: no two operands of any size, on the same memory area, may share a single byte.

2.1 Recommended Address Reservation Scheme

Note that the BUSY/DONE/ERROR/STATUS cluster is intentionally placed in a separate Merker range (M200+) so that the program can copy it into a structured diagnostic DB (e.g. DB_Diagnostics) without further aliasing. The DATA_PTR should always point into a non-optimized data block; optimized (S7-1200 symbolic) DBs are not supported by the legacy Modbus RTU instructions.

3. Root Cause #2 — REQ Edge Logic and Polling

MB_MASTER only begins a transaction on a rising edge of REQ. If the user code drives REQ from a coil that is set TRUE and never reset, the first transaction is started, and subsequent transactions are not started until the next full PLC restart, or until the program explicitly toggles REQ. A common (and incorrect) pattern is to wire REQ to a normally-closed contact of BUSY or to a constant TRUE.

The correct polling pattern is a one-shot pulse generator that fires once after every DONE or ERROR:

// Ladder excerpt (TIA Portal, S7-1200)
Network 1: Request trigger
   "PollClock" (TON, 200 ms) .Q
   |---(P)----( S )--- "MB_MASTER_DB".REQ       // rising edge pulse, not level

Network 2: Self-reset on completion
   "MB_MASTER_DB".DONE  "MB_MASTER_DB".ERROR
   |---( )---+---( R )--- "PollClock".IN       // restart 200 ms cycle

Network 3: Capture diagnostic status
   "MB_MASTER_DB".ERROR  %M200.2
   |---[ ]---( MOVE )--- "DB_Diagnostics".StatusLast := %MW202

Equivalently in Structured Text (S7-1200 / TIA Portal V17+):

// FB_PollingModbus, written in SCL
IF (NOT busyLatch) AND cycleEnable THEN
    mbMaster.REQ := TRUE;          // rising edge, one shot
    busyLatch := TRUE;
END_IF;

IF mbMaster.DONE OR mbMaster.ERROR THEN
    mbMaster.REQ := FALSE;
    IF mbMaster.ERROR THEN
        lastStatus := mbMaster.STATUS;  // 16-bit fault code
    END_IF;
    busyLatch := FALSE;
    cycleEnable := FALSE;
    cycleTimer(IN := TRUE, PT := T#200ms);  // inter-request spacing
END_IF;

IF cycleTimer.Q THEN
    cycleTimer(IN := FALSE);
    cycleEnable := TRUE;
END_IF;

The inter-request spacing (200 ms in the example) is critical. The Modbus RTU specification requires a 3.5 character inter-frame silence at the configured baud rate. At 9600 8N1, one character time is roughly 1.04 ms, so the silent interval is approximately 3.5 ms. The user timer is a sanity check, not a substitute, and must always be greater than the calculated silent interval. If the timer is too short, the slave may not have released the bus when the next request fires, producing a partial overlap of frames and CRC errors that the master reports as a stuck BUSY on some firmware loads.

4. Root Cause #3 — Physical Layer (CB 1241 RS485)

The CB 1241 RS485 communication board is a half-duplex, 2-wire differential transceiver. The on-board LEDs are the engineer's first diagnostic:

4.1 CB 1241 Wiring Pinout

4.2 Termination Resistor

RS485 requires a 120 Ω termination resistor at each end of the bus, between A and B, ONLY if the bus length exceeds approximately 3 meters at high baud rates. The CB 1241 has an internal switchable 120 Ω terminator accessible through the device configuration in TIA Portal (CB 1241 properties → RS485 → Termination = ON). If the transmitter is at the far end and also has internal termination, enable both. If the bus is short (≤ 3 m) and both ends are not properly biased, leave the termination OFF to avoid overloading the drivers.

5. Root Cause #4 — MB_COMM_LOAD Configuration Mismatch

MB_COMM_LOAD is the one-time initialization block that programs the CB 1241 with the baud rate, parity, data bits, stop bits, flow control, and the Modbus RTU mode flag. It must be called exactly once per port, on cold start, with its REQ pulse triggered by the first scan or by a startup tag. Common defects:

• Calling MB_COMM_LOAD in OB1 with a constant REQ = TRUE rather than a one-shot. On some firmware loads this causes the port to be re-initialized every scan and locks the underlying UART.
• Configuring a baud rate the slave does not support (e.g. 38400 on a transmitter that only supports 9600 and 19200).
• Mismatched parity (PLC 8E1 vs. slave 8N1). A parity mismatch produces a framing error on every received byte, which the PtP driver reports as STATUS = 0x0007 in MB_MASTER, but only after at least one full timeout window has elapsed.

5.1 Reference Parameters for a 9600 8N1 Temperature Slave

Until MB_COMM_LOAD.DONE is TRUE, the port is not yet active and MB_MASTER will sit in BUSY. Always gate MB_MASTER's EN input on the MB_COMM_LOAD completion flag.

6. Root Cause #5 — Slave-Side Protocol and Address Mapping

A third-party Modbus RTU temperature transmitter (ESP-based modules, generic PT100 converters, industrial head transmitters) may report its process value at a holding register, an input register, or a discrete coil, depending on the manufacturer's design. If the master is reading a function code that the slave does not support for the requested address, the slave responds with an exception frame (function code + 0x80, exception code 1 = illegal function, or 2 = illegal data address). The master then sets ERROR = 1 and STATUS = 0x0001 (or similar). However, if the slave is in a half-implemented state (e.g. a custom ESP firmware that does not write to the Modbus library's response buffer), the master will simply see no reply and stay BUSY.

6.1 Common Modbus Function Codes for Temperature

For a temperature reading, function code 04 (Read Input Registers) at address 0x0000 is the most common. In the S7-1200 MB_MASTER block, this is MODE = 4 and DATA_ADDR = the Modbus address + 1 in some vendor conventions, or the Modbus address verbatim in others. The official Siemens documentation for the legacy Modbus RTU instructions states that DATA_ADDR uses the standard Modbus addressing (0-based), so a vendor datasheet that says "register 30001" should be entered as 0 (or 1 if the vendor is using 1-based user-visible addressing). Always cross-check by writing a known value to a known holding register first, and then reading it back with MODE = 3.

7. Step-by-Step Diagnostic Procedure

Follow this sequence exactly. Each step produces a verifiable yes/no result that points to the next layer to investigate.

1. Confirm MB_COMM_LOAD has finished. Watch MB_COMM_LOAD.DONE online in TIA Portal. If it is stuck at FALSE, the port is not initialized; check BAUD, PARITY, FLOW_CTRL, and the PORT hardware ID. Reference: CB 1241 manual.
2. Confirm MB_MASTER REQ edge fires. Add a "REQ fired" tag that latches on every rising edge of REQ. The latch should toggle once per polling period. If it is constant, your REQ logic is wrong (see §3).
3. Watch the TX LED on the CB 1241. It should blink once per polling period. If dark, the request is not leaving the PLC. If solid, the bus is stuck.
4. Watch the RX LED. A healthy round-trip with a responding slave shows TX blink followed by RX blink within the configured RESP_TO. If TX blinks but RX does not, jump to §4 (physical layer).
5. Loopback test on the CB 1241. Disconnect the field cable, install a 120 Ω resistor between A and B at the CB 1241 terminals, and short A to RX/TX-P, B to RX/TX-N. The driver cannot talk to itself, but you can verify that MB_MASTER reports ERROR with a sensible STATUS word (e.g. 0x0001 — no response) within RESP_TO. This proves the master side is working and the problem is downstream.
6. Attach a PC as a Modbus RTU slave. Use a tool such as "Modbus Poll" or "Modbus Slave" (by Witte Software), or any open-source equivalent, connected via a USB-to-RS485 adapter. Match baud, parity, stop bits, and slave address exactly. If the PLC can read a known value from the PC, the field slave (or its wiring) is at fault.
7. Capture the line with a USB logic analyzer or scope. Trigger on the TX edge, then look for a slave response 4–30 ms later (depending on the slave's processing time). Verify the response's CRC16 with an online Modbus RTU frame calculator.
8. Verify the slave is actually a Modbus RTU device. Some sensors advertise "Modbus" but ship from the factory as Modbus ASCII, or as a proprietary protocol. The first byte of any valid Modbus RTU response is the slave address (1–247); ASCII responses start with a colon (0x3A).

8. Common MB_MASTER STATUS Codes

The 16-bit STATUS word carries the lower-level error from the PtP driver. The most relevant values when BUSY never clears:

Always latch the most recent STATUS into a non-volatile tag (or a retentive DB) so that a fast-changing code is not lost between scan cycles.

9. Resolution Summary by Symptom

10. Verification and Commissioning Tests

After applying any of the fixes above, run the following verification sequence to prove that the link is healthy:

1. Cold start test. Power-cycle the PLC. Confirm MB_COMM_LOAD.DONE = TRUE within the first scan after OB100 completes. Confirm MB_MASTER.BUSY pulses to TRUE then back to FALSE within one polling period.
2. Round-trip latency. Time the interval from REQ rising edge to DONE rising edge. For a single-register read at 9600 baud, this should be 20–50 ms depending on slave response time. A value consistently above 200 ms indicates intermittent retries.
3. Error budget. Monitor ERROR over 1000 transactions. A healthy link has zero errors. Anything above 1% is unacceptable for process control.
4. Data integrity. Read the same register 100 times and compare. Bit-for-bit equality is the expected result. If the lower 4 bits flicker, the bus has ground potential issues.
5. Stress test. Disconnect and reconnect the field cable three times. The master should report ERROR (with a status indicating no response) and then recover automatically on the next polling cycle without a PLC restart.

11. Preventive Best Practices

• Reserve a dedicated Merker range for every MB_MASTER and MB_COMM_LOAD instance. Document the offsets in a project-wide "communication map" DB. Never reuse these addresses for any other purpose.
• Always use a non-optimized (standard) data block for the receive buffer. Optimized DBs strip the absolute byte offset that the legacy MB_MASTER instruction requires.
• Use the System Clock bit (e.g. Clock_1Hz) as the polling trigger for low-speed process variables such as temperature, scaled to a longer period (e.g. Clock_10s for ambient monitoring).
• Place the CB 1241 at the beginning of the backplane bus, not at the end, to minimize the distance to the CPU and reduce the risk of communication-port addressing confusion when multiple CMs are installed.
• Use a dedicated 24 VDC power supply for the Modbus bus, separated from any variable-frequency drive DC bus. VFDs inject common-mode noise that destroys Modbus RTU frames at long cable runs.
• Document the slave's register map in the PLC project, including the function code, register type, scaling, and units. A single source of truth prevents the "0x0002 illegal data address" problem when multiple engineers modify the master.

12. Field-Proven Diagnostic Flowchart

Use the following decision tree when the symptom is "MB_MASTER.BUSY = 1 permanently, no ERROR":

MB_MASTER.BUSY = 1 forever?
        |
        +-- YES --> MB_COMM_LOAD.DONE = 1?
        |               |
        |               +-- NO  --> Check BAUD/PARITY/PORT; fix MB_COMM_LOAD
        |               +-- YES --> REQ rising edge firing?
        |                               |
        |                               +-- NO  --> Replace constant REQ with one-shot
        |                               +-- YES --> TX LED blinks per poll?
        |                                               |
        |                                               +-- NO  --> MB_MASTER not reaching port
        |                                               +-- YES --> RX LED blinks?
        |                                                           |
        |                                                           +-- NO  --> Physical layer:
        |                                                           |           - A/B swap
        |                                                           |           - missing GND
        |                                                           |           - slave not powered
        |                                                           |           - slave address mismatch
        |                                                           +-- YES --> Frame structure:
        |                                                                       - baud mismatch
        |                                                                       - parity mismatch
        |                                                                       - CRC error (EMI)
        |
        +-- NO --> Normal operation; revisit polling period

FAQ