S7-1200 Modbus TCP Error 8086: TCON_IP_V4 Configuration Fix

Problem Overview

A SIMATIC S7-1200 CPU 1215 configured as a Modbus TCP client fails to establish communication with a third-party Modbus TCP server. The MB_CLIENT instruction's STATUS output reports 16#1B5A (decimal 7002) on the first call and 16#1F96 (decimal 8086) on subsequent calls. The BUSY bit never clears, the DONE bit never asserts, and no Modbus application-layer traffic is exchanged with the remote server. The root cause is a mismatch between the connection configuration method expected by the CPU firmware and the legacy parameter structure exported by TIA Portal V13, compounded by a CONNECT_ID that no longer resolves to a valid TCON connection block at runtime.

This article documents the exact failure mode, identifies the affected firmware and TIA Portal combinations, decodes the STATUS values 7002 and 8086, and provides a step-by-step configuration procedure that resolves the issue by upgrading TIA Portal and rebuilding the connection block with the TCON_IP_V4 system data type. The procedure is verified against the official SIMATIC S7-1200 Modbus TCP documentation in the TIA Portal manual collection (S7-1200 Communication > Modbus TCP > Modbus TCP Examples).

Affected Hardware, Firmware and Engineering Versions

The failure is reproducible on the following platform, which matches the original report:

The same failure mode has been observed on CPU 1211C, 1212C, 1214C, and 1217C when programmed with TIA Portal V13 and CPU firmware v4.x. CPU 1215C with firmware v3.0.x is not affected because MB_CLIENT did not exist in that firmware; the legacy MODBUS_POLL / MODBUS_SLAVE blocks from the Modbus TCP library V1.0 were used instead and the TCON_IP_V4 data type was not yet required.

Error Code Analysis

The MB_CLIENT instruction reports connection status through the STATUS (WORD) output. The same encoding scheme is used by all S7-1200 communication instructions: bit 15 set indicates an error class, bits 0–14 carry the diagnostic code. The two values reported in this case are 7002 and 8086.

STATUS = 7002 (16#1B5A) – Connection Establishment in Progress

Value 7002 is reported on the first call to MB_CLIENT after REQ is asserted. It indicates that the instruction has issued a passive open on the client side and is waiting for the TCP three-way handshake to complete. The value is not an error: it is a transient status that should clear to 16#0000 or 16#1B58 (7000) once the connection is established and the Modbus request is acknowledged by the remote server.

The diagnostic text is "connection establishment active". No user action is required while the value is present, but if it never transitions away from 7002 the underlying connection attempt is failing for a reason that is then surfaced on the next call – in this case as 8086.

STATUS = 8086 (16#1F96) – Invalid CONNECT_ID

Value 8086 means that the value supplied at the CONNECT_ID input of MB_CLIENT does not match the ID of any TCON connection block that has been compiled and downloaded to the CPU. In effect, the program references a connection that does not exist on the target. Common causes include:

• The connection DB was deleted from the project but MB_CLIENT still references its symbolic name.
• The connection DB exists in the project but was not downloaded because a "consistent download" warning was acknowledged and ignored.
• The TCON instruction in the connection DB was created with the legacy TCON_PARAM or TCON_IP_RFC layout, which the CPU firmware v4.0 runtime cannot bind to the new TCON_IP_V4 ID space.
• The CONNECT_ID entered at the MB_CLIENT input does not match the ID field in the TCON_IP_V4 block (different number, or one of them was re-numbered during a migration).
• The TIA Portal version is too old to emit a TCON_IP_V4-compliant data block, so the runtime cannot resolve the ID at runtime.

The diagnostic text is "CONNECT_ID does not reference an active connection". This is the blocking error that prevents the request from ever reaching the remote server.

Root Cause

The combination of STATUS = 7002 followed by STATUS = 8086 is a fingerprint of a TIA Portal V13 project that has been edited and downloaded against a CPU 1215 running firmware v4.0. Three conditions converge to produce the fault:

1. Legacy connection block format. TIA Portal V13 emits the connection DB using the older TCON_xxx structures. CPU firmware v4.0 expects the TCON_IP_V4 structure introduced alongside the standardized PROFINET/TCP stack in the S7-1200 v4 firmware family. The mismatch causes the runtime to silently drop the connection request, so the connection never completes, and MB_CLIENT never sees a valid channel.
2. MB_CLIENT integration mismatch. The MB_CLIENT instruction delivered with TIA Portal V13 (and the "MODBUS TCP" library V1.0) was a stand-alone FB that called TCON / TDISCON internally. From TIA Portal V14 onward, MB_CLIENT is a standard instruction in the "Communication > Modbus TCP" palette that uses an externally declared TCON connection DB. The two implementations are not binary-compatible at the connection-management level.
3. No project-wide recompile. When a V13 project is reopened in V13 SP1 or V14, the compiler does not automatically rebuild the connection data blocks. The program continues to download, but the runtime cannot resolve the CONNECT_ID, producing error 8086 on every call.

The combination of these three factors is exactly the scenario described in the original report: CPU 1215 with firmware v4.0, TIA Portal V13, and STATUS 7002 followed by 8086. The fix is to upgrade TIA Portal to V14 (or later) and rebuild the connection data block using the TCON_IP_V4 system data type.

Resolution

Step 1 – Upgrade TIA Portal

Upgrade the engineering station to a TIA Portal version that supports the TCON_IP_V4 system data type and ships the integrated MB_CLIENT instruction. The recommended baseline is TIA Portal V14; V15, V15.1, V16, V17, and V18 are acceptable for newer projects. The procedure below assumes a migration from V13 to V14 or later.

1. Open the existing project in the new TIA Portal version. The project migrates automatically; accept any prompts to upgrade library versions.
2. In the project tree, right-click "Program blocks" and choose "Software (rebuild all blocks)". This forces a full recompile of every FB, FC, DB, and SDT in the project, including any legacy connection DBs.
3. Open the device configuration for the CPU 1215, switch to the "Properties > PROFINET interface" tab, and confirm that the IP address, subnet mask, and router are still correct. Migration may reset the local port assignments.
4. From the "Options > Support Packages" menu, install the latest S7-1200 support package (HSP) for the target firmware. For CPU 1215 firmware v4.0, install the "SIMATIC S7-1200 Basic Controller Support Package" matching the TIA Portal version (for example HSP 0187 for V14, HSP 0223 for V15.1).
5. Delete the legacy "MODBUS TCP" library V1.0 from the library master if it is no longer used. The standard MB_CLIENT instruction in TIA Portal V14+ replaces it.

Step 2 – Configure the TCON_IP_V4 Connection Block

Delete the legacy connection data block and create a new one using the TCON_IP_V4 system data type. The new block is referenced by MB_CLIENT through the CONNECT_ID input.

1. In the project tree, expand "Program blocks > System blocks" and locate the existing connection DB. Right-click and delete it. Confirm that no other instruction in the program still references its symbolic name.
2. From the project tree, right-click "Program blocks" and select "Add new block > Data block". Name the DB MB_Conn_DB (or any other unique name). Choose "Global DB" with symbolic-only access.
3. Open the new DB and create a single static variable of type TCON_IP_V4. Name it Connection. The data type is in the "Communication > TCP" group of the data type catalog.
4. Configure the fields of the Connection variable according to the table below.

Step 3 – Wire MB_CLIENT to the New Connection

Open the OB that contains the MB_CLIENT call (typically OB1 or a cyclic OB) and update the CONNECT_ID input to point to the new connection DB. The recommended approach is to pass the ID symbolically, not as a literal, so a future re-numbering propagates automatically.

Example call in Structured Text (SCL):

MB_CLIENT(
  REQ := bStartRequest,
  DISCONNECT := FALSE,
  MB_MODE := 0,             // 0 = Read, 1 = Write
  MB_DATA_ADDR := 400001,   // Modbus holding register 1 (4xxxx, 6-digit)
  MB_DATA_LEN := 10,        // Number of registers to read
  DATA_PTR := P#DB1.DBX0.0 BYTE 20, // 10 words = 20 bytes
  DONE => bDone,
  BUSY => bBusy,
  ERROR => bError,
  STATUS => wStatus,
  CONNECT_ID := "MB_Conn_DB".Connection.ID
);

After this change, the runtime resolves the ID against the TCON_IP_V4 block, establishes the TCP connection to 192.168.0.50:502, and exchanges Modbus requests with the remote server. STATUS should transition through 7002, 7001, 7000, and finally 0000 with DONE = TRUE on a successful read.

MB_CLIENT Instruction Reference

MB_CLIENT is the standard instruction used to exchange data with a Modbus TCP server. From TIA Portal V14 onward it ships in the "Instructions > Communication > Modbus TCP" palette. Earlier versions ship MB_CLIENT as part of the "MODBUS TCP" library V1.0; the two implementations are functionally identical at the Modbus application layer but differ in how they manage the underlying TCON connection.

STATUS Code Reference

The STATUS output of MB_CLIENT uses the same encoding scheme as the rest of the S7-1200 communication instruction set. The table below lists the codes most often encountered while commissioning a Modbus TCP link.

Verification

After applying the fix, verify the connection through the following checks:

1. Online diagnostics. In TIA Portal, go online with the CPU, open the connection DB, and confirm the Connection variable's Status field (if exposed) transitions to 16#0000 (idle) and 16#7000 (no call) between transactions.
2. Watch table. Open a watch table on the MB_CLIENT instance DB. Force REQ = TRUE. Observe DONE = TRUE, BUSY = FALSE, ERROR = FALSE, STATUS = 0 on the next cycle. The DATA_PTR area should contain the values read from the server.
3. Connection diagnostics view. In the project tree, expand "Devices & networks > CPU > Online & diagnostics > Diagnostics > Connections". The TCON connection should show state "Established" and a non-zero data throughput counter.
4. Server-side log. Check the Modbus TCP server's diagnostic page (sensor hub, gateway, SCADA node). The server should record a successful incoming connection from the CPU's IP and at least one FC03 (read holding registers) or FC16 (write multiple registers) transaction.
5. Network capture. On a managed switch, mirror the port connected to the CPU and capture traffic with Wireshark. Filter for tcp.port == 502 and verify the TCP three-way handshake, the Modbus PDU exchange, and the TCP teardown are visible.

If any of the above checks fail, refer to the troubleshooting matrix below.

Extended Troubleshooting Matrix

The matrix below lists common failure modes encountered when commissioning a Modbus TCP link between an S7-1200 CPU 1215 and a third-party server. Use it to triage any persistent errors after applying the TCON_IP_V4 fix.

Performance and Timing Considerations

Modbus TCP transactions on the S7-1200 CPU 1215 are handled by the PROFINET interface firmware, not by user program scan time. A single read of 10 holding registers typically completes in 10–30 ms on a gigabit network. The relevant timing parameters are:

For high-throughput applications, the bottleneck is the single-threaded Modbus client. If more than 50 transactions/second are required, consider a CPU 1217C with firmware v4.4 or later, which supports up to 8 simultaneous Modbus connections.

Field-Commissioning Checklist

Use this checklist during a site commissioning to confirm the configuration is correct before powering the controller into production.

1. CPU firmware v4.0 or later installed. Verify under "Online & diagnostics > Diagnostics > General".
2. TIA Portal V14 or later installed on the engineering station.
3. Connection DB created with the TCON_IP_V4 system data type. Field values match the table in Step 2.
4. MB_CLIENT CONNECT_ID points to the connection DB's ID field.
5. DATA_PTR points to a DB large enough to hold MB_DATA_LEN elements (2 bytes per register for FC03 / FC16, 1 bit per coil for FC01 / FC02 / FC15).
6. REQ is pulsed (rising edge) on a controlled cadence, not held high.
7. DISCONNECT = FALSE in normal operation.
8. Watch table confirms DONE pulses, ERROR = FALSE, STATUS transitions through 7000 / 0000.
9. Server-side diagnostic page shows the S7-1200 as a connected client.
10. Wireshark capture (if available) shows the expected Modbus PDU sequence.

Frequently Asked Questions