Troubleshooting S7-1500 Modbus_Comm_Load Status 16#7000 / 16#7001: DONE and ERROR Stay FALSE

The Modbus_Comm_Load instruction on the SIMATIC S7-1500 (CPU 1515-2 PN, 1517-3 PN/DP, 1518-4 PN/DP, etc.) is one of the most frequently misconfigured FBs in TIA Portal. A classic symptom — the block never reports DONE = TRUE or ERROR = TRUE, and the STATUS output remains frozen at 16#7000 or 16#7001 — is almost never a code bug. It is a hardware, library, port-identifier, or runtime issue that prevents the block from completing bus initialization.

This guide consolidates the engineering checks required to recover the communication, with deep coverage of the CM 1541-1 PtP module (article number 6ES7 541-1AB00-0AB0), TIA Portal V16 library selection, port HW identifiers, and PLCSIM limitations. It is intended for automation engineers responsible for commissioning Modbus RTU links to inverters, instruments, and weigh scales over RS485.

1. What the Status Code 16#7000 Actually Means

The STATUS word on Modbus_Comm_Load follows the standard SIMATIC step-pattern:

2. Why the Block Never Advances Past 16#7000 / 16#7001

From field experience, the failure modes cluster into five categories. Diagnose in this order because each subsequent check assumes the previous one is correct.

1. Library not installed in the project. The blocks Modbus_Comm_Load and Modbus_Master / Modbus_Slave are not part of the S7-1500 base instruction set. They ship in the optional library MODBUS_RTU (or MODBUS_PN for Open User Communication on PROFINET). Without the library, the FB compiles against a stub or the system function simply does not execute.
2. Wrong or empty HW identifier on the PORT input. The PORT parameter is a hardware identifier (HW-ID), not a slot number. The HW-ID is generated automatically by TIA Portal when the CM 1541-1 is inserted and configured. Dragging the value from the device configuration or using a constant from the system constants is mandatory.
3. Block called only on a single cycle and not retriggered. Because the FB is a multi-cycle instruction, the first scan must re-evaluate every OB1 pass. Tying REQ to FirstScan then never re-driving it leaves the block in the idle state 16#7000.
4. Running on PLCSIM. S7-PLCSIM does not emulate the CM 1541-1 backplane bus. PtP instructions always return 16#7000 in PLCSIM regardless of wiring. Use PLCSIM Advanced or a physical CPU for testing.
5. Instance DB loaded twice or not loaded. The single-instance DB created by the FB must be downloaded to the CPU. If a second copy exists in the project tree without the FB call, the call gets the wrong instance.

3. Hardware Setup: CM 1541-1 (6ES7 541-1AB00-0AB0)

The CM 1541-1 in HF (High Feature) variant is the standard PtP module for S7-1500 Modbus RTU. Configure it in the device view before adding any FB to OB1.

The HW identifier is the single most common source of stuck 16#7000 / 16#7001. After downloading the device configuration, open PLC > Properties > System Constants and locate the line CM 1541-1 / PtP interface. The numeric value in the HW Identifier column is what must be wired to the PORT input of Modbus_Comm_Load.

4. Software Setup: TIA Portal V16 Library Selection

TIA Portal V16 ships multiple Modbus libraries. Choose exactly one to avoid name collisions.

To install: in the project tree, right-click the CPU → Properties > Library → Add user library → select MODBUS_RTU from the global library catalog. Confirm that Modbus_Comm_Load V6.0 (or later) appears under Instructions > Communication > Modbus RTU. Rebuild the program after adding the library so the FB symbol resolves to a real block rather than an unresolved reference.

5. Wiring the RS485 Bus

The CM 1541-1 front connector is a 9-pin Sub-D. For 2-wire (half-duplex) Modbus RTU:

Verify the bus is a single daisy chain (no stubs longer than ~30 cm at 19200 baud, shorter at higher rates), that the shield is grounded at one end only, and that exactly two termination resistors — at the physical end nodes — are present. A shorted or reversed A/B pair will produce 16#8184 the moment a telegram is sent; a missing termination typically allows the first scan to complete (16#7001 → 16#0000) but corrupts every subsequent Modbus_Master call.

6. Calling the FB in OB1 — The Correct Pattern

Because Modbus_Comm_Load is multi-cycle, it must be called every scan. A common mistake is to gate it behind FirstScan:

// OB1 — segment 1
// ❌ INCORRECT — REQ is only TRUE for one scan, then STATUS stays 16#7000
IF "FirstScan" THEN
    "Modbus_Comm_Load_DB".REQ := TRUE;
END_IF;
"Modbus_Comm_Load_DB"(
    REQ              := "Modbus_Comm_Load_DB".REQ,
    PORT             := 269,              // HW ID of CM 1541-1
    BAUD             := 9600,
    PARITY           := 2,                // 0=None, 1=Odd, 2=Even
    FLOW_CONTROL     := 0,                // 0=None
    RTS_ON_OFF       := 0,
    RTS_PRESET       := 0,
    RESP_TO          := 1000,             // ms — slave response timeout
    MODE             := 4,                // 4 = Modbus RTU master (RS485 half-duplex)
    TIMEOUT          := 2000,             // ms — character timeout
    DONE             => _done,
    ERROR            => _err,
    STATUS           => _status);

The correct pattern is to force a rising edge on REQ on the first scan, then let the FB self-clear it. The block is internally designed to drive its own REQ low on completion, so an external latch is not required:

// OB1 — segment 1
// ✅ CORRECT — REQ rises on first scan, then the block manages its own state
"Modbus_Comm_Load_DB"(
    REQ              := "FirstScan",       // one-shot edge is sufficient
    PORT             := 269,
    BAUD             := 19200,
    PARITY           := 2,                 // Even
    FLOW_CONTROL     := 0,
    RESP_TO          := 1000,
    MODE             := 4,                 // Modbus RTU master half-duplex
    DONE             => _done,
    ERROR            => _err,
    STATUS           => _status);

IF "Modbus_Comm_Load_DB".DONE THEN
    "Modbus_Master_DB".REQ := TRUE;        // start master cycles
END_IF;

7. PLCSIM and Runtime Limitations

The S7-1500 simulation (S7-PLCSIM and S7-PLCSIM Advanced) supports PROFINET-based MODBUS_PN, but does not emulate the CM 1541-1 PtP module. In PLCSIM:

• Modbus_Comm_Load returns STATUS = 16#7000 indefinitely.
• No telegram is ever placed on the bus.
• DONE never becomes TRUE; ERROR never becomes TRUE.

Symptom presentation: the engineering project is fully correct, Modscan sees the slave on the desk, and TIA Portal reports a successful download. Only the in-CPU behavior is broken. The only remedy is to test on real hardware. If a CPU is unavailable, you can validate program structure by stubbing the PORT input with an unused HW identifier and observing the 16#8180 error — this confirms the call site is wired correctly and shifts the suspicion away from code into hardware.

8. Step-by-Step Diagnostic Procedure

Run the following checks in order. Each step should be marked complete before moving to the next.

1. Verify the CM 1541-1 in the device view. The module must appear under the CPU in the project tree. Open Device view, select the CM, and confirm a green check on the slot. If absent, add it from the catalog and download the new hardware configuration.
2. Confirm the port protocol. Right-click the CM → Properties > Port > Protocol → Freeport. The Modbus RTU master instruction expects the port to be in Freeport mode, not "Modbus Master".
3. Read the HW identifier. PLC > System Constants → filter by CM 1541-1. Note the integer value (e.g., 269) and use it on the PORT input.
4. Install the MODBUS_RTU library. Check that the FBs appear in the project instructions tree. If they are missing, the block in OB1 is a placeholder.
5. Confirm the call site is in OB1 (or a cyclic OB). Modbus_Comm_Load in OB100 only runs once on startup; in OB82 / OB86 it is suspended. Place it in OB1 unconditionally.
6. Monitor STATUS in a watch table. Add a watch table with the instance DB tags .REQ, .DONE, .ERROR, .STATUS. Cycle the CPU and observe.
7. Cross-check the slave with Modscan or Modbus Poll. If the slave answers from a PC tool, the slave hardware and physical layer are good. The issue is on the PLC side.
8. Check the CPU diagnostic buffer. Online → Diagnostics > Diagnostic Buffer. Entries referencing "PtP", "Modbus", or "CM 1541-1" with event ID 0x1A40 / 0x1A41 indicate the module reported a bus error.
9. Re-download everything. Stop the CPU → Download to device with "Software (all blocks)" and "Hardware configuration" checked. Reset the CM by power-cycling or by toggling it in the device view.

9. Verification

Successful commissioning is confirmed by the following observable state:

• Modbus_Comm_Load.DONE pulses TRUE once after the rising edge of REQ, then returns FALSE.
• Modbus_Comm_Load.STATUS reads 16#0000 on the cycle where DONE is TRUE.
• Modbus_Master cycles through 16#7001 → 16#0000 on each read/write request.
• The diagnostic buffer contains no PtP error events.
• An external Modbus scanner sees the master’s request frames on the RS485 bus at the configured baud and parity.

A final test that catches the most elusive wiring issues: temporarily set the slave to loopback mode (if available) or short pins 3 and 8 on the CM 1541-1 with a 120 Ω resistor. The block should now report a framing error (16#8184) on the first Modbus_Master cycle. The fact that the error code is physical rather than stuck at 7000 proves the Modbus_Comm_Load itself is healthy — the original problem is upstream of the bus.

10. Quick Reference Fault Matrix

11. Extended Diagnostics: Reading the CM LEDs

The CM 1541-1 front panel LEDs provide instantaneous status that complements the STATUS word:

• DIAG slow red blink — module diagnostic event; check CPU diagnostic buffer for entry text "PtP configuration error" or similar.
• DIAG solid red — module fault, often firmware / configuration mismatch. Verify the module firmware in the device view matches a version supported by the CPU firmware (F-update the CM if required).
• TX / RX activity — should flicker on every Modbus_Master cycle. A completely idle TX/RX with DONE=TRUE on Modbus_Comm_Load confirms the master is not being called.

If the LEDs do not match the expected state, cycle power to the CM. A field-tested quirk: after a hot-swap or partial download, the CM can hold the previous port configuration in cache, returning 16#7001 because the new HW ID does not match its internal handle. A full power reset of the S7-1500 station clears the cache.

12. Frequently Asked Questions