Resolving MB_REDCL W#8304 Connection Errors on S7-400H Modbus TCP

1. Problem Description

When using the Siemens library block FB "MB_REDCL" (Redundant Modbus/TCP Client) on an S7-400H station with two CP 443-1 communications processors, the function block returns persistent error statuses W#16#8304 and/or W#16#A083 on the STATUS_0A / STATUS_1A outputs, the ERROR output is set, the DONE output never goes TRUE, and the error counter increments continuously even though the block is called cyclically in OB35 (for example, 50 ms cycle).

Typical symptoms reported in the field:

• DONE never becomes TRUE.
• ERROR is set immediately on the first call.
• STATUS_0A = W#16#8304 (no connection to the partner).
• STATUS_0A = W#16#A083 (TCP error during send/receive).
• Error counter (COUNT_ERROR) increments every OB35 cycle, Done counter stays at 0.
• Reducing the OB35 period (e.g., 20 ms or 100 ms) does not change the behavior.

Almost all such incidents share a common root cause category: the TCP connection between the S7-400H CP 443-1 and the Modbus/TCP server is not actively established from the SIMATIC side, and/or the rising-edge trigger at ENQ is re-asserted while a previous job is still active. A secondary cluster of issues involves misuse of the WRITE_READ, DATA_TYPE, and LENGTH parameters.

2. MB_REDCL Block Architecture and Parameters

MB_REDCL is a function block (FB) that wraps a single Modbus/TCP transaction against a configured server. The block supports two physical connections (path A and path B), each of which can be associated with one of the two H-CPUs through dedicated connection IDs (id_0_a / id_1_a for path A; id_0_b / id_1_b for path B). The UNIT input selects which path is used for the next transaction.

2.1 Formal interface (STEP 7 / STL view)

2.2 DATA_TYPE values and corresponding Modbus function codes

3. Root Cause Analysis

Every reproducible W#8304 / W#A083 case in the source material maps to one of the following five causes. They are listed in order of frequency.

3.1 Status W#16#8304 – "No connection to the communication partner"

W#16#8304 is the SIMATIC standard error code meaning "the configured connection is not established at the moment the job is sent". The Modbus request could not be transmitted because the TCP connection was down, not yet opened, or had been aborted. Common underlying reasons include:

• The TCP connection in NetPro is configured as a passive (server) connection – i.e., "Accept incoming connection" – on the S7-400H side, but the third-party device (here, the Ventyx / eDNA "VMS") does not dial in.
• Both connections in the redundant pair are passive and the partner never dials in.
• The partner IP address, partner port, or own port (default 502 for Modbus/TCP) is wrong in the connection properties.
• The CP 443-1 firmware does not support Modbus/TCP keep-alive on the configured port (verify firmware version, see Section 8).
• Connection ID (id_0_a / id_1_a) handed to MB_REDCL does not match the ID assigned in NetPro.

3.2 Status W#16#A083 – "TCP error during send/receive"

W#16#A083 indicates that the TCP send or receive call inside the Modbus/TCP stack returned a non-success error. The most frequent triggers in the field are:

• ENQ is set on every OB35 cycle while a previous job is still pending. The block therefore re-issues a request on top of an in-flight job, which the underlying CP rejects.
• The application uses a fresh ENQ rising edge but the OB35 cycle is shorter than the time the Modbus server needs to answer (typical eDNA or third-party server round-trip is 50–200 ms, while OB35 may be 20–50 ms). The block enters its error state at the next cycle.
• Firewall / router silently drops Modbus/TCP frames; the CP eventually reports a TCP-level reset.

3.3 WRITE_READ polarity

The example code in the original post sets WRITE_READ = TRUE while the user comment states "I want to read from the server". With WRITE_READ = TRUE, MB_REDCL builds a Modbus write request, but the application does not provide a source DB of the requested length. The block therefore either ignores the request (no DONE) or surfaces W#16#A083 because the stack cannot build a valid FC 06/16 PDU. For pure read polling, WRITE_READ must be FALSE.

3.4 LENGTH unit confusion

The user's code writes L 5 / T "CONTROL_DAT".LENGTH with DATA_TYPE = 3 (holding register). For DATA_TYPE = 3, LENGTH is in registers (words), not bytes. With LENGTH = 5, MB_REDCL will read 5 holding registers from address 834. This happens to be the correct interpretation here, but the user must be aware that for FC 01/02 (coils/inputs) the same constant would mean 5 bits. When in doubt, always cross-check with the server's Modbus map and the function code in the wire capture.

3.5 ENQ trigger logic in OB35

MB_REDCL must be called cyclically – the block is stateful and uses the cyclic call to advance its internal handshake with the CP. The rising edge at ENQ, however, must only be applied once per finished job. The original code resets ENQ in the same cycle that ENQ was set:

A     "CONTROL_DAT".ENQ
R     "CONTROL_DAT".ENQ     // reset in the SAME cycle

This is technically a one-cycle pulse and is acceptable, provided that the next rising edge is only generated when the previous job has finished (BUSY = FALSE). The original code, however, triggers ENQ every OB35 cycle without checking BUSY. Combined with a down TCP connection, this floods the CP with retries and produces the continuous W#8304 / W#A083 pattern observed.

4. Hardware Configuration Constraints

MB_REDCL is a redundant Modbus/TCP client block and requires a redundancy-capable topology. The supported hardware combinations are documented in the library manual and are strict:

5. Step-by-Step Solution

Apply the steps below in order. Each step is followed by a verification check.

Step 1 – Confirm the CP 443-1 firmware supports the Modbus/TCP CP Red library

Verify the firmware version on both CP 443-1 modules. The minimum required firmware for the Modbus/TCP CP Red library is documented in the library manual "SIMATIC Modbus/TCP - Redundant Communication via CP 443-1 in H-Systems" (Siemens entry ID 109754927). A CP 443-1 with firmware < V3.2 typically does not support the redundancy functions. If the firmware is older, update it with the SIMATIC Manager's "PLC → Update Firmware" function.

Verification: In HW Config, right-click the CP 443-1 → Object Properties → Diagnostics tab. The firmware version must match or exceed the version listed in the library manual.

Step 2 – Create the TCP connections in NetPro with active connection establishment

1. Open the S7 project in SIMATIC Manager.
2. Open NetPro (Options → NetPro).
3. Insert a new TCP connection for each CP. In the H-station, this means one connection from CPU 0 / CP 443-1 (rack 0) and one from CPU 1 / CP 443-1 (rack 1) to the VMS partner.
4. Open the connection properties → General tab. Confirm the connection direction is set to "Establish an active connection". If it reads "Accept incoming connection", the S7 is acting as the TCP server and will not dial out – this is the single most common cause of W#8304.
5. Set the partner IP address (the VMS server), the partner port (default 502), and the local port (any free port, or leave blank to let the OS assign).
6. Save and compile NetPro, then download the connection configuration to both CPUs.

Verification: In NetPro → Connections, the icon for the connection should be a solid arrow from the S7-400H to the partner, and the status byte in the connection diagnostics (online → connection status) should read 01 (connection established) after a few seconds.

Step 3 – Capture the connection IDs and CP logical base addresses

For each connection created in Step 2, note:

• Connection ID (a number assigned by NetPro – usually 1, 2, 3, …). Hand it to MB_REDCL at id_0_a (for the connection that is active on CPU 0) or id_1_a (for the connection that is active on CPU 1). The same for path B at id_0_b / id_1_b.
• CP logical base address from HW Config (for example, 256 for CP in slot 4). Hand it to MB_REDCL at laddr_cp0 (CPU 0) or laddr_cp1 (CPU 1).

Verification: Cross-check that each ID used in the program exists in the NetPro download. An ID that exists in the program but not in NetPro is the most common silent cause of W#8304 on cold start, because the connection table in the CPU has no entry for that ID.

Step 4 – Wire the library block to the right FB instance DB

Each call of MB_REDCL must use a dedicated instance DB (multi-instance is allowed). Renaming or rewiring the FB to a DB of the wrong type is the most common reason the outputs of the block show undefined or static values, and the DONE / ERROR / STATUS words never update. Make sure the call is:

CALL  "MB_REDCL" , "IDB_Modbus_Client"

where IDB_Modbus_Client is an instance DB generated by STEP 7 when the FB is inserted into the S7 program. Do not hand the call a shared DB of the wrong type.

Step 5 – Set WRITE_READ, DATA_TYPE, START_ADDRESS, and LENGTH for read polling

For "read 5 holding registers starting at address 834 once per second":

Step 6 – Correct the ENQ trigger logic

Re-arm the trigger only when the previous job has finished (BUSY = FALSE) and the cycle timer (1 s for the user's requirement) has elapsed:

// 1-second cyclic trigger
A     "TICK_1S".Q           // 1 Hz clock from OB35 (every 20th call at 50 ms)
AN    "IDB_Modbus_Client".BUSY
S     "CONTROL_DAT".ENQ    // rising-edge request

// Reset ENQ in the same cycle (single-cycle pulse)
A     "CONTROL_DAT".ENQ
R     "CONTROL_DAT".ENQ

Do not re-assert ENQ while BUSY is TRUE. The original code did not check BUSY, which is the second half of the W#A083 problem.

Step 7 – Apply the correct license key

MB_REDCL requires a valid license key at the REG_KEY input. The key is shipped with the library and is typically a 24-character string. With an invalid or missing key, the LICENSED output stays FALSE and the block reports W#16#A005 / W#16#A007. For the Modbus/TCP CP Red library, the key is bound to the CP serial number. If the CP is replaced, the license must be re-applied.

6. Corrected STL Code for OB35

Below is a production-ready call pattern for MB_REDCL running in OB35, polling once per second with a 50 ms OB35 base cycle. The pattern is derived from the original post but applies the corrections documented above.

// === OB35, 50 ms base cycle, 1 s poll period ===

// Trigger every 20th OB35 call (= 1.0 s)
A     "TICK_1S".Q              // clock generator
AN    "IDB_Modbus_Client".BUSY // only when no job is pending
S     "CONTROL_DAT".ENQ
A     "CONTROL_DAT".ENQ
R     "CONTROL_DAT".ENQ        // 1-cycle pulse

// Job parameters (read holding register 834, 5 words, path A)
L     3
T     "CONTROL_DAT".DATA_TYPE       // holding register
L     834
T     "CONTROL_DAT".START_ADDRESS   // Modbus start address
L     5
T     "CONTROL_DAT".LENGTH           // 5 words
CLR
=     "CONTROL_DAT".WRITE_READ      // FALSE = read
L     1
T     "CONTROL_DAT".UNIT            // path A

CALL  "MB_REDCL" , "IDB_Modbus_Client"
ENQ            := "CONTROL_DAT".ENQ
DATA_TYPE      := "CONTROL_DAT".DATA_TYPE
START_ADDRESS  := "CONTROL_DAT".START_ADDRESS
LENGTH         := "CONTROL_DAT".LENGTH
WRITE_READ     := "CONTROL_DAT".WRITE_READ
UNIT           := "CONTROL_DAT".UNIT
MONITOR        := FALSE
REG_KEY        := "LICENSE_DB".REG_KEY
id_0_a         := W#16#0001   // path A, CPU 0 - from NetPro
id_1_a         := W#16#0002   // path A, CPU 1 - from NetPro
id_0_b         := W#16#0003   // path B, CPU 0 - from NetPro
id_1_b         := W#16#0004   // path B, CPU 1 - from NetPro
laddr_cp0      := W#16#0100   // CP 443-1 base address, CPU 0 - from HW Config
laddr_cp1      := W#16#0200   // CP 443-1 base address, CPU 1 - from HW Config
check_conn_cycle:= T#5s
use_all_conn   := TRUE
single_write   := FALSE
BUSY           := "CONTROL_DAT".BUSY
DONE           := "CONTROL_DAT".DONE
ERROR          := "CONTROL_DAT".ERROR
STATUS_0A      := "CONTROL_DAT".STATUS_0A
STATUS_1A      := "CONTROL_DAT".STATUS_1A
STATUS_0B      := "CONTROL_DAT".STATUS_0B
STATUS_1B      := "CONTROL_DAT".STATUS_1B
IDENT_CODE     := "CONTROL_DAT".IDENT_CODE
LICENSED       := "CONTROL_DAT".LICENSED

7. Verification and Diagnostics

After the fix is applied, run the verification matrix below.

8. Common Status Codes Reference

9. Field-Commissioning Checklist

1. Confirm CP 443-1 firmware ≥ minimum version specified in the Modbus/TCP CP Red manual.
2. Open HW Config and confirm both CP 443-1 modules are in the correct slots of the H-rack (UR2-H).
3. Open NetPro and confirm two TCP connections exist, both with active establishment.
4. Compile NetPro, download to both H-CPUs, and verify online connection status = 01.
5. Open the program in STEP 7 and confirm each MB_REDCL call has a dedicated instance DB.
6. Confirm WRITE_READ matches the intended direction (FALSE for read, TRUE for write).
7. Confirm LENGTH is in registers (words) for DATA_TYPE 2/3/4, and in bits for DATA_TYPE 1.
8. Confirm id_0_a, id_1_a, id_0_b, id_1_b match the IDs assigned in NetPro.
9. Confirm laddr_cp0 / laddr_cp1 match the CP base addresses in HW Config.
10. Confirm REG_KEY contains a valid license key for the serial number of the active CP.
11. Implement BUSY-gated ENQ logic; do not retrigger on every OB35 cycle.
12. Run a 60-second observation. The Done counter should increment at the configured poll rate, the Error counter should stay at 0.
13. Capture traffic with Wireshark on port 502 to confirm FC 03 polls are leaving the S7 and valid responses are returning.
14. For a redundant site, pull the network cable from the primary CP and confirm the secondary CP takes over (STATUS_0A / STATUS_0B transition, but communication continues).
15. Document the ID → CP mapping in the project notes for future maintenance.

10. Edge Cases and Alternate Platforms

10.1 Migrating to S7-1200/1500 with MB_RED_CLIENT

Newer S7-1200 (FW 4.4+) and S7-1500 stations use the TIA Portal instruction MB_RED_CLIENT in place of MB_REDCL. The interface is similar but parameter names differ: REQ replaces ENQ, DONE / BUSY / ERROR are identical, and the connection IDs are replaced by the symbolic Connection reference. The redundancy topology is still 1 × S7-1500 CPU with 2 × CP 1543-1. See the official TIA Portal manual at MB_RED_CLIENT – Redundant communication over PROFINET as a Modbus/TCP client for the exact parameter mapping.

10.2 Single-CPU S7-300 with 2 × CP 343-1

If the user has an S7-300 station and wants the same redundant Modbus/TCP behavior, the same library works with the S7-300 variant. The two CP 343-1 modules are wired to the same CPU. The two H-specific parameters (id_0_a / id_1_a) collapse to a single connection ID per CP. laddr_cp0 is set to the base address of the first CP, laddr_cp1 to the second. The license key is bound to the CPU serial number rather than the CP.

10.3 Polling rate vs. OB35 cycle

For a 1 s poll rate, use an OB35 cycle of 50 ms and a counter that fires every 20th call. For a sub-100 ms poll rate, drop the cycle to 10 ms (OB35 supports 1 ms minimum) and confirm the Modbus server can keep up. If the server's response time is greater than the cycle, the BUSY gate will throttle the next ENQ automatically – no extra logic required.

10.4 S7-300 software redundancy: not supported

Modbus/TCP is not part of the S7-300 software-redundancy model. Two S7-300 stations linked via PN redundancy cannot share a single MB_REDCL block. Each station can only run its own MB_CLIENT with its own CP, and a takeover will not transfer the active Modbus connection. Plan for an S7-400H or a single-CPU S7-300 with two CPs if redundancy is required.

10.5 Status word polling

When integrating MB_REDCL into a higher-level diagnostics display (WinCC, PCS 7, or a custom HMI), the recommended approach is to expose only the steady-state DONE counter, the ERROR counter, and the latched Save_STATUS_0A / Save_STATUS_1A words (capture the status on the rising edge of ERROR, exactly as in the original post). Do not display transient W#16#A090 as an alarm – it will cause alarm floods at every poll.

FAQ