Resolving WinCC Modbus TCP Connection Limit with Moxa MB3180

Problem Overview

A common integration pattern with legacy variable-frequency drives is to poll ABB drives over Modbus RTU (RS-485) on the field side and bridge those frames to Modbus TCP on the SCADA side through a protocol converter such as the Moxa MB3180. When the SCADA layer is implemented in Siemens WinCC 7.0 SP3, the system often exhibits a confusing symptom: WinCC establishes Modbus TCP sessions to only five of twelve configured drives at runtime start, and the remaining seven drives never receive a connect attempt, no matter how long the runtime runs.

The behavior is non-deterministic in that the five "winners" change between restarts, which points away from a tag-addressing problem and toward a socket-pool or channel-handle exhaustion problem inside the WinCC driver or the Windows TCP/IP stack. The same diagnostic fingerprint is observed when an OPC aggregation server such as Kepware is substituted for WinCC, which confirms that the limit is not strictly a WinCC implementation bug but a side-effect of how the Modbus TCP channel is opened.

The fix is to force the driver to reuse a single TCP socket for every Modbus slave attached to one Moxa port, or to partition the drives across multiple WinCC channels so that each channel stays within the practical socket and register-count envelope of the Moxa gateway.

System Architecture

The reference topology is documented in the table below. Twelve ABB drives (for example, ABB ACS355, ACS550, or ACS580 families with the FMBA-01 Modbus RTU adapter or built-in Modbus RTU) are daisy-chained on one RS-485 bus and terminated at the Moxa MB3180. The MB3180 acts as a Modbus RTU master on the serial side and a Modbus TCP server on the Ethernet side. WinCC 7.0 SP3 runs on Windows 7 x64 Ultimate and opens Modbus TCP client channels to the MB3180.

The Moxa MB3180 is a 1-port RS-232/422/485-to-Ethernet Modbus gateway with up to 32 concurrent TCP master connections and up to 16 Modbus RTU/ASCII slaves per serial port. When the WinCC channel is created with default settings, the MODBUS TCP driver opens one TCP socket per configured device, which translates to one socket per drive on the MB3180 side.

Symptom Description

1. Runtime starts. WinCC logs a successful TCP connection for five drives and a connect failure or silent timeout for the other seven.
2. The five successful drives are not deterministic across runtime restarts.
3. No Modbus exception code (0x01 illegal function, 0x02 illegal data address, 0x0B gateway target failed to respond) is logged. The failure is at the TCP socket layer, not the Modbus PDU layer.
4. Kepware behaves identically when "Share a single socket across all devices on this channel" is left unchecked, which proves the cause is upstream of either HMI driver.
5. Reducing the polling rate does not recover the missing seven connections.

Root Cause Analysis

The combined evidence points to three independent limits that can each independently cap the visible drive count. They must be investigated in order.

Cause 1 - Per-channel socket-per-device default in WinCC / Kepware

The Siemens SIMATIC WinCC "MODBUS TCP" channel and the Kepware Modbus TCP driver both default to opening one TCP socket for each configured device. With twelve drives, twelve sockets are requested against the Moxa MB3180, which supports up to 32 simultaneous sockets, so the gateway is not the bottleneck. However, when the channel driver is shared with other HMI tasks, an internal handle pool in the WinCC MODBUS TCP channel DLL can be exhausted before all twelve sockets are opened, leaving the remaining drives in a perpetual "connecting" state.

Cause 2 - Windows half-open / ephemeral port exhaustion

Windows 7 / Server 2008 R2 by default permits 5,000 outbound ephemeral ports (registry MaxUserPort at 0x1388 = 5000 decimal) with an overlapping TIME_WAIT interval of 240 seconds (TcpTimedWaitDelay). If the channel driver reconnects on every poll cycle or after every read exception, the number of sockets in TIME_WAIT can climb until the available port range is exhausted. The symptom is that connections succeed at first, then drop as new sockets cannot be allocated.

Cause 3 - Moxa MB3180 register-throughput limit per socket

The Moxa MB3170 / MB3180 line has a documented per-socket polling limit when read block sizes exceed roughly 100-110 contiguous registers. WinCC by default may issue wide reads that cross this boundary, after which the gateway silently drops the request and the WinCC driver marks the device as offline. This explains the original report's secondary observation that splitting into two logical drivers cured a similar symptom on the MB3170.

Moxa MB3180 Technical Reference

Because the MB3180 supports 32 concurrent TCP masters, the gateway itself is not the limiting factor for a 12-drive system. The 5-drive symptom must therefore come from the WinCC client side or from the Windows TCP/IP stack.

Modbus TCP Protocol Constraints

Modbus TCP encapsulates the Modbus PDU in a 7-byte MBAP header plus the PDU. Each request and response must fit in a single TCP segment. The protocol defines a hard upper bound of 253 bytes for the PDU, which in turn caps the number of registers per transaction.

The 125-register hard limit per Modbus read transaction is specified by the Modbus Organization in the Modbus Application Protocol V1.1b3. WinCC's MODBUS TCP driver issues single-block reads by default; if the tag list spans more than 125 contiguous registers, the driver must split the read into multiple transactions. Across many drives this multiplies socket utilization and can starve the connection pool.

Diagnostic Procedure

1. Capture the WinCC startup log at C:\Program Files (x86)\Siemens\Automation\WinCC\Diagnostics\ and look for the line MODTCP: ChannelUnit <name> opened for each device. Count successful opens against the expected twelve.
2. From the WinCC host, run netstat -ano | findstr 502 immediately after runtime start. The number of ESTABLISHED connections to port 502 of the MB3180 equals the number of WinCC-opened sockets. If only five appear, the driver is not even attempting the remaining seven.
3. Use netsh int ipv4 show dynamicport tcp to read the ephemeral port range and netsh int ipv4 show tcpstats to see the current allocation. If the used port count climbs into the thousands, raise MaxUserPort and shorten TcpTimedWaitDelay.
4. Open the MB3180 web UI (http://<mb3180-ip>) and inspect System Log → TCP Master Connections. The gateway will list all currently open sockets from WinCC. If the gateway already lists twelve connections but WinCC only reads five, the fault is in the WinCC tag configuration, not the network.
5. Open Wireshark on the WinCC host with filter tcp.port == 502 and confirm that the MB3180 is responding to all twelve clients with valid MBAP/PDU responses. If responses are received but WinCC logs no value, suspect tag address mapping rather than the connection itself.

Solution Option A - Single Socket Sharing per Channel

The simplest fix mirrors the Kepware "Share a single socket across all devices on this channel" option, which is the same TCP socket to the Moxa MB3180 serving every drive through the use of the slave-address byte in the Modbus PDU. In WinCC 7.0 SP3 the equivalent behavior is obtained by configuring a single logical connection in the MODBUS TCP channel that addresses every drive through separate tag groups, instead of creating one connection per drive.

1. In WinCC Explorer, open Tag Management → MODBUS TCP.
2. Right-click the channel and select New Connection. Create only one logical connection named, for example, Moxa_MB3180.
3. Set IP Address to the MB3180 address (e.g. 192.168.10.50) and Port to 502.
4. Under the connection, create twelve tag groups, one per drive. Each group uses the same physical connection but a different Station Address (1 through 12) corresponding to the Modbus RTU slave address on the RS-485 bus.
5. Configure Polling Cycle to a value consistent with the MB3180 idle timeout (default 60 s). Set cycle to 30 s to keep the socket warm.
6. Activate the project. Verify with netstat -ano | findstr 502 that only one TCP socket is open per WinCC runtime, regardless of drive count.

This approach guarantees that the MB3180 sees a single TCP client (WinCC) and internally routes the Modbus RTU requests to the slave whose station address matches the PDU byte. Twelve drives ride on one socket, eliminating the per-device socket exhaustion path.

Solution Option B - Channel Partitioning

If the tag count per drive exceeds the MB3180 comfortable block size (about 100-110 registers) or the Modbus 125-register hard limit, partition the drives across multiple WinCC channels. Each channel still opens one socket and serves a subset of drives, keeping each socket's register load manageable.

The WinCC MODBUS TCP driver accepts multiple connections to the same IP/port pair. Each connection opens an independent TCP socket. With two sockets of six drives each, the MB3180 sees two concurrent masters and the register load per socket is halved. This is the same pattern that successfully resolved the MB3170 case with 110-register block sizes.

Solution Option C - Operating-System Tuning

When the channel driver must use one socket per drive and the count exceeds the available ephemeral ports or the TIME_WAIT window, adjust the Windows registry. Back up the registry before changes and reboot for the new values to take effect.

Solution Option D - Firmware Update

Siemens released Update 2, Update 3, and Update 4 for WinCC V7.0 SP3. Each cumulative update tightened the MODBUS TCP driver's internal socket handling and improved reconnection after read exceptions. Install the latest available update (Update 4 is the terminal update for 7.0 SP3) before applying any of the workarounds above. After the update, repeat the netstat diagnostic to confirm whether the symptom persists.

Verification Procedure

1. Activate the modified WinCC project and open the runtime.
2. Run netstat -ano | findstr 502 on the WinCC host. Confirm the expected socket count (1 for Option A, 2 for Option B, 12 for the original configuration).
3. In the MB3180 web UI, navigate to System Log → TCP Master and verify that every configured station address has at least one polled request in the last 60 seconds.
4. In WinCC, open Graphics Designer → Tag Simulator and force a value change on a register from each of the twelve drives. Confirm the value updates in the HMI faceplate within one polling cycle.
5. Run the runtime for 24 hours and review the WinCC diagnostic log for any MODTCP: Connection lost or MODTCP: Retry timeout entries. Zero such entries is the acceptance criterion.
6. Restart the runtime three consecutive times. The set of "winning" drives (or lack of differentiation) must be identical across all three starts.

Troubleshooting Matrix

Frequently Asked Questions