Troubleshooting Modbus TCP Server Connection on S7-1200 PLC

Troubleshooting Modbus TCP Server Connection on S7-1200 PLC

When commissioning an S7-1200 CPU as a Modbus TCP server and connecting it to a PC-based test client, two symptoms dominate the field: (1) the TCP session establishes briefly while the instruction STATUS reports 16#7002 and then drops the moment STATUS returns 16#0000, and (2) the client can read holding registers but writes to the same registers silently fail. This article consolidates the official Siemens instruction behavior, the relevant STATUS codes, and the configuration settings that resolve both issues without changing the topology.

1. Problem Overview

A typical symptom chain reported during commissioning:

1. The PC client (e.g., SimplyModbus, Modbus Poll) successfully opens a TCP session on port 502 of the S7-1200.
2. On the PLC side, the MB_SERVER instance DB shows STATUS = 16#7002 (job processing) and the client can perform one or more transactions.
3. Once STATUS returns to 16#0000, the client loses the connection, and reconnect attempts fail until the PLC program is re-downloaded.
4. Read FC03/FC04 operations succeed, but FC06/FC16 write attempts either time out or return an exception code 04 (slave device failure) on the client.

These symptoms are almost always traced to one of three root causes: the MB_SERVER instance is not being called cyclically, the holding-register pointer block has been optimized (which blocks Modbus access), or the TSAP / port assignment on the S7-1200 conflicts with another service.

2. MB_SERVER and MB_CLIENT Instruction Roles

The SIMATIC S7-1200 supports Modbus TCP natively through the PROFINET interface. Two primary instructions are used:

For the scenario in the source post, the S7-1200 acts as the server and the PC is the client. The full instruction reference is published in the SIMATIC S7-1200 Programmable Controller Manual Collection, specifically the Modbus TCP Instructions (MB_CLIENT, MB_SERVER) section in the Siemens TIA Portal documentation portal.

3. Prerequisites: Firmware and TIA Portal Versions

Verify the CPU firmware with TIA Portal: Online > Accessible devices > right-click CPU > Online & diagnostics > Diagnostics. The firmware version is reported under "Module information".

4. Configuring MB_SERVER as a Modbus TCP Server

4.1 Create a Holding Register Data Block

1. In the project tree, select Add new block > Data block (DB).
2. Uncheck Optimized block access. Optimized DBs cannot be addressed by Modbus function codes because the byte offset is not deterministic.
3. Define the registers. For example:

DATA_BLOCK "ModbusRegisters"
{ S7_Optimized_Access := 'FALSE' }
VERSION : 0.1
NON_RETAIN
  STRUCT
    HoldingReg : ARRAY[0..99] OF WORD;   // 100 holding registers, FC03/FC06/FC16
    InputReg   : ARRAY[0..99] OF WORD;   // 100 input registers, FC04
  END_STRUCT;
END_DATA_BLOCK

4. Note the absolute byte offset of HoldingReg[0]. In a non-optimized DB, the offset is the sum of preceding static data; here, HoldingReg starts at offset 0.

4.2 Insert and Wire MB_SERVER

1. Open the main OB (typically OB1) and drag MB_SERVER from the task card into a network.
2. Create an instance DB when prompted (e.g., MB_SERVER_DB).
3. Wire the input parameters:

3. Ensure MB_SERVER is called every scan cycle. Placing it in OB1 is the most common and reliable approach. Do not call it conditionally (gated by a flag or inside a slow OB), or the server will appear to "stop responding" the moment the condition is false.

5. STATUS Code Reference Table

The following STATUS values are documented for MB_SERVER and MB_CLIENT. Codes are 16-bit words; values are hexadecimal. Refer to the in-editor Help panel for the active CPU firmware's full list.

6. PC Test Client Options for S7-1200

6.1 Recommended Test Clients

6.2 Client Connection Settings to Match the S7-1200

• Remote IP: the S7-1200's IP address (e.g., 192.168.0.10). Confirm with the S7-1200's display or with TIA Portal's Online & diagnostics > IP address.
• Remote port: 502 (default for MB_SERVER; can be changed in the instance DB if required by plant network policy).
• Connect timeout: ≥ 3 seconds. Some clients default to 1000 ms, which is shorter than the S7-1200's first-response window after startup.
• Unit ID (Slave ID): any value 0..255; the S7-1200 server ignores it for TCP.
• Polling interval: ≥ 100 ms. Aggressive polling (≤ 20 ms) saturates the CPU's background communication tasks and can mask intermittent STATUS codes.

7. Root Cause: Connection Drops When STATUS Returns to 0000

There are three independent causes that produce this symptom; in field reports, the first is by far the most common.

7.1 MB_SERVER Is Not Called Cyclically

The instruction processes incoming TCP frames only on the PLC scan in which it is called. If the call is in OB1, it runs every cycle. If it is inside a function that is called only on a trigger (for example, "call only when M0.0 = 1"), the instruction misses TCP segments between calls. The client sees a successful first transaction (STATUS cycles 7002 → 0000), the connection then sits idle from the PLC's perspective, and the client's keep-alive timer expires.

Fix: Place the MB_SERVER call unconditionally in OB1 (or in the cyclic OB the project uses as the main scan). Verify by watching MB_SERVER_DB in online mode: NDR and DR should toggle with every request when the client is polling.

7.2 DISCONNECT Input Is Being Driven True

If the DISCONNECT input is wired to a tag that becomes TRUE at any point, the active connection is closed and the server returns to the listening state. STATUS will be 0000 after the close. Check the rung driving DISCONNECT; in many projects it is wired to a startup flag that is never cleared.

Fix: Drive DISCONNECT only on an explicit operator action or fault condition. Use a normally-open contact on a fault tag, not a latched power-on flag.

7.3 Firewall or Anti-Virus Closes the Idle Socket

Windows firewall and most enterprise anti-virus suites treat long-lived, low-traffic TCP sessions as suspicious and close them after a few minutes. The Modbus TCP test client appears to "lose the connection" right after the first successful exchange.

Fix: Add a Windows firewall rule that allows inbound TCP 502 for the test client's executable. Configure the client to send a periodic poll (every 5-10 s) to keep the socket warm. For production gateways, prefer a managed industrial Ethernet switch with QoS rather than a software client.

8. Root Cause: Cannot Write to Registers

If read (FC03/FC04) works but write (FC06/FC16) returns exception 02 (illegal data address) or 04 (slave device failure), inspect the following:

8.1 Holding-Register DB Is Optimized

An optimized data block has no fixed offset. The MB_HOLD_REG pointer relies on a deterministic byte offset, so an optimized DB is invisible to Modbus function codes. Writes return exception 04.

Fix: In the DB properties, uncheck Optimized block access. Recompile and redownload. Verify the DB properties in the project tree; the check box is in the DB's Attributes tab.

8.2 The MB_HOLD_REG Pointer Does Not Match the DB Layout

The pointer is of the form P#<DB number>.DBX<byte offset>.0 WORD <length>. A common mistake is to point at the wrong DB or to declare a length that exceeds the array. The Modbus server then returns exception 02 for any address that falls outside the array.

Fix: Right-click the HoldingReg[0] tag in the DB, choose Copy symbolic information, and paste the absolute address into MB_HOLD_REG. The pointer's length field must match the array size exactly.

8.3 Address Offset in the Client Is Off by One

Modbus addressing is 0-based in the protocol but 1-based in many client tools. If the test client uses "40001" as the first holding register, the request is for address 0x0000; if it uses "40000", the request is for address 0xFFFF (broadcast-equivalent), which the server rejects with exception 02. Always confirm with FC03 first: read one register at the client's "address 0" and verify the value against the PLC's online monitor.

8.4 FC06 / FC16 Use a Different Data Block Than the Pointer Suggests

Some sample programs on the web wire MB_HOLD_REG to a different DB than the one being written. Confirm the pointer in the MB_SERVER_DB instance data block at IDB.HOLD_REG_PTR and trace the symbolic reference back to the source.

9. Verification Procedures

After applying the fixes, run the following verification sequence.

1. Download the project to the S7-1200 and go to RUN.
2. Open the MB_SERVER_DB instance data block in TIA Portal online mode and confirm STATUS = 16#0000, CONNECTED = FALSE.
3. Start the PC test client, configure remote IP = CPU IP, remote port = 502, polling interval = 1 s, function = FC03, address = 0, length = 10.
4. Confirm the client shows valid words and that MB_SERVER_DB toggles NDR on every poll.
5. Issue an FC06 write to address 0 with a recognizable pattern (e.g., 0xAAAA) and read back with FC03. Verify the value appears in the online DB monitor.
6. Issue an FC16 multi-write to addresses 0..3 with a sequence. Verify all four registers in the online DB monitor.
7. Leave the connection idle for 5 minutes and confirm the client does not report a dropped socket. If it does, see §7.3.

10. Summary of Settings That Resolve the Source Symptom

11. Related Official Documentation

For deeper configuration and the full STATUS-code list for the CPU firmware in use, refer to:

• MB_CLIENT / MB_SERVER instruction reference in the SIMATIC S7-1200 Manual Collection (TIA Portal documentation portal)
• SIMATIC S7-1200 Programmable Controller System Manual, chapter on "Modbus TCP communication" — accessible from the same TIA Portal documentation portal under the S7-1200 system manual entry.
• Modbus Application Protocol Specification V1.1b3 — published by the Modbus Organization (modbus.org), the authoritative reference for function codes and exception codes.