Resolving MB_CLIENT Status 7005-80C3 Oscillation on S7-1200

Problem Overview

The MB_CLIENT instruction on Siemens S7-1200, S7-1500, and S7-1200 G2 CPUs running a Modbus TCP client toggles continuously between BUSY = TRUE, DONE = FALSE, ERROR = FALSE and BUSY = FALSE, ERROR = TRUE with the output parameter STATUS cycling primarily between 7005 and 80C3 (hexadecimal). The user data buffer mapped to the DATA_PTR input remains at 16#0000 across every scan cycle. Intermittent 7006 (waiting for response), 7009, or event word status codes may appear in the instance DB monitor without ever producing a DONE = TRUE edge.

Technical Background: Status Code Decoding

The MB_CLIENT STATUS output is a 16-bit WORD in which two distinct encoders feed the value depending on operating state. When the block is mid-transaction, STATUS carries the Modbus job progress; when an exception occurs, it carries the underlying PROFINET/TCP error code. The 7005/80C3 pair must be interpreted as separate events, not a single code.

Root Cause Analysis

Five independent root causes can produce this oscillation on a Siemens S7-1200. Field data and the official Siemens library documentation isolate them into the following ranked matrix.

Prerequisites

1. STEP 7 Basic / Professional V16 or later, TIA Portal V17/V18/V19/V20/V21 supported. Library Modbus_TCP_CP V4.0+ for S7-1200, V3.x+ for S7-1500 must be installed.
2. Target CPU firmware: S7-1200 V4.0+ (article applies to S7-1200 G2 with the same library block).
3. Online connection to the PLC (Ethernet, PG/PC interface).
4. A second TCP testing tool such as ModScan32 or open-source libmodbus for cross-validation of the server's register map.
5. Wireshark or the TIA Portal online Online & Diagnostics > PROFINET > Connections view to capture the TCP handshake.

Diagnostic Procedure

Follow the procedure in order. Each step produces a binary decision (pass/fail) that points to the matching solution section.

1. Capture the live STATUS. In TIA Portal, open the MB_CLIENT_DB instance data block in Monitor/Modify mode and select Update in watch. Confirm that STATUS flips between W#16#7005 and W#16#80C3 on every PLC cycle.
2. Verify the connection resource. Navigate to Project tree > PLC > Devices & networks > X1 / X2 > PROFINET interface > Properties > Ethernet addresses. Open Connections and locate the entry whose Local ID matches the value at the CONNECT input of MB_CLIENT. Each ID must be unique across the project.
3. Test against a reference Modbus server. Use Modscan on the engineering PG to query the same registers the MB_CLIENT is configured for. If Modscan reads valid values, the server is healthy.
4. Cross-check the data type. Confirm whether the server stores the target register as INT, REAL, WORD or as a 32-bit double register (CDAB / ABCD byte order). Mismatch here triggers Siemens MB_CLIENT 8181 replies.
5. Capture the TCP stream. Start Wireshark on the same VLAN, filter for tcp.port == 502. A successful Modbus transaction shows SYN, SYN-ACK, ACK, MB request PDU, MB response PDU, FIN. If only SYN retransmits are observed, the partner does not respond.
6. Verify the MB_UNIT_ID. Many SIPROM, ABB and Schneider power-meter servers require a specific Unit Identifier (often 255 or 0). The DB parameter MB_UNIT_ID must match.

Solution 1 — Connection Identifier Collision

This is the most common field fix and is the one that resolved the original case study. A TCON connection resource index is consumed by the first Ethernet instruction that references it. Two MB_CLIENT instances configured with CONNECT = 1, or an MB_CLIENT paired with an MB_SERVER or a TSEND_C block sharing CONNECT = 1, will both attempt to bind to the same local endpoint and the TCP stack rejects the second.

1. In TIA Portal open Project tree > PLC > Devices & networks.
2. Click the CPU, then Properties > Ethernet addresses > Connections.
3. Rename the local ID of the failing MB_CLIENT from 1 to a free slot — 5, 10, or any unused value.
4. Open the MB_CLIENT instance and update the CONNECT input to the new local ID.
5. Compile (Hardware + Software) and download to the CPU.

After the change the block must be re-initialized. Insert a one-shot rising edge into the REQ input or call MB_CLIENT(REQ := bStart) once after restart so a fresh TCON occurs.

Solution 2 — Data Type and Register Address Mismatch

If Modscan returns the expected values but the MB_CLIENT still fails (often with periodic 8180/8181 flashes in the same cycle), the register model the PLC expects is different from the server reality.

1. For floating-point values, ensure the DATA_PTR points to a REAL tag (4 bytes) and that MB_DATA_LEN is set to 1 register pair, i.e., value 2. For 16-bit values use INT/WORD and MB_DATA_LEN = 1.
2. Verify the byte order. Some energy meters (Schneider Electric PM5xxx, ABB M4M 30) return CDAB floating-point format. If DATA_PTR points to REAL and the value reads 0.0 with valid Modscan output, swap high/low word with two WORD reads followed by a byte-swap function block.
3. Validate the register address. Most servers use 0-based holding-register offsets starting at address 40001. Some PLC-side libraries (legacy Modbus-TCP MB_CLIENT V3.x) expect 1-based MW0-style offsets and expose 40001 as 0. If MB_DATA_ADDR = 1 (40001) returns 0 but MB_DATA_ADDR = 0 or 2 returns the right value, change the address by 1.

Solution 3 — Physical Layer and Switch Configuration

1. Swap the Ethernet patch cord; pinout must be TIA-568A or TIA-568B consistently end-to-end. Use a known-good Cat 5e or Cat 6 cable of less than 100 m.
2. Force both the S7-1200 and the server to 100 Mbps / Full Duplex on the switch port if autonegotiation fails. ProSet/managed switches expose this as Port Speed & Duplex > Force 100Fdx.
3. Disable Energy Efficient Ethernet (EEE, IEEE 802.3az) on the switch port — some S7-1200 firmware revisions historically handle EEE pause frames incorrectly and the link resets every few seconds.
4. Confirm any VLAN tagging — if the server sits in VLAN 20 and the PLC port is VLAN 1 untagged, the Modbus PDU never returns.

Solution 4 — Direct MB_UNIT_ID Override (Advanced)

This technique was reported as a workaround for stubborn Modbus gateways that ignore MB_UNIT_ID in the request PDU but require a specific unit on the response side. Use only when both solutions 1 and 2 are exhausted.

1. Open System blocks > MB_CLIENT_DB in TIA Portal.
2. Switch the DB to Manual (uncoupled from the program).
3. Edit the static tag MB_UNIT_ID to the value the server expects (commonly 1, 255, or the unit-slot of a daisy-chained RTU).
4. Re-compile and download only the DB, then restart the MB_CLIENT by toggling REQ.
5. Once handshake succeeds, snapshot the data and put the DB back into program-control so future re-deployments do not overwrite the manual edit.

Verification

1. Set a trace on MB_CLIENT_DB.STATUS, MB_CLIENT_DB.BUSY, MB_CLIENT_DB.ERROR and MB_CLIENT_DB.DONE.
2. Force REQ with a single-cycle rising edge.
3. Confirm the trace shows one pulse of BUSY followed by a clean DONE edge within the configured Modbus timeout (default 5 000 ms).
4. Confirm STATUS ends at W#16#0000 after the DONE pulse. The buffer must contain the expected value.
5. Repeat the cycle ten times consecutively; any reappearance of 80C3 indicates the underlying root cause has not been fully resolved.

Related Status Codes Reference

Troubleshooting Matrix

Common Field Pitfalls

• Using the same Ethernet port for PROFINET IO and Modbus TCP without enabling the PROFINET interface for open communication — by default, S7-1200 blocks open TCP traffic on the same IP used for PROFINET when the controller is a PROFINET device; remap to a second IP / second interface where available.
• Configuring MB_DATA_ADDR in holding-register offset mode while the server expects the legacy Modicon 4xxxx base — always confirm with the server's register map PDF.
• Forgetting that MB_CLIENT requires a positive edge on REQ for each transaction. Holding REQ = TRUE causes one execution followed by ERROR = TRUE and a status flip.
• Using MB_CLIENT from a library version older than 4.0 on S7-1200 V4.5 firmware; cross-version conflicts lead to 80C3 even on a healthy network.

FAQ