Configuring Modbus TCP on S7-1500: TIA Portal V12+ Technical Reference

This reference covers the engineering, commissioning, and field-troubleshooting of Modbus TCP communications on the S7-1500 family using the native MB_CLIENT and MB_SERVER instructions in the TIA Portal. The focus is on programmed connections using the TCON_IP_V4 data structure, the most common variant in field deployments, with explicit attention to hardware identifier selection, the MB_DATA_PTR pointer rules, and the most common STATUS error codes reported in commissioning (809B, 818B, 8086, 80C8, and others).

The native Modbus TCP instructions were introduced for the S7-1500 in TIA Portal V12 SP1 (released via the firmware/support download at Siemens Industry Online Support) and have been refined in subsequent releases. The configuration mechanism is similar on the S7-1200, but the S7-1500 has the additional advantage of being simulated with PLCSIM Advanced, which simplifies bench validation before deployment to a real CPU.

1. Prerequisites and Compatibility

2. Connection Architecture: TCON_Configured vs Programmed TCON_IP_V4

The S7-1500 supports two distinct ways to define a Modbus TCP connection.

2.1 Configured Connection (TCON_Configured)

The connection is established in the TIA Portal "Devices & Networks" editor under "Connections". The TIA Portal generates a connection DB that holds a TCON_Configured structure. This approach is preferred when:

• The peer IP and port are static and known at design time.
• The same connection is used by multiple program blocks.
• You want automatic download of connection parameters with the hardware configuration.

2.2 Programmed Connection (TCON_IP_V4)

The connection parameters live in a user data block that contains a variable of system data type TCON_IP_V4. This approach is preferred when:

• The peer IP/port is dynamic (computed at runtime, e.g., a recipes-driven IP).
• You need to spin up many connections (one per peer) from a single FB.
• You want to keep all connection metadata in the user program rather than the hardware config.

Both approaches consume the same CPU connection resources and behave identically at runtime as far as the Modbus instructions are concerned. The block's CONNECT input accepts either variant.

3. Building a TCON_IP_V4 Data Block

Manual creation is straightforward:

1. Add a new global DB (e.g., Client_Send_DB).
2. In the DB, add a new variable, name it Connection.
3. In the "Data type" column, type TCON_IP_V4 literally. The type browser will not show it — it must be entered by hand.
4. Fill the structure fields per the table below.

4. Configuring MB_CLIENT (Modbus Client Role)

MB_CLIENT is called cyclically (typically every OB1 cycle) and is edge-sensitive on REQ. Each rising edge on REQ triggers one Modbus transaction.

4.1 Inputs

4.2 Outputs

4.3 Function Code Mapping

5. Configuring MB_SERVER (Modbus Server Role)

MB_SERVER is a passive listener. It does not require a REQ edge. Internally it calls TCON/TRCV/TSEND/TDISCON based on the connection state machine.

5.1 Critical Configuration Rules

• Set ActiveEstablished = FALSE in the TCON_IP_V4.
• Set RemotePort = 0 to accept any client port, or set a specific value to filter.
• Set RemoteAddress to all-zeros ([0,0,0,0]) for any-client, or to a specific client IP for one-client-only.
• Specify a LocalPort (typically 502). A single MB_SERVER instance is bound to a single port.

5.2 Multiple Clients on a Single CPU

To accept multiple simultaneous clients, instantiate one MB_SERVER call (with its own connection DB and instance DB) per port. See Section 11 for a worked example with port 502 and 503.

6. MB_DATA_PTR: Pointer Formats and Data Types

The MB_DATA_PTR accepts two addressing modes on the S7-1500.

6.1 Absolute Pointer (S7-300/400 Style)

Use a fully qualified pointer in the M area or in a non-optimized DB:

P#M0.0 BYTE 100   // 100 bytes starting at MB0
P#DB10.DBX0.0 BYTE 200   // 200 bytes in DB10 (any structure allowed)

This form is mandatory when the data block has standard (non-optimized) access. The DB itself may contain any data type structure.

6.2 Symbolic Pointer (Optimized Block)

For optimized DBs (default for S7-1500), pass a tag of an array of WORD or INT (registers) or an array of BOOL (bits):

"Data".HoldingReg[0..9]      // array of INT, 10 elements, FC03 read
"Data".Coils[0..31]          // array of BOOL, 32 elements, FC01 read
"Data".InputReg[0..4]        // array of INT, FC04 read

7. ID Parameters: CONNECT ID vs MB_Unit_ID

Two distinct identifiers are in play. Confusing them is one of the most common setup errors.

8. Hardware Identifier (InterfaceId) Configuration

The InterfaceId in TCON_IP_V4 is the hardware identifier of the interface, not of the module. On a CP 1543-1, the module itself and each of its ports (X1, X2) have separate identifiers in TIA Portal.

8.1 Locating the Correct Hardware ID

1. Open the Device View of the CPU/CP.
2. Select the port to which the Ethernet cable is physically attached.
3. Open Properties → System constants.
4. Note the value next to "Hardware identifier" — that is the InterfaceId.

8.2 Common Interface ID Errors

• Using the module ID (e.g., 259) instead of the port ID (e.g., 260) → 809B.
• Using a value below 64 (default CPU interface) when traffic is going through a CP → 809B.
• Using a value above 64 that is not a valid hardware identifier → 8086 (ID out of range) or 80C8 (resource problem).

9. Error Code Reference and Diagnostics

The STATUS output of MB_CLIENT and MB_SERVER returns hex codes drawn from the TCON instruction set and Modbus specification.

10. Multi-Port Server: Supporting Multiple Modbus TCP Clients

A single MB_SERVER instance is bound to one local port. To accept N simultaneous clients, instantiate N MB_SERVER blocks, each with:

• Its own connection DB (different LocalPort).
• Its own instance DB.
• Its own data buffer tags (use the same symbolic tags if the same data must be exposed to all clients).

10.1 Example: Two Servers on Ports 502 and 503

Both blocks must be called in OB1. Each will accept the first client that connects to its port. The data tags in user memory (e.g., "Modbus".HoldingReg) can be shared symbolically across both blocks.

11. Vendor Interoperability Notes

12. Verification and Commissioning Checklist

Use this sequence on first power-up of any S7-1500 Modbus TCP link.

1. Network reachability. From a laptop on the same subnet, ping the CPU's PROFINET IP. Confirm the port LED on the CP/CPU is lit.
2. Watch table test. Force MB_CLIENT.REQ = TRUE for a read of FC03 from address 0, length 1. Observe DONE going high and the data in MB_DATA_PTR updating.
3. Server visibility. From a Modbus client tool (e.g., mbpoll on Linux, "Modbus Tools" on Windows), poll the CPU's IP on port 502. Confirm that the data is mirrored in MB_SERVER's configured tags.
4. STATUS inspection. While the link is idle, observe STATUS = 7000 (client) or 7000 (server). A non-zero STATUS that does not match the table in Section 9 indicates a configuration error.
5. Disconnect / reconnect. Pull the Ethernet cable at the remote end. Confirm STATUS moves to 80A8 or similar, then recovers to 7000 when the cable is reinserted.
6. Multi-client stress. Connect two clients on ports 502 and 503. Verify both MB_SERVER instances report STATUS = 7000 and respond to polls.
7. Throughput check. With FC03 reads at 100 ms cadence, confirm the cycle time impact on OB1 is < 5 ms on a typical S7-1516.

13. Frequently Asked Questions

References and Documentation

• Siemens Industry Online Support: Modbus/TCP with instructions MB_CLIENT and MB_SERVER (sample project) — net_modbus_tcp_s7-1500_s7-1200_en.pdf
• Siemens Industry Online Support entry 76276623 — STEP 7 V12 SP1 release notes / S7-1500 firmware
• S7-1500 Communication Function Manuals (S7-1500, ET 200MP communication) — S7-1500 Communication Function Manual on Siemens Industry Online Support