S7-1500 MB_CLIENT Error 809B: Bently Nevada 3500 Modbus TCP Fix

1. Problem Summary

A SIMATIC S7-1500 CPU attempts Modbus TCP polling of a Bently Nevada 3500 machinery protection rack fitted with a 3500/92 Modbus TCP gateway card. The PLC is wired into a SCALANCE X208 managed switch on PROFINET port X2 of the CPU (port X1 carries the PROFINET ring). Ping from the engineering station and from the PLC to the 3500/92 IP succeeds, but the MB_CLIENT instance reports a permanent status word value of 809B hex on the STATUS output and never updates the receive buffer.

The same engineering project also exhibits the following behaviour:

• The 3500/92 rack is reachable by ICMP echo from both the engineering PC and the PLC.
• Setting the 3500/92 to act as a Modbus client instead of a server produces the same 809B status.
• Changing MB_MODE between 101 and 104 yields no change in STATUS.
• Only when MB_MODE = 0 is entered does the status finally clear and registers begin populating.

2. Hardware and Network Topology

Wiring path: CPU X2 → CAT6 patch → SCALANCE X208 Port 1 → SCALANCE X208 Port 4 → 3500/92 Ethernet RJ45. The PROFINET ring (port X1) is logically and physically separate from the Modbus subnet.

3. Decoding Status 809B

The 16-bit STATUS output of MB_CLIENT reports class A errors as 0x8xxx hex. Per the Siemens SIMATIC S7-1500 Communication Function Manual, the relevant subset of error classes is:

Diagnosis: Status 809B is reported before any Modbus PDU is exchanged. It indicates the TCP three-way handshake with the 3500/92 server failed. The PLC attempted to open a TCP session to the configured RemoteAddress:RemotePort and the partner either refused the SYN or did not reply.

4. Root Cause Analysis

Three contributing defects were present in the original project. Each must be corrected before MB_CLIENT will complete the TCP handshake.

4.1 Remote port misconfiguration

The initial project had RemotePort = 0 with LocalPort = 502. The roles are reversed in a Modbus TCP client. The 3500/92 acts as the server and is the device listening on TCP 502. The PLC must therefore set RemotePort = 502; the local port must be 0 (let the operating system assign an ephemeral port) or any unused port above 1024.

4.2 MB_MODE value mismatched to data request

The MB_MODE parameter encodes both the Modbus function code and the access type (read/write, bit/word). Valid values are 0, 1, 2, 3, 101, 102, 103, 104, 105, 106. Modes 101-104 require the data length to be ≤ the maximum word count the function allows and require MB_DATA_ADDR to be entered as the zero-based Modbus address (0 to 65535). Mode 0 (FC 3 - Read Holding Registers) with explicit address and length supplied via MB_DATA_ADDR and MB_DATA_LEN is the most forgiving configuration and was the only mode that produced a successful response on this hardware combination.

4.3 DATA_LEN exceeding server-mapped length

The 3500/92 was configured with a Modbus mapping length of 95 holding registers starting at server address 45001. MB_DATA_LEN must be exactly 95; any larger value triggers a server-side rejection once the PLC moves past the configured range. The MB_DATA_ADDR parameter must be set to the address value declared inside the 3500/92 configuration utility - in this case 45001 - not to the zero-based offset. MB_CLIENT performs the zero-based remapping internally.

5. Working MB_CLIENT Configuration

The instance DB of MB_CLIENT must contain the following parameter values. Hardware identifier (InterfaceId) for port X2 on an S7-1516 is system constant 72 in TIA Portal V15 and later; verify with the device view "System constants" tab.

6. Step-by-Step Resolution Procedure

1. Confirm physical layer. From the engineering PC, ping 192.168.1.6. Successful reply indicates that the SCALANCE X208, patch cabling, and the 3500/92 RJ45 port are functional.
2. Confirm 3500/92 TCP server. From the PC, open a Modbus TCP test tool (for example a PC acting as Modbus client with Wireshark on tcp.port == 502) and issue an FC 3 read of 1 register from address 45001. A response confirms the server is listening and that registers are mapped.
3. Identify the PLC PROFINET interface. In TIA Portal, open Devices & Networks, select the CPU, and switch to the System constants tab. Note the HW identifier of the PROFINET interface used for Modbus traffic. On an S7-1516 with two PROFINET ports, port X1 is usually HW ID 71 and port X2 is HW ID 72.
4. Insert MB_CLIENT. Drag MODBUS TCP > MB_CLIENT into the project. The instruction creates an instance DB automatically.
5. Configure the CONNECT input. Open the instance DB and populate the CONNECT structure with the values from the working configuration table above. ConnectionType = 11 selects standard TCP/IP.
6. Configure the polling inputs. Set MB_MODE = 0, MB_DATA_ADDR = 45001, MB_DATA_LEN = 95.
7. Provide a non-optimised data block. The receive buffer MB_DATA_PTR must point into a standard (non-optimised) DB of at least 95 WORDs. Optimised DBs occasionally interfere with the Modbus data transfer under specific firmware versions; revert to standard access if problems persist.
8. Tie REQ high. Connect REQ to a constant TRUE in OB1 for continuous polling, or to a clock generator for periodic polling.
9. Compile, download, go online. Force OB1 to run and observe the STATUS tag online. Expect 7001 momentarily, then 7002, then DONE pulses.
10. Verify register contents. Open the receive DB online and confirm that 95 WORDs are populated and change when the 3500 rack vibration channels are stimulated.

7. Verification Checklist

8. Common Pitfalls and Field Notes

• Mode vs. address confusion. Modes 101-104 are convenience modes that auto-derive the function code from a 1-based register number. If the 3500/92 mapping starts at 45001, the user is tempted to set MB_DATA_ADDR = 45001 with mode 103. Mode 103 internally reinterprets MB_DATA_ADDR as 45001 with zero-based offset calculation - on most firmware revisions this works, but with the 3500/92 a small subset of the address space above register 41000 causes the server to NAK. Falling back to mode 0 with explicit address and length avoids the interpretation problem.
• Optimised access blocks. A receive DB with "Optimised block access" enabled prevents the MB_DATA_PTR ANY pointer from resolving to a known byte offset. Always use a standard DB with byte offsets for Modbus data buffers, or assign the symbol directly in TIA Portal V16+ where the compiler can resolve symbolic slice references.
• CPU PROFINET port selection. S7-1500 CPUs with two PROFINET ports (X1 and X2) report a separate HW identifier for each. Using the wrong identifier routes the TCP SYN out the wrong interface and the 3500/92 never sees it. The symptoms are indistinguishable from a partner-refused error (809B). Confirm the HW ID against the CPU's system constants.
• SCALANCE switch ACLs. A SCALANCE X208 in default configuration passes all frames. If a previous project has loaded an ACL or VLAN filter, ensure that VLAN membership and IP-based filter rules permit TCP/502 between 192.168.1.2 and 192.168.1.6.
• 3500/92 firmware versions. Bently Nevada 3500/92 firmware revisions prior to A2.10 do not implement Modbus TCP keep-alive and may drop the connection after 60 seconds of silence. With continuous REQ = TRUE polling this is not an issue, but periodic polling at intervals above 30 s should enable the 3500/92 "Modbus Keep-Alive" parameter.
• Modbus TCP port collision. Port 502 is privileged on some embedded Linux stacks and may require the S7-1500 firmware V2.6 or higher to bind outgoing connections correctly. Update the CPU firmware if LocalPort = 0 still triggers 809B after the partner configuration is corrected.

9. Related TIA Portal Diagnostics

The Siemens Open User Communication instructions TCON, TDISCON, TSEND, and TRCV sit beneath the MB_CLIENT abstraction and expose lower-level status information. For persistent 809B errors, drop to a manual TCON/TRCV pair to isolate whether the TCP handshake itself completes - the underlying connection establishment function returns a status that mirrors the partner refusal condition described above. Reference: TCON, TDISCON, TSEND, and TRCV (TCP communication instructions).

Use the diagnostic buffers of the CPU (Online & Diagnostic → Diagnostic buffer) to inspect the connection status events generated when the TCP handshake is attempted.

10. Troubleshooting Matrix

11. Cross-Platform Equivalents

All platforms share the same three failure modes: wrong remote port, wrong slave address mapping, or wrong data length. The 809B-equivalent status on other platforms is "connection refused" (Winsock error 10061) or a CIP error 0x0308.

12. FAQ