S7-1500 MB_CLIENT Status 7002: Resolving Modbus TCP Connection

1. Problem Overview: MB_CLIENT Permanently Stuck on Status 7002

The MB_CLIENT instruction on a SIMATIC S7-1500 (CPU 1512 SP FW ≤ V2.x with TIA Portal V13 SP1) reads a constant status word of 16#7002 (decimal 28674) while attempting to reach a Modbus TCP server hosted on a PC. The instruction never transitions to 16#818C (timeout, server unreachable) and never reports a TCP-level error such as 16#80A1 or 16#80A4. The same S7-1500 configured as a Modbus server using MB_SERVER against the same PC (running Modscan) responds normally. This asymmetric fault is the classic signature of an outbound connection that the kernel TCP stack cannot complete because the remote endpoint never completes the three-way handshake, while no ICMP unreachable / RST is generated back to the CPU.

Status 7002 corresponds to the on-the-wire state "Connection being established." Because TIA Portal V13 SP1's MB_CLIENT internal implementation waits on a passive SYN-ACK from the target and the connection-establishment retry window is bounded only by the OS-level connect timeout, the instruction can remain in 7002 for the full TCP retransmit lifetime (typically 60-120 s on the S7-1500 PROFINET stack) and then return to a steady 7002 instead of surfacing 818C if the underlying socket was re-armed by the background OUC (Open User Communication) task. This makes 7002 look stuck even though the connection attempt is still alive in the background.

2. System Configuration and Topology

The reference configuration that reproduces the issue is documented below.

3. MB_CLIENT Connection Parameters Reference

The instance DB written by MB_CLIENT_DB contains the static connection parameters. The values entered for the failing case must be checked item by item.

4. Modbus TCP Client Status Code Dictionary

Status is reported on the STATUS (WORD) output of MB_CLIENT. The TIA Portal V13 SP1 help and the Modbus/TCP function manual describe the codes as follows.

5. Root Cause Analysis: Why Status 7002 Never Transitions

There are seven realistic root causes that produce exactly the observed symptom of permanent 7002 with no 818C. The diagnostic procedure below tests each.

5.1 Wrong Remote IP (Most Common)

Modsim may be listening on 127.0.0.1 only, or the PC's active interface may not be 192.168.0.1. Open a Windows command prompt on the PC:

ipconfig /all
netstat -ano | findstr :502

The netstat output must show a line with [192.168.0.1]:502 in LISTENING state. If it shows [0.0.0.0]:502 or [127.0.0.1]:502 the server is reachable but may not be the right interface. If only [127.0.0.1]:502 appears, Modsim is bound to the loopback and the S7-1500 will never reach it — the CPU's SYN will elicit no reply, hence no RST and therefore no 80A4. The status stays in 7002.

5.2 Windows Firewall Blocking Inbound TCP/502

Windows Firewall with Advanced Security silently drops unsolicited inbound TCP unless an allow rule exists. Because no RST is returned to the CPU, the S7-1500 stack keeps retransmitting SYN and reports 7002. Validate by temporarily disabling the firewall:

If the connection establishes immediately, add a permanent inbound allow rule:

5.3 Modsim Not Actually Listening on TCP/502

Modsim defaults to Modbus RTU on a serial port. To switch it to Modbus TCP/IP server:

1. Start Modsim.
2. Menu Connection → Connect → TCP/IP Server.
3. Confirm the listen port is 502 and the bind address is 0.0.0.0.
4. Click OK. The status bar must read "Listening on TCP/IP port 502."

If the wrong COM port or RTU mode was active, no TCP listener exists; SYN packets get no reply and 7002 persists.

5.4 ActiveEstablished Set to FALSE

If the engineer confuses the roles (PLC is supposed to be the client but the DB was built from the MB_SERVER template), ActiveEstablished is FALSE and ConnectionType = 11. The kernel TCON is configured as passive: it never sends a SYN. Status cycles 7002 → 7001 → 7002 and never connects. Fix: set ActiveEstablished = TRUE for the client DB.

5.5 Duplicate ID Across Multiple MB_CLIENT Instances

When two clients are required against the same server, both must use the same RemoteAddress but different ID values (e.g. ID=2 and ID=3) and ideally different LocalPorts. Sharing ID is not an error on download, but the second TCON is rejected by the kernel and the second MB_CLIENT is starved of its socket. The visible symptom on the second instance is identical to the 7002 hang.

5.6 IP Routing Failure on the PC Side

If the PC has multiple NICs (e.g. one wired to the CPU at 192.168.0.1 and one wireless at 10.0.0.50), the SYN from the CPU may be answered by the wrong interface or simply routed nowhere. In route print confirm that 192.168.0.0/24 has the local NIC as the only route.

5.7 TIA Portal Project Not Fully Downloaded

Online → Download to device with "All" blocks selected. Partial downloads (only the FB but not the instance DB) leave the CPU running an older MB_CLIENT that references a stale connection DB. Right-click the PLC → Download and reset program identifier if necessary.

6. Step-by-Step Resolution Procedure

Execute the following checks in order. Each step takes less than one minute.

Step 1 — Verify the Server Is Listening

1. On the PC, open Command Prompt (Admin).
2. Run netstat -ano -p TCP | findstr :502.
3. Confirm a row in state LISTENING exists with LocalAddress containing 0.0.0.0:502 or 192.168.0.1:502.
4. If absent: switch Modsim to TCP/IP Server (menu Connection → TCP/IP Server) and restart.

Step 2 — Validate End-to-End Reachability with a PC Ping

1. From the PC, ping the CPU: ping 192.168.0.10.
2. From the CPU's online → Diagnostics, use Online & diagnostics → PROFINET interface → Ping to ping 192.168.0.1.
3. If either fails, fix the physical link first — no Modbus layer work helps.

Step 3 — Temporarily Disable the Firewall

1. Run netsh advfirewall set allprofiles state off.
2. Set REQ = TRUE on MB_CLIENT.
3. Watch the STATUS tag. If it transitions to 7003 within 3 s, the firewall was the cause.
4. Re-enable: netsh advfirewall set allprofiles state on and add the inbound allow rule from §5.2.

Step 4 — Verify the MB_CLIENT Instance DB

1. In TIA Portal, open the MB_CLIENT instance DB.
2. Confirm ActiveEstablished = TRUE, ConnectionType = 16#0B (decimal 11).
3. Confirm RemoteAddress[1..4] = 192,168,0,1.
4. Confirm RemotePort = 502.
5. Confirm InterfaceId = 64.

Step 5 — Force a Full Reload

1. Online → Download to device → select All (not "Software" only).
2. After download, place the CPU in STOP, then back to RUN to reinitialize all OUC resources.
3. Trigger REQ and observe STATUS.

Step 6 — Capture the Handshake

1. On the PC, install Wireshark (free, vendor-neutral).
2. Apply a display filter: tcp.port == 502 and ip.addr == 192.168.0.10.
3. Trigger REQ on the CPU.
4. Expected frames in order: [SYN] CPU → PC, [SYN, ACK] PC → CPU, [ACK] CPU → PC.
5. If only SYN appears with retransmissions and no SYN-ACK ever returns, the server is not listening on the interface the SYN reached.
6. If RST returns from the PC, STATUS will go to 80A4, confirming a TCP-level refusal, not a Modbus-layer issue.

Step 7 — Add an Operator-Side Watchdog

While the TCP stack's connect timeout is fixed and not user-configurable, you can wrap MB_CLIENT with an application watchdog so the HMI does not show "Connecting..." forever.

// ST pseudocode
IF MB_CLIENT_INSTANCE.STATUS = 16#7002 THEN
    TIMER_7002(IN := TRUE, PT := T#10s);
    IF TIMER_7002.Q THEN
        // Force disconnect and reconnect
        MB_CLIENT_INSTANCE.DISCONNECT := TRUE;
        TIMER_RECONNECT(IN := TRUE, PT := T#2s);
        IF TIMER_RECONNECT.Q THEN
            MB_CLIENT_INSTANCE.DISCONNECT := FALSE;
            MB_CLIENT_INSTANCE.REQ := TRUE;
            TIMER_RECONNECT(IN := FALSE);
            TIMER_7002(IN := FALSE);
        END_IF;
    END_IF;
END_IF;

7. Verification and Field Diagnostics

After the corrective action, confirm a healthy loopback:

7.1 Quick Diagnostic Decision Matrix

8. Common Pitfalls and Cross-Platform Edge Cases

8.1 Port 502 Privileges on Windows

On Windows Vista and later, the IANA-assigned well-known port range (1-1023) can be bound by user-mode applications without administrator rights, but Modsim running as a non-elevated user may still fail to bind 502 silently. Always right-click → "Run as administrator" for Modsim if it is the only suspect.

8.2 Anti-Virus Software Replacing the Firewall

Corporate installations often run a third-party AV suite (Symantec Endpoint, McAfee, Kaspersky) that replaces Windows Firewall. The Windows Firewall check above will report off, yet the AV may still drop TCP/502. Consult the AV vendor's network shield allow-list documentation for the Modbus port.

8.3 Switching Port to Non-Standard

If port 502 is unreachable on the server side and cannot be opened, both sides can be moved to 5020 or similar. Update RemotePort in the PLC and Modsim's listen port accordingly. Do not run two Modbus services on the same port from the same PC.

8.4 Multiple Network Interface Cards (NICs)

If the PC has Wi-Fi and Ethernet, Windows sometimes sends replies from the wrong interface. Disable the unused NIC in Network Connections for the duration of the test to force traffic onto the wired link.

8.5 TIA Portal V13 SP1 Specific Bug

TIA Portal V13 SP1 Update 4 and earlier have a known issue where MB_CLIENT continues to show 7002 even after a successful connect, because the STATUS output is not refreshed until the next OB1 cycle of the OUC background task. Upgrading to Update 9 (or to TIA Portal V14 SP1 or later) is the long-term remediation. The S7-1500 Modbus/TCP function manual is documented in the Siemens support portal under the entry for the Modbus library for S7-1500 / ET 200.

8.6 Two Clients Sharing the Same Server

For each MB_CLIENT connection, a unique server IP address must be specified. If the design requires two PLCs to talk to the same Modbus server, each must use its own connection block and its own instance DB. Reusing the same ID across them is the most frequent cause of a 7002 on the second instance.

9. Frequently Asked Questions