Resolving MB_Client Multi-Instance Errors on S7-1200 Modbus TCP

Problem Overview

Calling the same S7-1200 Modbus TCP function block (FB) twice from OB1 in TIA Portal V14 produces one of two visible failure modes:

• Output overwrite: Both call sites display the same response data, and the second call overwrites the first call's tags before the application can read them.
• Error 80A3: Active connection resource already exists. The MB_CLIENT returns STATUS = 16#80A3 when the FB is reorganized as a multi-instance block inside a wrapper FB and a second instance is opened against the same remote IP and port.

Both symptoms have the same root cause: global resources shared between the two calls. The MB_CLIENT FB reads its connection state, request buffer, and internal handshake bits from a single instance data block; when two calls share the same DB (or, worse, share absolute M-bits or OB-tag globals), the runtime cannot tell them apart. The S7-1200 CPU does not duplicate the TCP connection resources, so the second CONNECT primitive collides with the first.

Root Cause Analysis

How MB_CLIENT Manages State

The MB_CLIENT instruction is an FB published in the Siemens Modbus TCP library (instruction library "Communication Processor and Modbus TCP"). It encapsulates the open user communication blocks (TCON, TSEND, TRCV, TDISCON) plus a small state machine that:

1. Resolves the TCON_IP_V4 connection descriptor.
2. Transitions REQ rising edges into a Modbus PDU.
3. Demultiplexes the incoming PDU back to the configured MB_MODE / MB_DATA_ADDR pair.
4. Exposes DONE, BUSY, ERROR, and STATUS.

All of this state lives in the instance DB that TIA Portal generates when the FB is dropped onto a network. If you call the same FB symbol from two networks and the compiler emits a single instance DB, both calls operate on the same memory and the active job gets clobbered. The symptom is the output-overwrite case described in the original report.

Why Error 80A3 Appears After Multi-Instance Conversion

When the engineer converts the wrapper FB to a multi-instance block (i.e., declares the MB_CLIENT as a STAT variable inside the parent FB), TIA Portal still generates a DB per parent FB call. Each parent-instance gets its own MB_CLIENT instance DB, which means each call attempts to open its own TCP connection. The S7-1200 user-communication stack rejects the second TCON with status word W#16#80A3 (Connection already established) because:

• The connection descriptor uses the same RemoteAddress / RemotePort.
• The connection descriptor uses the same ID field (the TCON connection ID).

Per the Siemens S7-1200 system manual, the connection ID is a 16-bit identifier unique within the CPU project. Reusing it for two simultaneously-open TCP sockets to the same partner is rejected by the communication resource manager.

Hidden Cause: Globals Inside the FB

The expert response in the field report flags a second, often-overlooked issue: any reference to global M-bits, inputs/outputs, or OB1 temporary tags inside the FB body destroys re-entrancy. Modbus TCP FBs that read or write %M0.0 directly cannot be safely instantiated twice, because both calls will toggle the same bit. Re-entrancy must rely entirely on the instance DB (variables declared in VAR / STAT sections).

Solution Architectures

Three patterns solve the problem. Choose based on whether you need true parallel polling or can serialize the requests.

Pattern A: Sequential Requests on a Single Shared MB_CLIENT Instance

Per the official TIA Portal "Example MB_CLIENT 1: Multiple requests with a common TCP connection" documentation, multiple Modbus client requests can be sent over the same TCP connection by reusing the same instance DB, connection ID, and remote port. Only one request is active at a time; the application triggers REQ when the previous job is complete. This is the lowest-overhead solution and is the recommended default.

Implementation in LAD:

1. Drop one MB_CLIENT FB into OB1; accept the auto-generated instance DB (e.g., MB_CLIENT_DB).
2. Create two input structures (REQ1, REQ2) that share the same FB instance but feed different MB_MODE / MB_DATA_ADDR values.
3. In OB1, use a small state machine that asserts REQ for request 1, waits for DONE, copies the result, then asserts REQ for request 2.

Sample ST fragment showing the state machine:

// Cyclic OB1 segment
IF "mbState" = 0 THEN
    "mbClient".REQ := TRUE;
    "mbClient".MB_MODE := 1;          // Read Coils
    "mbClient".MB_DATA_ADDR := 0;     // Coil 0
    "mbClient".MB_DATA_LEN := 1;
    IF "mbClient".DONE THEN
        "coil0Value" := "mbClient".MB_DATA_BUF[1];
        "mbState" := 1;
    ELSIF "mbClient".ERROR THEN
        "mbState" := 99;              // Error handler
    END_IF;
ELSIF "mbState" = 1 THEN
    "mbClient".REQ := TRUE;
    "mbClient".MB_MODE := 1;
    "mbClient".MB_DATA_ADDR := 16;    // Coil 16
    "mbClient".MB_DATA_LEN := 1;
    IF "mbClient".DONE THEN
        "coil16Value" := "mbClient".MB_DATA_BUF[1];
        "mbState" := 0;
    ELSIF "mbClient".ERROR THEN
        "mbState" := 99;
    END_IF;
END_IF;
"mbClient".REQ := FALSE;

Pattern B: Two Separate MB_CLIENT Instances with Unique Connection IDs

Use this when the application needs to keep both TCP sockets live (for example, one against a primary PLC and one against a redundant partner, or two independent slaves on different IPs). Each instance requires:

Configure the connection descriptors in the TCON_IP_V4 DB before downloading. The S7-1200 supports up to 16 active Open User Communication connections on CPU firmware 4.x; the exact maximum depends on the CPU order number and is documented in the S7-1200 System Manual.

Pattern C: Multi-Instance DB Inside a Wrapper FB

If the goal is to ship a "Modbus read coil" toolbox FB that the user drops into OB1 multiple times, package MB_CLIENT as a static member of a wrapper FB. Each call site generates a new instance DB for the wrapper, which in turn allocates a new MB_CLIENT instance DB internally.

FUNCTION_BLOCK "FB_ModbusReadCoil"
VAR
    mbClient : MB_CLIENT;          // Static; multi-instance
    lastDone : BOOL;               // Per-instance latches
    lastError : BOOL;
    lastStatus : WORD;
END_VAR
BEGIN
    mbClient(REQ := REQ_IN,
             DISCONNECT := FALSE,
             MB_MODE := 1,
             MB_DATA_ADDR := ADDR_IN,
             MB_DATA_LEN := 1,
             CONNECT := CONNECT_DESC,
             MB_DATA_BUF := DATA_BUF);
    
    IF mbClient.DONE THEN
        DONE_OUT := TRUE;
        lastDone := TRUE;
    END_IF;
    IF mbClient.ERROR THEN
        ERROR_OUT := TRUE;
        lastError := TRUE;
    END_IF;
    STATUS_OUT := mbClient.STATUS;
END_FUNCTION_BLOCK

Call it twice in OB1:

"instReadCoil_0"(REQ_IN := req0,
                ADDR_IN := 0,
                CONNECT_DESC := connDesc0,
                DONE_OUT => done0,
                ERROR_OUT => err0,
                STATUS_OUT => stat0);

"instReadCoil_1"(REQ_IN := req1,
                ADDR_IN := 16,
                CONNECT_DESC := connDesc1,
                DONE_OUT => done1,
                ERROR_OUT => err1,
                STATUS_OUT => stat1);

For Pattern C, each instance must still receive a unique connection ID in its connDesc. The wrapper does not absolve the underlying TCP socket uniqueness rule.

Step-by-Step Fix for Error 80A3

Prerequisites

• STEP 7 Basic / TIA Portal V14 SP1 or later (V16 recommended for current firmware targets).
• S7-1200 CPU with firmware 4.2 or later (firmware 4.4 required for some Modbus library updates).
• Modbus TCP instruction library installed: Instructions → Communication → Communication Processor → MODBUS TCP.
• Reachable partner on TCP port 502 (or user-defined).

Procedure

1. Audit the FB body. Open the FB in question and use Find → Find in code to search for any absolute address (%M, %I, %Q, DB with hard index). Replace each with an IN_OUT, STAT, or TEMP variable of the FB.
2. Confirm the instance DB layout. Right-click the MB_CLIENT symbol in OB1, choose Properties → Information, and note the instance DB number. In the project tree, right-click Program blocks → Show block structure to verify only one instance DB exists per FB symbol.
3. Decide on Pattern A, B, or C. Pick sequential sharing if both requests target the same Modbus server. Pick unique instances if requests go to different servers or you need concurrent sockets.
4. For Pattern A: Create a small cyclic state machine that toggles between two MB_MODE / MB_DATA_ADDR combinations against one FB instance. Confirm both coils update at half the per-request scan rate (acceptable for most polling applications).
5. For Pattern B: Add a second MB_CLIENT call. TIA Portal will create MB_CLIENT_DB_2 automatically. Open the new instance's CONNECT parameter and assign ConnectionID := 2, unique RemoteAddress, and matching RemotePort.
6. For Pattern C: Verify each instance of the wrapper FB compiles to its own DB. In the project tree, the Program blocks folder should show one DB per instance (e.g., DB_FB_ModbusReadCoil_1, DB_FB_ModbusReadCoil_2). Confirm in the call environment that the CONNECT_DESC input for each call uses a unique ConnectionID.
7. Download to the CPU with Stop → Download → Run. TIA Portal will reset retained tags; acknowledge the prompt.
8. Go online and add the instance DBs to a watch table. Force REQ := TRUE for one cycle and observe STATUS returning 16#0000 on success or the standard Modbus exception codes on failure.

Verification

After applying one of the three patterns, verify the fix with the following checks:

Troubleshooting Matrix

Modbus TCP Library Compatibility Notes

The Modbus TCP instruction library ships with several revisions; check the version installed via Project → Libraries → Show library versions:

Projects created in TIA V14 with v2.0 of the MB_CLIENT library benefit from multi-instance support, which is the cleanest path for Pattern C. Older V11/V12 projects often need to be migrated and re-compiled against the newer instruction versions to gain the same capabilities.

Standards Reference

Modbus TCP behavior is defined by:

• MODBUS Messaging on TCP/IP Implementation Guide V1.0b — specifies port 502 as the well-known Modbus port and PDU/ADU framing rules. Available from the Modbus Organization.
• IEC 61158 (Industrial Communications) — referenced by Siemens for the underlying TCP transport, though Modbus TCP is not a CIP/EtherNet/IP protocol.
• RFC 793 (TCP) and RFC 791 (IP) — define the transport layer used by every Modbus TCP connection. Siemens does not alter these; the S7-1200 follows standard TCP state transitions.

Connection-ID semantics are Siemens-specific and not part of the Modbus standard; they live in the S7-1200 communication resource manager and are documented per the SIMATIC S7-1200 Programmable Controller System Manual.

Edge Cases and Field-Proven Caveats

• Firewall default: CPU firmware 4.x ships with the built-in firewall enabled in "Advanced" mode. TCP port 502 inbound is blocked by default; you must create an explicit rule for the partner IP range.
• Partner reset: When the partner PLC powers cycles, MB_CLIENT transitions through 16#80A2, then 16#80A4, then auto-reconnects on the next REQ. Do not call DISCONNECT manually unless intentionally tearing the socket down.
• Cycle-time budget: Each Modbus TCP transaction typically consumes 10-25 ms on a 1214C/1215C CPU depending on scan load. Pattern A doubles the effective poll latency compared to a single-instance single-request application; budget accordingly.
• Watchdog risk on long DBs: If the user wraps the entire MB_CLIENT inside an FB with extensive ST logic, the resulting instance DB can exceed 1 KB. Watch the CPU's online memory budget; small CPUs (CPU 1211C, CPU 1212C) have tighter work-memory limits than 1215C and 1217C.
• Symbolic vs. absolute addressing: When copying the wrapper FB, always use Copy → Paste with reference disabled, so TIA Portal generates a fresh instance DB. A reference-pasted FB will share the original DB and reintroduce the original symptom.

Frequently Asked Questions