S7-1200 Modbus RTU: Reading Non-Consecutive WEG CFW500 Registers

Problem Overview

An S7-1200 CPU (firmware V4.x or later) communicating over Modbus RTU through a CM 1241 or CB 1241 RS-485 communication module often hits a hard wall when a downstream device such as the WEG CFW500 Variable Frequency Drive (VFD) exposes non-consecutive parameter numbers. The PLC's MB_MASTER instruction is the documented Modbus RTU master block, and although it advertises a maximum payload of 125 holding registers, the read collapses entirely when the slave leaves even a single hole in the requested address range. The symptom is unmistakable: every destination word in the buffer is left untouched and MB_MASTER.DONE returns TRUE without raising an ERROR. A 45 ms block read turns into a 500 ms parameter-by-parameter poll, and operators waiting on drive feedback notice the delay.

This article dissects the root cause, lays out three production-ready remedies (multiple parallel MB_MASTER instances, optimised single-register polling, and migration to Modbus TCP), and shows how to verify each fix on the bench. Code samples are written in Structured Text (SCL) for TIA Portal V17 and later, and ladder snippets are included where helpful.

System Architecture and Reference Hardware

The CB 1241 plugs into the left bus of the S7-1200 and is auto-discovered after power-up. The RS-485 port is wired A-to-A, B-to-B, and shield to PE at one end only. A 120 Ω termination is enabled on the last device; on the CB 1241 this is a DIP switch (position ON) inside the module door. The CFW500 is configured through parameter P0308 (slave address), P0310 (baud), and P0311 (parity/stop bits).

Modbus RTU Fundamentals on the S7-1200

Modbus RTU is a request/response protocol carried over a single multi-drop RS-485 bus. The master issues a function code, a starting address, and a quantity; the slave replies with the same function code echoed and the requested payload. The crucial constraint is that the address range is always contiguous. Function code 03 (Read Holding Registers) and function code 04 (Read Input Registers) both expect the slave to return Q consecutive 16-bit words starting at A. There is no built-in mechanism to skip holes in the range.

The Siemens Modbus RTU overview for S7-1200 / S7-1500 documents that the MB_MASTER instruction accepts a DATA_LEN of 1 to 125 words for function codes 03/04 and 1 to 123 words for function code 23 (read/write multiple registers). Larger quantities are silently clipped by the instruction's internal buffer. The official Siemens support entry on input register reading also confirms that function code 04 is limited to addresses 0-9998 on the S7-1200; if the drive maps a parameter above 9998, the master must use function code 03 against the holding register range or split the read into multiple function code 04 transactions.

Root Cause: Why a Single Hole Kills the Whole Read

The CFW500 user manual (section 8.2, page 23 of the Modbus RTU supplement) states that a valid request and response telegram cannot exceed 64 bytes. Function code 03 replies are framed as [1 byte addr][1 byte FC][1 byte byte count][2N bytes data][2 bytes CRC]. For 32 words this is exactly 68 bytes, which is already over the 64-byte ceiling, so the practical upper limit is 30 words per request when the slave is a CFW500. Inside the requested range, the drive replies with whatever 16-bit values it has stored at each address. Parameters that the manufacturer reserved but never implemented (P0008 in the example, or any "not used" parameter between two populated ones) return 0x0000 on most CFW500 firmware revisions. The driver does not crash, but the field engineer who tried to read P0007 + P0008 + P0009 in a single block was looking at a slave that simply returned 0x0000 for the missing word while P0007 and P0009 still populated correctly.

If the parameter hole is small and well-defined (for example only P0008 is missing), the cleaner remedy is to ask the vendor whether the drive can be re-mapped. WEG exposes a "modbus mapping" table in parameter group P0680-P0689 (function 06 writes). Reserving a placeholder value in those words forces the slave to reply with a non-zero value for the missing address, which in turn lets the master read P0007-P0009 in one transaction again. Refer to the CFW500 Modbus RTU communication manual section on parameter remapping before assuming the polling workaround is unavoidable.

Strategy 1: Multiple Parallel MB_MASTER Instances

The simplest performance fix is to use several MB_MASTER blocks, each issuing a smaller request against an isolated destination buffer. The S7-1200 CB 1241 can queue up to 4 simultaneous MB_MASTER calls on a single physical port; the underlying driver serialises them in transmit order, but the application can prepare the next request while the previous one is outstanding. This means an eight-instance approach reduces a 12-parameter scan from ~500 ms to ~120 ms without any new hardware.

Steps in TIA Portal V17:

1. Create a global DB named "DriveData" with one array per parameter: MotorSpeed : ARRAY[0..0] OF WORD;, MotorCurrent : ARRAY[0..0] OF WORD;, and so on. Each array must be a multiple of two bytes so the DATA_PTR of MB_MASTER can address it byte-accurately.
2. Drop eight MB_MASTER instances: MB_MASTER_1 through MB_MASTER_8. Wire each REQ input to a unique clock-bit from the cyclic OB (for example "Clock_50ms".ET_Pulse[0] through "Clock_50ms".ET_Pulse[7]).
3. Configure MB_ADDR = 1, MODE = 0 (RTU), DATA_ADDR = the drive's holding-register offset for the parameter, and DATA_LEN = 1. The single-word length guarantees the read will never span a hole.
4. Wire DATA_PTR to the matching array in DriveData. Stagger the REQ pulses by at least 10 ms to avoid back-to-back collisions on the bus.
5. Map DONE to a "data valid" boolean consumed by your HMI; map ERROR to a centralised fault routine. STATUS should be logged to a 16-word ring buffer for diagnostics.

For SCL implementers, the following fragment shows a typical poll body. It assumes a hardware interrupt OB (OB40) generates a 50 ms tick.

// FB_DrivePoll — single-parameter Modbus RTU poll scheduler
// Each call advances one outstanding request and consumes the result.

IF #schedulerTick THEN
    CASE #activeSlot OF
        0: #mbMaster.REQ := #trigger0;
        1: #mbMaster.REQ := #trigger1;
        2: #mbMaster.REQ := #trigger2;
        ...
        7: #mbMaster.REQ := #trigger7;
    END_CASE;
END_IF;

IF #mbMaster.DONE THEN
    #activeSlot := (#activeSlot + 1) MOD 8;
END_IF;

Strategy 2: Single-Register Polling with Priority Scheduling

Where the application only needs a handful of fast values and a larger number of slow values, the cleanest pattern is priority scheduling. A critical parameter (motor current at P0003) is polled every 20 ms; a secondary parameter (heatsink temperature at P0031) is polled every 200 ms; a diagnostic parameter (P0090 power-on hours) is polled every 5 s. This decouples scan time from parameter count and avoids running 12 simultaneous MB_MASTER blocks.

Implement the schedule in an FB that owns an array of PollDescriptor UDTs:

TYPE PollDescriptor :
STRUCT
    dataAddr    : UINT;   // Modbus holding register address (zero-based)
    interval    : TIME;   // e.g. T#20ms, T#200ms, T#5s
    lastCall    : TIME;   // timestamp of last REQ edge
    destPtr     ^WORD;    // AT-view into DriveData
END_STRUCT
END_TYPE

The scheduler scans the array, issues REQ := TRUE on entries whose (currentTime - lastCall) >= interval, and clears the REQ on the next DONE. A single MB_MASTER instance services all slots round-robin, and because no more than one transaction is in flight at a time, the bus is deterministic. Total scan time for the 12-parameter example drops from 500 ms to roughly 280 ms even with the round-robin overhead.

Strategy 3: Migration to Modbus TCP

If the application can tolerate a small hardware change, the cleanest path is the WEG CFW500 Ethernet/IP & Modbus TCP module (plug-in accessory, part number 15069021 or equivalent for the matching CFW500 frame). The S7-1200 supports MB_CLIENT from firmware V4.1 onward, and the PROFINET interface of the CPU can open up to 8 TCP connections concurrently to one or more slaves.

Key advantages of TCP over RTU for this problem:

• Independent transactions can be issued in parallel without bus arbitration. The 12-parameter scan finishes in < 80 ms because the OS-level socket layer pipelines them.
• The 64-byte CFW500 telegram limit still applies, but the driver can pre-allocate a TCP segment larger than 64 bytes and the slave still answers within the constraint.
• Diagnostics are richer: MB_CLIENT exposes STATUS codes that map directly to the Modbus exception response (illegal data address = 02, illegal data value = 03, slave device failure = 04).

Disadvantages to weigh: the TCP module on the CFW500 is still a serial-to-TCP gateway in some firmware revisions, so the 64-byte cap and one-master-at-a-time constraints are inherited from the RS-485 side. Always confirm with the accessory's user manual that the firmware supports a true Modbus TCP server, not just a transparent bridge.

Performance Comparison

WEG CFW500 Parameter Map Reference

The CFW500 exposes its parameters as standard Modbus holding registers at address = parameter number. The default communication settings assume address 1, 38400 baud, 8 data bits, no parity, 2 stop bits (8N2). Adjust the CB 1241 port configuration under Device configuration > CB 1241 > Properties > Port configuration to match.

Holes in the parameter map (e.g. between P0007 and P0009) are factory-reserved. Each "not used" word is reachable on the bus but returns 0x0000 on firmware V3.0X. WEG can supply a per-firmware Parameter List spreadsheet that highlights which numbers are populated; pair this with the official CFW500 Modbus manual so that the S7-1200 engineer knows the exact request range.

Programming the MB_MASTER Block in TIA Portal

1. Insert a new MB_MASTER instance from Libraries > Communication > MODBUS (RTU).
2. On the instance DB, expose REQ, MB_ADDR, MODE, DATA_ADDR, DATA_LEN, DATA_PTR, DONE, ERROR, and STATUS.
3. Create a non-optimised global DB "ModbusBuffers" with one byte array per slot. DATA_PTR must reference a non-optimised area; this is the single most common reason the read "returns nothing" on S7-1200 V4.x. If you are using an optimised DB, switch it off under DB properties > Attributes > Optimised block access.
4. Set MB_ADDR = 1, MODE = 0, DATA_ADDR = the parameter's register offset, and DATA_LEN = 1.
5. Drive REQ from a rising-edge trigger; never tie it to the cyclic OB unconditionally, or the instruction will issue a fresh transaction every scan and starve the bus.

Ladder equivalent of the trigger logic:

|   Clock_50ms   Cycle_OK   |
+-----[P]----+--------( )----(MB_MASTER_1.REQ)
|                                    |
+---[MB_MASTER_1.DONE]---[RESET]---/

Verification Procedure

1. Compile and download the project to the S7-1214. Ensure the CB 1241 is plugged in and powered before download; otherwise TIA Portal will refuse to bind the port configuration.
2. Go online and open the instance DB for MB_MASTER_1. Force REQ to TRUE for one scan. Verify DONE transitions to TRUE within 50 ms and STATUS = 0x0000.
3. Watch the destination array in DriveData. The read should populate the matching slot within one or two 50 ms ticks.
4. Repeat for each MB_MASTER instance in turn. Confirm that no two instances raise REQ simultaneously; the CB 1241 driver will respond with STATUS = 0x80C8 (data area conflict) if the buffer is reused incorrectly.
5. Disconnect the RS-485 cable from the CFW500 to simulate a slave timeout. MB_MASTER.ERROR should rise, STATUS should read 0x80D1 (timeout), and the destination buffer should remain unchanged from its previous value.
6. Reconnect and confirm the next valid REQ edge recovers the link without cycling the CPU.

Troubleshooting Matrix

Diagnostic Capture Snippet

Use the following SCL block to log every Modbus transaction into a ring buffer for the next day's review. It catches both errors and the data so a post-mortem on a missed poll is fast.

// FB_ModbusDiag — diagnostic ring buffer (64 entries)
IF #mbMaster.ERROR THEN
    #logIndex := (#logIndex + 1) MOD 64;
    #logTime[#logIndex]      := RT_CLK_RD(T#0s, _clk);
    #logStatus[#logIndex]    := #mbMaster.STATUS;
    #logDataAddr[#logIndex]  := #mbMaster.DATA_ADDR;
    #logDataLen[#logIndex]   := #mbMaster.DATA_LEN;
END_IF;

Export logTime, logStatus, logDataAddr, and logDataLen to a watch table and save as CSV for trend analysis. This is the fastest way to confirm whether a given poll ever actually completed, and whether the slave ever returned an exception code that the S7-1200 silently ignored.

Field-Proven Caveats

• The 64-byte CFW500 telegram cap is a hard physical limit. If the user is reading more than 30 holding registers in one transaction, the slave will not respond at all and the master will time out, not raise an exception.
• Some early CFW500 firmware revisions (V2.4X) returned 0xFFFF instead of 0x0000 for unused parameters. Treat any read that yields 0xFFFF as a "hole not yet mapped" rather than a real 65535 value.
• CB 1241 RS-485 termination is shared with the next module; if the next device in the line is also a CB 1241 with termination enabled, the bus is over-terminated and reads become intermittent. Enable termination on exactly one device.
• MB_MASTER on the S7-1200 cannot be called from more than one priority class at the same time. If a fast OB35 also issues a request while OB1 is mid-transaction, the second call is dropped and returns STATUS = 0x80C8. Always serialise Modbus traffic in OB1 (or in a single fast OB that owns the instruction).

FAQ