S7-1200 Modbus RTU Master Communication: MB_MASTER Setup Guide

Overview

The SIMATIC S7-1200 PLC integrates Modbus RTU master and slave capability through the MODBUS_RTU library distributed with STEP 7 (TIA Portal). This guide consolidates the documented procedure for establishing Modbus RTU communication between an S7-1200 CPU and one or more third-party AC drives (VFDs), including the CM 1241 RS485 communication module, the RS485 communications board (CB 1241), the MB_COMM_LOAD and MB_MASTER instructions, data block layout, and a deterministic sequential polling pattern.

The MODBUS-RTU reference project (entry ID 47756141) is the canonical Siemens example for this topology. The same description PDF documents the maximum hardware expansion: up to three CM 1241 communication modules plus one CB 1241 RS485 communications board per S7-1200 CPU.

Prerequisites

Hardware Configuration and Topology

The S7-1200 supports Modbus RTU on two physical interfaces: the plug-in CB 1241 RS485 board mounted directly to the CPU, and one or more CM 1241 RS485 communication modules on the left-side bus. Each physical port requires a single instance of MB_COMM_LOAD to configure baud rate, parity, data bits, stop bits, and flow control, and a single instance of MB_MASTER to issue transactions. The hardware identifier assigned by TIA Portal to the CM/CB port must be supplied to the HW_ID input of MB_COMM_LOAD — this is the most common configuration error on first-time setup.

RS485 bus topology for Modbus RTU:

• Two-wire (half-duplex) daisy chain with termination resistors (typically 120 Ω) enabled at both physical ends of the trunk.
• Shielded twisted pair, shield grounded at one end only.
• Maximum of 32 unit loads per segment without repeater; most modern VFDs present 1/8 unit load.
• CM 1241 RS485 ships with a termination resistor that can be engaged via the on-board slide switch.

Firmware Considerations

S7-1200 CPUs shipped with early production firmware (notably the Starter Kit CPUs with firmware 1.0.0) exhibited documented communication issues affecting both Modbus TCP and RS485-based protocols. The relevant fix points were:

For any production deployment or new commissioning, use the latest firmware available for the specific CPU order number. Firmware updates are performed via TIA Portal using a SIMATIC Memory Card or via the Web Server (where supported). Always back up the project before performing a firmware update.

Installing the Modbus RTU Library

1. Open the TIA Portal project and switch to the project library view (right pane: Libraries tab).
2. Import the MODBUS_RTU library shipped with STEP 7. In TIA Portal V11/V12 the library is named MODBUS_RTU (version 1.x). In TIA Portal V13 and later the successor library Modbus_Com_Load / Modbus_Master is provided as a global library.
3. Drag the master folder (MB_MASTER, MB_COMM_LOAD, and associated data types) into the project tree under Program Blocks > System Blocks.
4. Confirm the block versions are compatible with the target CPU firmware. TIA Portal flags version mismatches during compilation.

MB_COMM_LOAD — Port Initialization

MB_COMM_LOAD is called once (or once per port change) to set the serial parameters and arm the port. It is edge-triggered on REQ and writes a DONE, ERROR, and STATUS back to the instance DB. The block must finish successfully before MB_MASTER transactions will be accepted by the port.

For typical VFD integration, set RESP_TO to 1000 ms minimum and increase to 2000–3000 ms if the drive is slow to respond on heavy bus loading.

MB_MASTER — Transaction Engine

MB_MASTER is the workhorse instruction. It is also edge-triggered on REQ and arbitrates access to the port configured by MB_COMM_LOAD. A single MB_MASTER instance is sufficient for polling multiple slaves, because the block itself is sequential: each call completes (or times out) before the next call should be issued.

For reading drive parameters, MODE = 0 (read holding registers, function code 03) is the most common. For writing a single control word or frequency reference, MODE = 1 with function code 06 is typical. For multi-register writes (e.g., 16-bit control plus 16-bit reference packed into a 32-bit word), function code 16 is used and the data area must be set up as a 2-element array.

Data Block and Array Layout

Each MB_MASTER call writes the returned registers into a buffer pointed to by DATA_PTR. The cleanest pattern is a global DB containing one or more ARRAY [0..n] OF WORD regions — one per drive or per parameter group.

DATA_BLOCK "DriveData"
  STRUCT
    Drive1_Read : ARRAY[0..9] OF WORD;   // 10 holding registers from slave 1
    Drive1_Write : ARRAY[0..1] OF WORD;   // 2-word write buffer (control + reference)
    Drive2_Read : ARRAY[0..9] OF WORD;   // 10 holding registers from slave 2
    Drive2_Write : ARRAY[0..1] OF WORD;
    FaultWord   : WORD;                  // Status / fault mapping
  END_STRUCT;
END_DATA_BLOCK

The example project referenced in entry 47756141 uses an array structure similar to the above; the networks that copy the active slice into a per-drive workspace DB are the "shift register" pattern observed in the field report.

Sequential Polling — Shift Register Pattern

A single MB_MASTER can poll any number of slaves, but only one transaction at a time. The standard pattern uses a counter or step index to sequence transactions. The example project sequences 4 networks (4, 5, 7, 8 in the original listing) that each:

1. Load slave address and register pointer for a specific drive.
2. Set (latch) the request to MB_MASTER.REQ.
3. Wait for DONE or ERROR.
4. Reset the request, increment the step counter, and continue.

A compact ladder equivalent:

// Step sequencer (simplified ST)
IF MB_MASTER_1.DONE OR MB_MASTER_1.ERROR THEN
    MB_MASTER_1.REQ := FALSE;
    step := (step + 1) MOD NUM_STEPS;
END_IF;

CASE step OF
    0: // Read Drive 1 status
        MB_MASTER_1.MB_ADDR   := 1;
        MB_MASTER_1.MODE      := 0;
        MB_MASTER_1.DATA_ADDR := 0;
        MB_MASTER_1.DATA_LEN  := 10;
        MB_MASTER_1.DATA_PTR  := "DriveData".Drive1_Read;
        MB_MASTER_1.REQ       := TRUE;
    1: // Write Drive 1 control word + reference
        MB_MASTER_1.MB_ADDR   := 1;
        MB_MASTER_1.MODE      := 1;
        MB_MASTER_1.DATA_ADDR := 0;
        MB_MASTER_1.DATA_LEN  := 2;
        MB_MASTER_1.DATA_PTR  := "DriveData".Drive1_Write;
        MB_MASTER_1.REQ       := TRUE;
    2: // Read Drive 2 status
        ...
    3: // Write Drive 2 control word + reference
        ...
END_CASE;

The shift register / sequencer is preferable to multiple parallel MB_MASTER instances on the same port, because the Modbus RTU library arbitrates port access internally and parallel calls will queue or collide. A common cause of intermittent timeouts is exactly this: several MB_MASTER blocks driven from different OB1 scan cycles.

Wiring to Third-Party AC Drives

Most modern VFDs expose Modbus RTU on a two-wire RS485 terminal block, frequently labeled D+/D- or A+/B-. Polarity conventions vary by manufacturer; consult the drive manual before commissioning. Typical termination:

• CM 1241 RS485: T/R+ (pin 3) → drive D+ / A; T/R- (pin 8) → drive D- / B.
• Common (GND_REF) at pin 5 of the CM 1241 should be connected to the drive's logic ground where the drive manual permits; this reduces common-mode noise.
• Enable the on-board 120 Ω termination at the S7-1200 end (DIP switch on CM 1241) and at the last physical drive in the daisy chain. Disable termination on intermediate drives.

STATUS Code Reference

Both MB_COMM_LOAD and MB_MASTER return a 16-bit STATUS word. The high byte is the function class and the low byte is the detail. Common values encountered in commissioning:

Commissioning Verification

1. Watch table test. Create a watch table on the drive data DB. Manually write a value to Drive1_Write[0], trigger MB_MASTER with REQ = TRUE from a test OB, and confirm the drive's response register changes via the drive's keypad or its own Modbus master tool.
2. Loopback test. Disconnect the field cable and connect T/R+ to T/R- on the CM 1241 with a 120 Ω resistor across the pair. A read of the local echo confirms the port and library are functional independent of the drive.
3. Single-drive sanity. Connect only the first drive. Verify baud, parity, slave address. Confirm a holding register read returns the expected default value (often 0 or a status word).
4. Sequential polling test. Add the second drive. Watch the step counter and confirm transitions are clean and timeouts are absent. Add a 50 ms post-DONE delay if slave response is borderline.
5. Long-run test. Log ERROR and STATUS over 24 hours. A non-zero error count above ~0.1% of transactions typically indicates electrical noise, termination, or insufficient inter-character delay.

Troubleshooting Matrix

FAQ