Troubleshooting S7-1200 Modbus TCP MB_CLIENT BUSY Lock Issue

Problem Description

An S7-1200 CPU drives the MB_CLIENT instruction against an Iskra MC740 power meter over the PROFINET interface using TIA Portal V11 SP2 Update5. When the application sets the REQ input, BUSY latches to 1 but neither DONE nor ERROR ever transitions to 1. The instruction appears "stuck" and the read data never populates the configured buffer (MB_DATA_PTR). The same CPU, project, and instruction handle other Modbus TCP endpoints normally, which isolates the fault to the partner device, the connection parameters that target it, or the firmware/library version mismatch.

Root Cause Analysis

According to the Siemens application note for Modbus TCP on S7-1200 and S7-1500 CPUs, MB_CLIENT drives BUSY during both the TCP connection establishment phase and the active request/response phase. DONE is set only after a valid Modbus response PDU has been received and parsed. ERROR is set only when the instruction either receives a Modbus exception code (function code with bit 7 set) or detects a transport-layer fault and reports it through the STATUS output.

If MB_CLIENT shows BUSY=1 for an abnormally long time without ERROR being set, the most likely cause is that the TCP connection is in the SYN-SENT state and the partner has not completed the three-way handshake. The S7-1200 TCP/IP stack retries the SYN according to its internal connect-retry policy, but if no SYN-ACK is ever returned and no TCP RST is received, the connection stays half-open and the STATUS output remains at the queued value 16#7001. This maps directly to the behavior described in the field report: the instruction tries repeatedly to open TCP/502 against the meter and never reaches a state where a Modbus PDU can be exchanged.

The S7-1200 Modbus TCP example set in the TIA Portal manual collection assumes the partner is a Modbus TCP server. The Iskra MC740 is, in many shipped configurations, a Modbus RTU / DNP3 meter with RS-485 and optional Ethernet for DNP3 over TCP, not Modbus TCP. Where Modbus TCP is offered, it is typically a firmware option or a different model variant. Treat protocol support on the meter as unknown until the manual confirms a TCP/502 listener service.

Pre-Diagnostic Verification

Before changing any PLC code, verify the partner device independently. None of these steps require the S7-1200.

1. Confirm the meter variant and the protocol the firmware exposes. Read the type plate (P/N, HW rev, SW rev). Compare to the Iskra MC740 user manual for the protocol capability matrix.
2. Apply the meter's documented IP address to a service laptop with a static address on the same subnet. Use a crossover cable or a managed switch with a port-mirror enabled.
3. Ping the meter. A successful ICMP echo proves Layer 3 reachability only; it does not prove a TCP/502 listener exists. A failed ping immediately rules out Layer 1/2/3 faults.
4. Probe port 502 with a generic TCP test tool (Hercules SETUP utility in TCP Client mode, Wireshark with the filter tcp.port==502, or PowerShell Test-NetConnection -Port 502). Send a single Modbus Read Holding Registers PDU, for example FC03 starting at register 0, length 1: 00 01 00 00 00 06 01 03 00 00 00 01 (no CRC for TCP). A successful reply proves the meter is a Modbus TCP server. A SYN without any reply, or with an immediate RST, proves the meter is not.
5. Capture traffic on the mirror port for one REQ cycle from the S7-1200 and verify whether the CPU emits SYN packets to meter:502 at all. No SYN packets mean MB_CLIENT has not attempted the connect (trigger path or instance DB issue). SYN packets without any reply mean the partner is not responding.

Protocol Confirmation for Iskra MC740

The MC740 family supports several communication options that depend on the hardware revision and firmware build:

• Modbus RTU over RS-485 (default on many units).
• DNP3 over serial or over TCP.
• Modbus TCP/IP on selected MC740N variants or where an external Ethernet gateway is fitted.

If the unit at hand is the base MC740 with no optional Ethernet module, Modbus TCP is not available and the stuck-on-BUSY symptom is expected: the S7-1200 is sending SYN to a port that is closed. The remedy in that case is one of:

• Replace MB_CLIENT with a serial Modbus RTU master on a CM 1241 RS-485 module using the MB_COMM_LOAD and MB_MASTER instruction pair.
• Install the Iskra Ethernet module that exposes TCP/502 and re-test with the Modbus scanner tool.
• Place a third-party Modbus TCP-to-RTU gateway in front of the MC740 RS-485 port and point MB_CLIENT at the gateway IP.

MB_CLIENT Parameter Configuration

Once protocol support is confirmed, the MB_CLIENT instance must be wired correctly. The instruction signature has changed between firmware generations. In TIA Portal V11 SP2 Update5 the legacy MB_CLIENT blocks match the S7-1200 firmware V2.x/V3.x signature. Configure the inputs as follows.

For a read of 8 holding registers starting at Modbus address 40001 from a meter whose IP is 10.0.0.42:

MB_MODE      := 0;                          // 0 = read holding registers
MB_DATA_ADDR := 0;                          // Modbus 40001 (zero offset)
MB_DATA_LEN  := 8;                          // 8 registers
MB_DATA_PTR  := P#DB20.DBX0.0 WORD 8;       // buffer of 8 words

Do not start with a large MB_DATA_LEN "just in case": many entry-class meters reject FC03 reads spanning the entire input map with an Illegal Data Address (0x02) exception. Begin with MB_DATA_LEN = 1 against a known register, then scale upward register-by-register as each register is verified.

TCON_IP_V4 Connection Structure

The CONNECT input is the most common culprit when the connect phase fails silently. In TIA Portal V11 the data block element must be of type TCON_IP_V4 (or the secure variant TCON_IP_V4_SEC on firmware V4.2+). Every field is required and the order is fixed.

Status Code Reference

Decode the STATUS output at every DONE or ERROR edge. The most relevant values for the S7-1200 firmware V2.x/V3.x generation are:

Capture STATUS via the watch table or trace and verify whether it stays at 16#7001 (connection phase) or advances to 16#7002 (response phase). If STATUS never advances past 16#7001, the partner is not completing the handshake. If it advances to 16#7002 but never reaches DONE, the partner accepted the connection but is not returning a Modbus PDU.

TIA Portal V11 SP2 Caveats and Firmware

Several field-proven issues are specific to the development environment in use:

• Firmware support: Modbus TCP MB_CLIENT and MB_SERVER instructions require S7-1200 CPU firmware V2.0 or later. Verify the connected CPU's firmware via "Online & Diagnostics" -> "Diagnostic of the CPU". V1.0 firmware does not include the Modbus TCP library and a project that compiles against V11 SP2 will simply not run the FBs at runtime.
• Library version: TIA Portal V11 SP2 Update5 ships "Modbus_TCP" V13 (master copy 3.1) for the legacy FB_MBUS_CLIENT/FB_MBUS_SERVER FBs. For newer projects prefer "Modbus TCP" V4.x with the renamed MB_CLIENT/MB_SERVER blocks referenced in the S7-1200/S7-1500 Modbus TCP application note. Mixing FBs across versions in the same project is unsupported.
• Instance DB regeneration: After any change to the CONNECT structure, delete and re-instantiate the MB_CLIENT instance DB. A stale DB keeps the connection descriptor of the previous compile, including an old IP or port.
• Watchdog supervision in OB1: Running MB_CLIENT only in OB1 with a long cycle is acceptable. Running it only in a watchdog OB or in a time-delay interrupt at a slow rate can stall the TCP stack from completing its state machine.
• Online STOP/RUN: Each RUN-STOP-RUN cycle closes existing TCP connections. The first REQ after a STOP must wait for the connect phase again; this matches the symptom "first scan fails, subsequent calls also stuck" in some projects.
• Real-time settings: If the PROFINET port's cycle time is set too low (for example, 1 ms) the communication load can starve the TCP/IP background task, delaying the SYN by several seconds. Increase the PROFINET update time to 2 ms or higher for any S7-1200 that is not engaged in real-time I/O.

Field-Proven Verification Procedure

1. Bring up the meter's Modbus TCP service. With a service laptop and a Modbus scanner (Modbus Poll, CAS Modbus Scanner, QModMaster), connect to meter.ip:502 and do an FC03 read of register 0 length 1. Confirm a response.
2. Compile and download the PLC project. After download perform a power cycle if the meter caches the prior client IP.
3. Force REQ TRUE once. Observe STATUS. Confirm STATUS advances from 16#7001 to 16#7002 within the partner's documented response timeout (typically 2..5 s for an Iskra-class meter).
4. Observe a successful DONE. Read MB_DATA_PTR in the watch table and verify the values match what the scanner returned.
5. If the meter is on a different subnet, configure the IP router on the PROFINET interface (Properties -> Ethernet addresses -> IP router). The S7-1200 will route outbound TCP segments to the gateway.
6. If multiple MB_CLIENT instances target the same meter, assign each a unique CONNECT.ID and a different LocalPort. Verify only one connection is active per instance (use Netstat on a PC mirror).
7. Disable managed-switch features that interfere with the meter: flow control, energy-efficient Ethernet (EEE / IEEE 802.3az), and IGMP snooping for unknown multicast. Each can break a slow 100BASE-TX endpoint.
8. Add watch-table breakpoints on DONE, ERROR, and STATUS so every completed or failed transaction leaves a record.

Modbus Address Mapping for the MC740 Family

When the connection is working but DONE never carries the expected values, the cause is typically a wrong MB_DATA_ADDR. The MC740 register map is documented in the Iskra MC740 Modbus protocol reference (P/N 1162530-1). The relevant holding register blocks for a typical energy reading are:

Always consult the meter's documentation for the exact register layout and the engineering units, since the scaling factor and endianness are vendor-specific. Most Iskra meters return 32-bit values as a pair of 16-bit registers with the high word first (big-endian within the Modbus payload). Use MB_DATA_LEN counts that respect register pair boundaries to avoid crossing energy counter boundaries mid-read.

Frequently Asked Questions