Resolving S7-1500 MB_CLIENT Status 7002/7006 Modbus TCP Errors

Problem Overview

Field engineers integrating an AccuEnergy Vista Touch Power 3-phase power meter (or any Modbus TCP server) with a Siemens SIMATIC S7-1515-2 PN CPU frequently encounter a situation in which the MB_CLIENT instruction never completes a transaction. The block sits indefinitely at status 7002 (connection establishment in progress), occasionally advances to 7004 (request sent, no response), and most often lands on 7006 (waiting for response after a successful send). On Wireshark, the engineer observes the PLC sending an SYN to the meter and receiving an RST, ACK back, even though the meter responds to ICMP ping without issue.

This is not a PROFINET fault. PROFINET and Modbus TCP share the same IEEE 802.3 physical layer but they occupy different protocol stacks above it. The PLC is performing standard Modbus TCP client communication over Ethernet, exactly the same way it would talk to any TCP server. The connection failures are typically the combined result of:

• Incorrect MB_CLIENT instance data block parameter assignment (especially the TCON_IP_V4 structure inside the CONNECT parameter)
• Active CPU access protection in TIA Portal blocking Modbus TCP connection establishment
• Host-side Windows firewall on the engineering station or domain policy on the meter side
• Network infrastructure issues (managed switch port blocking, VLAN mismatch, mirroring configuration)
• Meter firmware behavior on simultaneous or rapid requests

This reference covers the full diagnostic tree, parameter tables, status code meanings, and the step-by-step field procedure to bring the link up reliably.

MB_CLIENT Status Code Reference

The MB_CLIENT instruction is delivered inside the MODBUS_PN library (program block name MB_CLIENT, instance DB "MB_CLIENT_DB") for S7-1500 CPUs. The DONE, BUSY, and ERROR outputs in combination with the STATUS word identify the exact fault stage. The most relevant values for this scenario are:

The persistent 7002/7006 pairing almost always points to a TCP-level reset rather than a Modbus-level rejection. A Modbus exception would surface as 0x838x. The 0x8187 ("no usable connection") and 0x8188 ("connection not established") codes are the real smoking gun and they are typically what is masked when the block stalls at 7002/7006 with a stale REQ edge.

PROFINET and Modbus TCP: Same Cable, Different Stacks

It is essential to separate PROFINET from the physical Ethernet medium. PROFINET uses Ethernet as a transport (real-time channels on top of standard Ethernet), and Modbus TCP also runs on standard Ethernet using TCP port 502. The two protocols do not interact; an S7-1500 CPU such as the 6ES7515-2AM02-0AB0 can simultaneously be a PROFINET controller on the same switch fabric and a Modbus TCP client to a non-PROFINET device. There is no PROFINET slot, no PROFINET device name, no GSDML file required for the meter.

Root Cause Analysis: Why the Meter Returns RST

The combination of "ping works, but the meter sends RST, ACK to the TCP SYN from the PLC" has a small number of mechanical causes. Walk through this checklist in order before changing any code:

1. Meter port mismatch. The Vista Touch Power supports both Modbus TCP and Modbus RTU; the configuration must explicitly set Modbus TCP = TRUE and the listening port to 502. A common mis-configuration is leaving the port at 503, 10502, or another non-default value while the TCON_IP_V4 RemotePort in TIA is set to 502. The meter then refuses the connection with a TCP reset.
2. CPU access protection in TIA Portal. The CPU's "Connection mechanisms" must allow Modbus TCP. With TIA Portal V17/V18/V19, the relevant setting is CPU Properties > Protection & Security > Connection mechanisms. The following must be true: "Permit access with PUT/GET communication from remote partner" = enabled, and there must be no read-only password level that blocks the open user communication channel. The error symptom of 7002/7006 with RST is the textbook result of an open-user-communication block being denied by the protection level.
3. Engineering station firewall. The PC that the engineer is running Wireshark and QModMaster on is a different node from the meter. If that machine is the only PC allowed to reach the meter on a corporate network, the issue is in the corporate policy, not on the PLC. To rule this in or out, isolate the meter and PLC on a dedicated switch.
4. Meter state. Many Modbus TCP meters only accept a single open TCP connection. If QModMaster left a stale connection, the meter may be in a half-open state and reject the next SYN with RST until the meter times out internally (the Vista Touch has a configurable timeout in seconds; 1000 s on this site is unusually high and is likely a UI display issue, not the real value).
5. VLAN / managed switch policy. A managed switch may block TCP/502 or apply broadcast suppression that fragments the TCP handshake. Mirror-port analysis should show the same RST whether captured on the PLC port or the meter port; if only one side shows RST, the switch is the culprit.
6. PLC IP and subnet. The CPU must be on the same subnet as the meter. 192.168.12.124/24 with gateway 192.168.12.1 means the PLC must have an address in 192.168.12.0/24 with no conflicting ARP entry. Verify with Online & Diagnostics > Accessible nodes in TIA Portal.

TIA Portal Project Configuration

2.1 Required Software

• TIA Portal V18 or V19 with the matching SIMATIC S7-1500 CPU HSP. Earlier versions (V16, V17) are supported but require the MODBUS_PN library V2.x to be installed separately; V18+ ships the library in the standard palette.
• CPU firmware V2.9 or higher for 6ES7515-2AM02-0AB0. The Modbus TCP PN block is supported on all S7-1500 CPUs from FW V1.5 onward, but the MB_CLIENT V6.x block version requires FW V2.5+ for full status code coverage.

2.2 CPU Protection & Security Settings

Open the CPU device configuration, navigate to Properties > Protection & Security > Connection mechanisms, and verify the following:

• Permit access with PUT/GET communication from remote partner = ticked (this is the setting that opens the open-user-communication channel for MB_CLIENT).
• Permit access with Siemens communication (load monitor, etc.) = allowed as required by your environment.
• The access password protection level must be "No password (full access)" or "Write-protected" with a known password; "Read/write protect" will block the connection.

Compile and download the hardware configuration. A runtime change to these settings requires STOP-to-RUN transition or full download in RUN.

2.3 Open User Communication Resource Limits

Each S7-1500 CPU has a maximum number of simultaneous open-user-communication connections (defined per firmware; typical values are 64 for the CPU 1515-2 PN). Modbus TCP uses one connection per MB_CLIENT instance. If you have multiple MB_CLIENT instances or other TCON-based instructions, verify the total is below the limit in Properties > Communication > Open User Communication.

MB_CLIENT Instruction Configuration

Drop MB_CLIENT from the Instructions pane (under Communication > MODBUS_PN) into a cyclic OB, ideally OB1. The instance DB is created automatically. The key parameters and their correct values for this scenario are:

3.1 The CONNECT TCON_IP_V4 Structure

The CONNECT parameter is a TCON_IP_V4 structure. In the project's data types, declare a PLC data type (UDT) and instantiate a DB of it. The fields must be set as follows for the Vista Touch scenario:

// UDT "VistaTouch_Connect" of type TCON_IP_V4
InterfaceId      : BYTE  = 16#01   // IPv4
Id               : WORD  = 1       // Local connection ID, must be unique
ConnectionType   : BYTE  = 16#0B   // 0x0B = TCP/IP native
ActiveEstablished: BOOL  = TRUE    // PLC is the active opener
RemoteAddress    : ARRAY[1..4] OF BYTE = (192, 168, 12, 124)
RemotePort       : UINT  = 502     // Modbus TCP standard port
LocalPort        : UINT  = 0       // 0 = let CPU assign
LocalAddress     : ARRAY[1..4] OF BYTE = (192, 168, 12, x) // PLC IP octets

Three of these fields are commonly mis-configured:

• RemotePort = 502. The meter is the Modbus server; it listens on 502. If the meter is configured for 503 or 10502, the connection will be RST'd. Verify in the meter's web UI under Modbus TCP settings.
• LocalAddress must match the CPU's PROFINET interface IP exactly. A wrong local IP does not produce 7002; it produces 0x80C7 (IP resolution error). But leaving LocalAddress as (0,0,0,0) and the Local TSAP-based addressing variant selected will produce 0x8187 in some firmware versions.
• Id is the local connection handle. If a previous test left an open connection with the same ID, the next call may not establish a fresh socket. Increment Id by 1 if you have been experimenting with the project and getting 8187/8188.

Wireshark Diagnostic Methodology

Wireshark on a mirror port is the single most useful tool. Apply the following filter to remove noise:

ip.addr == 192.168.12.124 and (tcp.port == 502 or icmp)

Walk through the captured handshake:

1. PLC sends SYN, meter replies SYN, ACK, PLC sends ACK → connection is open. If you do not see this three-way handshake, the meter is not seeing the PLC's IP at all. Check the switch port and VLAN.
2. PLC sends SYN, meter replies RST, ACK → the meter received the SYN but the destination port is closed or the connection table is full. This is what the original poster observed. The most likely causes: (a) meter port is not 502, (b) meter has not finished its Modbus TCP initialization, (c) meter firmware rejects the source IP via a security list.
3. Full three-way handshake completes, no Modbus data follows → the REQ edge is not being seen by MB_CLIENT. The PLC never sends a Modbus PDU. Verify in TIA Portal that the instance DB is not being overwritten by another block.
4. Modbus request sent, no response, TCP FIN or RST later → meter is busy or rejected the function. Look for Function Code 0x83 (Modbus exception) in the response; if absent, the meter is dropping the packet silently.

When capturing, place a managed switch in mirror mode with both PLC and meter ports mirrored to the engineering PC. Do not put the engineering PC in-line between PLC and meter; that creates a transparent bridge and can cause double-NAT issues with the S7-1500's keep-alive timers.

Firewall and Security Layer Analysis

The Siemens CPU's built-in firewall in TIA Portal's Protection & Security &em> IP firewall is the first place to look. By default, the IP firewall is permissive on the PROFINET interface, but if a project has previously added rules for OPC UA or other protocols, those rules may block TCP/502. Open CPU Properties > Protection & Security > IP firewall and inspect:

• Rule sets in the active table — any DROP or REJECT rule for inbound TCP to port 502 must be removed for the meter subnet.
• The "Access to the CPU via HTTPS/Modbus/OPC UA" checkboxes must allow open user communication.

For the engineering station, run the following PowerShell commands to rule in or out a Windows host firewall even if the standard UI is locked:

Get-NetFirewallProfile | Select Name, Enabled
Get-NetFirewallRule -Direction Inbound -Enabled True -Action Block | Select DisplayName, Profile
# Test raw TCP open to the meter (uses port 502)
Test-NetConnection -ComputerName 192.168.12.124 -Port 502

Test-NetConnection -Port 502 returning TcpTestSucceeded : True confirms the meter is listening on the same port the PLC is dialing. If it returns False, the meter side has a problem (port mismatch, meter busy, ACL on the corporate network, or the meter is genuinely not in Modbus TCP mode). The PLC side of the firewall should also be tested by removing the meter subnet from the engineering PC and pointing MB_CLIENT to a known-good Modbus server tool (e.g., the Modbus Doctor emulator from WinTech) on a laptop with the Windows firewall off completely. If the link works to the emulator and not to the meter, the problem is the meter or the network path to it, not the PLC code.

Step-by-Step Resolution Procedure

Follow this procedure in order. Do not skip steps. A structured walkthrough of this kind typically resolves 90 % of "MB_CLIENT stuck" cases in under an hour.

6.1 Build the bench-top test

1. Connect a Windows laptop directly to the S7-1500 CPU's PROFINET port X1 with a standard Ethernet cable (crossover is not required on modern S7-1500 interfaces).
2. Set the laptop IP to 192.168.12.50/24, no gateway, no DNS. Disable every firewall profile on the laptop, including public, private, and domain. Disable antivirus network filtering where corporate policy allows.
3. Install a Modbus TCP server emulator on the laptop (e.g., "Modbus Tools" from WinTech, "Modbus Poll" server mode from Witte Software, or the open-source diagslave tool).
4. Configure the emulator to listen on port 502, slave ID 1, with a few writable holding registers.

6.2 Validate PLC ↔ PC link

1. Set up MB_CLIENT in TIA Portal with the laptop's IP (192.168.12.50) and the Modbus emulator parameters.
2. Compile, download, and go to RUN.
3. Trigger REQ from a tag. Observe STATUS: it should sweep 7001 → 7002 → 7003 → 7004 → DONE in well under a second for a 10-word read.
4. If it does, the PLC side is healthy. Move to step 6.3.
5. If it does not, fix the PLC side first: check the access protection, the IP firewall, and the local IP in TCON_IP_V4.

6.3 Insert the meter in the same isolated network

1. Re-cable: PLC ↔ dumb switch ↔ meter. Use a passive 5-port unmanaged switch. Place the engineering laptop on the same switch.
2. Verify the meter still answers ping from the laptop. If not, the meter is mis-configured at the IP layer.
3. Run the Wireshark capture with the filter tcp.port == 502.
4. Trigger MB_CLIENT in the PLC.
5. Inspect the capture. You are looking for: SYN, SYN-ACK, ACK, then a Modbus 0x00 0x00 0x00 0x00 0x00 0x06 0x01 0x03 ... query from the PLC, then a response with the same transaction ID from the meter.
6. If the capture still shows RST, ACK, the meter is rejecting the connection. Verify the meter's Modbus TCP mode and port with a different tool — point the laptop's Modbus client at the meter and confirm the meter accepts the connection from the laptop. If the laptop succeeds and the PLC fails, swap the meter for a known-good unit or update the meter firmware.

6.4 Restore the production network

1. Once the meter ↔ PLC link works on the isolated switch, re-introduce the managed switch one segment at a time.
2. Add port-level ACLs allowing TCP/502 from the PLC IP to the meter IP only.
3. Enable the engineering PC firewall again, but add an explicit rule to permit Wireshark and the engineering tool. The PLC does not need any change.
4. Reconnect the corporate network last; this is the layer most likely to break the link via proxy ARP, deep packet inspection, or a Windows GPO that pushes firewall rules.

Verification and Acceptance Test

Once the link is up, perform a sustained communication test:

1. Run a 1 Hz cyclic read of a known register (e.g., voltage L-N, 40001) for 24 hours.
2. Log MB_CLIENT.STATUS, ERROR, and the data quality word in a data log.
3. Expected outcome: STATUS cycles 0 → 7001 → 7003 → 7004 → 0, with ERROR = 0 throughout. A periodic 8187 followed by automatic reconnection is acceptable on a noisy industrial network, but the time-to-reconnect must be < 5 s.
4. Inspect Wireshark at the 1-hour, 6-hour, and 24-hour marks. The expected traffic is one MBAP query and one response per second, no retransmits, no RSTs. Any RST after the link has been running for > 30 s indicates a meter firmware issue or a network device killing idle TCP sessions.

Hardware Platform Notes and Field Caveats

• S7-1500 vs. S7-1200: the procedure above applies to both, but the S7-1200 MB_CLIENT V3.x has a smaller status code set. The 8187/8188 codes were added in V4.0 of the instruction library; older projects may need the library upgraded to expose them.
• Firmware compatibility: the MODBUS_PN library is firmware-version tagged. The library version that ships with TIA Portal V18 supports S7-1500 FW V2.5 and up. If the CPU is at FW V2.0 or lower, install the matching older MODBUS_PN package from the Siemens Online Support portal.
• CPU 1515-2 PN resource limits: the 1515 has a hard limit of 64 active open-user-communication connections. MB_CLIENT consumes one ID. TSEND_C and TRCV_C also consume IDs. Plan the ID space before deploying.
• TCP keep-alive: the S7-1500 sends TCP keep-alives by default at 30 s intervals. Some meters' embedded TCP stacks close the socket after 60 s of idle. The MB_CLIENT will reconnect automatically on the next REQ edge, so this is benign in polled mode but can produce bursty traffic in publish-subscribe patterns.
• Vista Touch firmware: the AccuEnergy meter's Modbus TCP implementation has historically had issues with the embedded web server hogging the same port. Update the meter firmware to the latest available release on the AccuEnergy support site before opening a case.