Solving Modbus TCP Single-Master Limitation with PLC Gateway

When a Modbus TCP server in the field accepts only one master connection at a time, two clients — typically a panel HMI and a high-speed data logger — cannot both hold an open socket to the same controller. The slave's firmware will reject the second connection, drop the first, or interleave responses in a way that corrupts both clients' register images. The standard fix is to insert a small PLC or dedicated gateway as a data broker: it holds the single authorized connection to the constrained slave, polls at a deterministic rate, and re-exports the polled values to any number of Modbus TCP clients on the LAN. This article documents the full architecture, the TIA Portal implementation on a Siemens SIMATIC S7-1200 CPU 1215C, the MOXA MGate alternative, the HMI-as-broker shortcut, and a verification matrix that catches the common field mistakes.

1. The Single-Connection Constraint in Real Modbus TCP Slaves

Modbus TCP is an open application-layer protocol originally published by Modicon and now stewarded by the Modbus Organization. The protocol specification — "Modbus Messaging on TCP/IP Implementation Guide V1.0b" — defines the MBAP header, the function codes, and the client/server model, but does not impose a hard limit on the number of concurrent client connections a server must accept. The IETF transport is a full-duplex TCP byte stream on port 502; in principle, a server can service many sockets in parallel. The Modbus overview on Wikipedia summarizes the protocol's history and the reasons it remains widely deployed.

Embedded industrial controllers, however, almost always implement a single-socket listener to minimize RAM, the TCP state machine, and the scheduler footprint. A Waukee temperature controller on a furnace atmosphere loop is one example: its firmware opens one listening socket on TCP 502 and either drops the existing connection when a new one arrives, or refuses the new connection with a TCP RST. The result is observable from any client as one of:

• Connection Refused (ECONNREFUSED) on the second client's connect call.
• Connection reset on the first client right after the second client connects.
• Interleaved PDUs when the slave permits multiple sockets but processes one transaction at a time, producing garbage data and timeout-derailed responses.

The slave itself is not defective; it is enforcing a single-master rule documented in its Modbus parameter sheet. Solving the problem at the application layer — by re-architecting the network so that only one master holds an authorized socket — is the field-standard fix. The ProSoft Technology Introduction to Modbus TCP/IP PDF provides a vendor-neutral primer that covers connection behavior.

2. Modbus TCP Frame Structure and Connection Modes

Modbus TCP wraps the legacy Modbus PDU in a 7-byte MBAP header. The full transaction over the wire is:

Modbus TCP does not use a Modbus CRC; TCP provides byte-level integrity. Each request/response pair rides inside one TCP connection. The connection itself can be:

• Persistent (keep-alive) — opened at application start, held for the lifetime of the program. Default for SCADA systems.
• Transient (per-request) — opened for one request, closed after the response. Common in scripts and some data loggers.

Single-connection slaves accept only one active connection at any moment, regardless of mode. Both clients trying to hold a persistent socket will lose. The solution is to ensure only the broker holds the active socket and re-exports the data to all other clients on a second connection layer. The Siemens Industry Online Support thread on maximum Modbus master device counts confirms the 32/64-slave historical limits and explains the connection-count math for the SIMATIC side.

3. Solution Matrix

Five architecture options are common in furnace, oven, and atmosphere control retrofits. Each has a different cost, commissioning time, and side-effect scope.

4. Reference Architecture: The Data Broker

The broker device is a Modbus TCP master to the constrained slave and a Modbus TCP server to the two (or more) clients. It maintains the only authorized socket to the Waukee controller and re-exports the polled registers on a different IP/port pair. Internally, a data block holds the latest polled values; the broker's server side answers the clients' reads directly from that buffer at wire speed.

The single TCP connection on the left side is the only authorized socket to the Waukee slave. The two sockets on the right side are independent and may be opened, closed, and re-opened at will by the clients. The PLC's scan cycle updates the buffer from the slave at a fixed rate (typically 250–500 ms) regardless of what the clients are doing.

5. Siemens S7-1200 Implementation (Option 1)

The S7-1200 is the most flexible broker for a furnace retrofit because it can also handle the alarming, interlock, and IFM buzzer output that the field installation requires. The implementation uses two instructions from the TIA Portal library: MB_CLIENT to poll the Waukee slave and MB_SERVER to serve the polled values to the two clients. Full instruction documentation is on the Siemens Industry Online Support portal — search for "MB_CLIENT" or "MB_SERVER" within the S7-1200 product tree.

5.1 Hardware Selection

For a two-client broker with alarm outputs, the SIMATIC S7-1200 CPU 1215C DC/DC/DC is the typical choice. Key catalog numbers:

Verify the exact catalog number against Siemens' SIMATIC product selector at the time of purchase, as Siemens has refreshed the part number suffixes between firmware V4.2 and V4.5.

5.2 TIA Portal Project Configuration

1. Create a new TIA Portal project. Select the S7-1200 CPU in the project tree.
2. Open Properties → PROFINET interface [X1] → Ethernet addresses. Set a static IP, e.g., 192.168.10.20, subnet mask 255.255.255.0. Disable the router.
3. Open Program blocks → Add new block → Data block (DB). Create DB200 "BrokerBuffer" with the structure described in section 5.4.
4. Add an MB_CLIENT instance: drag from Instructions → Communication → Modbus TCP into OB1. Name the instance DB DB201 "MB_Client_Waukee".
5. Add an MB_SERVER instance: same path. Name the instance DB DB202 "MB_Server_Clients".
6. Open PLC → Properties → Protection & Security → Connection mechanisms. Permit "Permit access with PUT/GET communication from remote partners" if the data logger uses that path, and ensure Modbus TCP server access is enabled.

5.3 MB_CLIENT Configuration (Polling the Waukee)

The MB_CLIENT instruction opens a TCP connection to 192.168.10.50:502, sends a function-03 read at the configured period, and writes the response into DB200. Configure as follows:

The TCON_IP_v4 UDT is filled with the Waukee's IP, port 502, and connection type 16 (TCP). Set the active flag to TRUE so the PLC initiates the socket. Local port can be left at 0 (auto-assigned).

5.4 Data Block Layout (DB200 "BrokerBuffer")

The buffer holds the polled values and a metadata block that the clients can use to confirm freshness:

The UpdateCounter and Status fields let the clients detect a stuck or stale value: if the counter does not change for >3 s, the buffer is stale. This is critical for alarming, because the clients will read the broker's value and not the slave's, and a broker-side failure must not be silent.

5.5 MB_SERVER Configuration (Serving the Clients)

The MB_SERVER instruction opens a TCP listener on port 502 of the S7-1200. The S7-1200 firmware V4.4 supports up to 8 simultaneous Modbus TCP server connections, which is enough for two clients plus an engineering station. Configure as follows:

The MB_HOLD_REG pointer length is the number of 16-bit words the clients can address as 40001…40xxx. The buffer's first 200 words are exposed. Because the polled values are stored as REAL (4 bytes), the client reads 2 registers per REAL and must apply big-endian word swap, or the broker can pre-pack the values into a separate INT-scaled block. The pre-pack approach is recommended for clients that cannot swap word order in their driver.

5.6 Common MB_CLIENT / MB_SERVER Error Codes

The STATUS pin returns a hex code. The codes below are the field-most-common on S7-1200 firmware V4.x with TIA Portal V17:

5.7 OB1 Ladder Logic Skeleton

The cyclic OB1 calls both instructions. A typical implementation in ladder:

Network 1 — Pulse every 500 ms
      "PollClock" (TON, PT = 500 ms)
        IN          OUT
   ----| |----------( )---- "PollPulse"
        PT = T#500ms

Network 2 — MB_CLIENT (master to Waukee)
   "MB_Client_Waukee"(
      REQ            := "PollPulse",
      CONNECT        := "TCON_Waukee",
      MB_MODE        := 0,
      MB_DATA_ADDR   := 40001,
      MB_DATA_LEN    := 20,
      MB_DATA_PTR    := P#DB200.DBX0.0 WORD 20,
      DONE           => "Client_Done",
      BUSY           => "Client_Busy",
      ERROR          => "Client_Err",
      STATUS         => "Client_Status",
      CONNECT_ID     := 1
   );

Network 3 — On every successful poll, increment counter
   "Client_Done"  --|
                  | +  "UpdateCounter" := "UpdateCounter" + 1
   ----( )------- |    "LastUpdateTime" := RD_SYS_T
                  |    "Status" := 0

Network 4 — If no success in > 3 s, set stale
   "Stale_TON" (TON, IN := NOT "Client_Done", PT = T#3s)
        Q
   ----( )---- "Status" := 1

Network 5 — MB_SERVER (serving two clients)
   "MB_Server_Clients"(
      DISCONNECT     := FALSE,
      CONNECT        := "TCON_Broker",
      MB_HOLD_REG    := P#DB200.DBX0.0 WORD 200,
      NDR            => "Srv_NDR",
      DR             => "Srv_DR",
      ERROR          => "Srv_Err",
      STATUS         => "Srv_Status",
      MB_DATA_PTR    := P#DB200.DBX0.0 WORD 200
   );

Network 6 — Audible alarm (IFM buzzer on DQ a0.0)
   "AlarmBits".X0  OR  "AlarmBits".X1
        +                    +
   ----| |-------------------(S) "BuzzerRun"
   "AckBtn"  (NO contact wired to DI a0.0)
        +
   ----| |-------------------(R) "BuzzerRun"
   "BuzzerRun"  DQ a0.0 (24V out to IFM buzzer)
        Q
   ----( )---- "DQ_A0_Buzzer"

The IFM buzzer (e.g., IE-series, 24 V DC, 30 mA) connects to the S7-1200's transistor output. The output is rated for 0.5 A continuous, so the buzzer's inrush must be checked; IFM buzzers in the 30 mA range are well within budget. The alarm-acknowledge pushbutton latches the buzzer off after operator acknowledgement.

6. MOXA MGate Alternative (Option 2)

If the only requirement is data replication — no new control, no alarms — a dedicated Modbus gateway is the smallest-footprint solution. The MOXA MGate family is the most deployed in furnace and oven retrofits, and the MB3270 is the two-port model commonly chosen for a single-slave / two-client case. Product manuals are at moxa.com — MGate Modbus TCP Gateways.

Catalog numbers and key specs:

The critical question — does the gateway act as a single broker (single TCP master) to the slave while serving multiple clients — is answered yes by the "Agent mode" or "Master mode" in the MGate configuration. The exact behavior depends on firmware. In MGate firmware V4.x and later, the modes are:

• Agent mode (default for most models): The MGate is a Modbus TCP server on the LAN side and a Modbus RTU/ASCII master on the serial side. This is the typical "TCP-to-serial bridge" behavior. The MGate holds one connection to the upstream device (the Waukee) and serves the data to any number of TCP clients.
• Master mode: The MGate is a Modbus TCP client on the LAN side and a Modbus RTU/ASCII master on the serial side. Used when the controller side is a Modbus TCP server but the fieldbus is serial.
• Slave mode: Used to daisy-chain a MGate to a higher-level master.

For a Modbus TCP-to-Modbus TCP case (no serial), the MB3270 is still usable by mapping the TCP slave's data into the gateway's internal register table using the polling/master mode, then re-serving it as a TCP server. The configuration lives in the MGate's web UI under Modbus Setting → Mode and Command Settings. A typical field configuration is:

1. Set the MGate IP to 192.168.10.25, subnet 255.255.255.0.
2. Set port 1 to Agent mode, Modbus TCP on the LAN side.
3. Add the Waukee as an upstream Modbus TCP slave on 192.168.10.50:502, slave address 1.
4. Define a polling command: function 0x03, start address 0, length 20 words, poll interval 250 ms.
5. Save; the MGate now holds the single TCP connection to the Waukee, polls every 250 ms, and serves the buffer to any TCP client that connects to 192.168.10.25:502.

7. HMI-as-Broker (Option 3)

When the operator interface is already a Proface GP4000, GP-4500, or an Exor eTOP500, the HMI can usually be configured as a Modbus client to the Waukee (polling the slave) and a Modbus server to the data logger (re-exporting). This path requires zero new hardware.

7.1 Proface GP-Pro EX Configuration

1. In GP-Pro EX, open the controller / driver list and confirm the project already uses the Waukee's protocol driver (or a generic Modbus TCP master driver). The Waukee's typical Modbus driver is registered as "Waukee OPL" or, in newer versions, as a generic Modbus TCP slave.
2. Add a secondary driver to the project: the Proface HMI can have two drivers running concurrently. Configure the new driver as Modbus TCP server, listening on the HMI's IP 192.168.10.30:502.
3. Map the polled tags from the Waukee driver to equivalent register addresses in the HMI's internal memory. The HMI re-exports them on its server port.
4. Configure the IBA data logger to point at 192.168.10.30:502 and read the same register map.

The Proface limitation is that not every firmware/driver combination allows a concurrent server. Pro-face has documented the supported "Multi-driver / Server" combinations in the GP-Pro EX Device Connection Manual; the relevant section is in the "Server Function" chapter. If the HMI's firmware does not support the server function, the PLC or gateway path is mandatory.

7.2 Exor eTOP500 and Other HMI Brands

Exor HMIs ship with the JMobile suite and have full Modbus TCP client + server support out of the box. The configuration is similar: one driver polls the Waukee, the other driver opens a server socket on the HMI's IP. Beijer Electronics iX HMI is functionally equivalent. Red Lion CR3000 and Graphite HMIs also support the dual role.

For plant fleets that already have an HMI per furnace, the HMI-as-broker pattern saves $500–$700 per cell. The catch is that the HMI must be operational; if the HMI is rebooted, the data logger loses its data feed for the reboot duration. The PLC broker, by contrast, can be configured to keep the polling task running even when the HMI is offline.

8. Connection Management and Update Rates

Whether you use a PLC or a gateway, the broker's poll rate to the slave must be tuned against the clients' read rates to avoid two problems:

• Over-polling: the broker hits the slave faster than the slave can respond, causing the Waukee to drop the socket. The Waukee's spec sheet typically allows one request every 100 ms minimum; 250–500 ms is a safe field default.
• Under-polling: the clients see a stale value because the broker's update interval is much longer than the clients' poll period. The clients should poll at half the broker's update interval, so they see every value at least once.

Recommended field settings for a furnace atmosphere loop with a 1 s process time constant:

The IBA's 100 ms poll rate is sustainable because the broker is on the LAN and answers from a memory buffer in microseconds, not over a slow physical link to the Waukee. The Waukee sees only the 250–500 ms poll from the broker. The Siemens SIMATIC Modbus master/slave limit thread explains why the historical 32-slave ceiling exists and how firmware SP13 raised it to 64, which gives headroom for any number of clients to the broker.

9. Verification and Commissioning

After programming the broker, the following checks must pass before sign-off:

1. Single-socket verification: use a packet capture (Wireshark on a mirrored port) on the LAN segment. Filter on tcp.port == 502 && ip.addr == 192.168.10.50. Confirm exactly one TCP session is open to the Waukee at steady state. Two or more sessions indicates the broker is mis-configured and the limitation is not solved.
2. Loopback read test: from a laptop running a Modbus TCP master tool (e.g., Modbus Poll, CAS Modbus Scanner), connect to the broker's IP and read registers 40001–40020. Compare to the Waukee's actual values within ±1 LSB. Repeat from a second laptop to verify the broker serves two clients concurrently.
3. Stale-data test: disconnect the LAN cable to the Waukee. After 3 s, the broker's Status word should change to 1 (stale) or 2 (comms lost). The IFM buzzer should NOT sound for a comms-loss condition; the alarm logic must distinguish between data out of range and data unavailable.
4. Concurrent client stress test: with both clients reading at their target rates for 30 minutes, monitor the broker's UpdateCounter. It should increment at the broker's poll rate (2 Hz at 500 ms) regardless of client activity. Any stall indicates a buffer race or a TCP state-machine bug.
5. Power-cycle test: power off the broker, then restore. The clients must reconnect automatically, and the broker must re-establish its own socket to the Waukee without manual intervention. TIA Portal's MB_CLIENT and MB_SERVER handle this on the next scan; gateways typically have a "reconnect on link" parameter that must be enabled.
6. Alarm acknowledgement test: drive the polled value out of band via simulation. Verify the IFM buzzer sounds. Acknowledge via the pushbutton. Verify the buzzer latches off and does not re-trigger until the value returns to band and out again.

10. Troubleshooting Matrix

11. Field-Proven Caveats

Three points worth flagging before the first commissioning walk-down:

1. Vendor Modbus map discrepancies. Waukee's published Modbus register map uses 1-based (40001 = first holding register). The S7-1200's MB_CLIENT uses 0-based by default. Always cross-check with the vendor's parameter sheet; the field's most common error is using 40001 when the slave expects 0x0000. Siemens' own discussion of MB_DATA_ADDR semantics is documented in the S7-1200 system manual on the Siemens Industry Online Support portal.
2. Modbus TCP and Modbus RTU are not interchangeable. A bridge device (e.g., MGate MB3170) that does TCP-to-serial still expects a Modbus RTU or ASCII slave on the serial side. A pure Modbus TCP slave cannot be polled over RS-485 by the same bridge without a separate TCP-to-TCP setup. The protocol primer at ProSoft Technology's Modbus TCP/IP introduction explains the framing differences clearly.
3. Proface / Schneider M221 / Click CPU may have Modbus server connection count limits. Schneider's M221 supports up to 4 simultaneous Modbus TCP server connections. AutomationDirect's CLICK C0-12DD1E-D supports up to 4. Both are enough for two clients plus engineering, but verify the exact number in the firmware manual before designing the topology. The CODESYS engineering thread at CODESYS Forge documents the equivalent 32/64-slave limit on the master side and the architectural reasons behind it.