Configuring Two TCP Connections on S7-315-2 PN/DP with TCON

A frequent integration scenario with the SIMATIC S7-315-2 PN/DP (CPU 315-2 EH14 or later, firmware V3.x) is to open two parallel TCP sockets from one PLC to a PC application — typically one channel for process data (Matlab, OPC, custom .NET service) and a second channel for diagnostics, HMI, or a redundant data path. Siemens' Open User Communication blocks (TCON, TSEND, TRCV, TDISCON) support multiple connections, but the first-time integrator almost always runs into the same symptom: the second FB300 TCON call returns STATUS = 16#7000 forever, and DONE never flips. The root cause is the same in nine out of ten cases, and it has nothing to do with the partner IP, the firewall, or the port number. This reference explains the full parameter stack, the byte-level layout of the Connection ID, and the field-proven commissioning procedure that gets both sockets up.

1. Problem Description

Symptom observed on a STEP 7 V5.5 / V5.6 project targeting an S7-315-2 PN/DP (6ES7 315-2EH14-0AB0):

• Connection 1 (e.g. ID = W#16#0001, port 2000) — FB300 TCON returns STATUS = 16#0000, DONE = TRUE. PC receives the SYN, data flows.
• Connection 2 (e.g. ID = W#16#0001, port 2001) — the engineer copies FB300, generates a new instance DB (DB301 for example), updates TCON_PARAM in UDT65 with the second port, but the call sits permanently at STATUS = 16#7000.
• No entry appears in the CPU diagnostic buffer, no partner SYN is sent, the PC never sees the second socket.

Status 16#7000 in the Open User Communication blocks is the placeholder value written when the instruction has no active job. It is not a fatal error — it is a "nothing to do" return. A persistently stuck 16#7000 almost always means the call is not being triggered correctly, the instance is wrong, or two TCON calls are configured to compete for the same internal connection resource.

2. Root Cause: Duplicate Connection ID Byte

On the S7-300/400 Open User Communication stack, every connection must be uniquely identified by the local Connection ID stored in UDT65 field id (WORD). Two TCON instances with the same id collide inside the CPU's connection resource table. The CPU silently refuses to start the second call, leaves it idle, and the call keeps reading the buffer where the previous job completed — so STATUS stays at the initial 16#7000.

The fix in the original Siemens support thread was to change the Connection ID Hi byte (the high-order byte of the W#16#xxxx WORD) of the second TCON. The Lo byte is the local connection number; the Hi byte carries additional routing/connection-class information and must be different for every concurrent connection when the CPU distinguishes the sessions by the high-order identifier.

3. Connection ID Byte Layout

The id field inside UDT65 TCON_PARAM is a 16-bit WORD with the following conventional split:

For a clean dual-connection design on the S7-315-2 PN/DP, the engineer can use either of the following ID schemes:

Either scheme works as long as the 16-bit values are unique. The original Siemens thread confirmed that incrementing the Hi byte resolved the issue when the Lo byte was already used for other S7 connections (HMI, PG, OP) on the same CPU.

4. UDT65 TCON_PARAM Structure

FB300 TCON takes a single TCON_PARAM pointer (any DB of type UDT65 "TCON_PARAM"). The UDT layout is:

Two parameters must be unique per TCON: the id WORD and the remote port in rem_tsap_id. The remote IP can be identical for both sockets (both sockets from the same PC) — that is normal. Setting both active_est = TRUE with the same remote IP is valid; the PLC will open two independent TCP sessions distinguished by the local port auto-assigned by the CPU and the unique Connection ID.

5. Step-by-Step Configuration for Two TCP Connections

1. Declare two instance DBs. In the S7 program, create DB100 as the instance for the first FB300 call and DB101 as the instance for the second. Generate them via the FB's "Instance DB" right-click menu so that the multi-instance layout is correct.
2. Declare two parameter DBs of type UDT65 "TCON_PARAM". For example DB200 for connection 1, DB201 for connection 2. Populate them per the table in §4.
3. Assign unique Connection IDs. Set DB200.id = W#16#0001, DB201.id = W#16#0101 (or any other 16-bit value not already used by HMI/OP/PG connections — check the CPU's connection table in NetPro or HW Config → CPU Properties → Communication).
4. Use unique remote ports. DB200.rem_tsap_id = port 2000 (0x07 0xD0), DB201.rem_tsap_id = port 2001 (0x07 0xD1). Verify the PC server is bound to both ports before commissioning.
5. Call FB300 twice with rising-edge REQ. A typical pattern is:

   // OB1 cyclic
   A  M 10.0  // First-start trigger (rising edge only)
   FP M 10.1
   =  "TCON_DB".REQ  // ... mapped to FB300.REQ for conn 1
   
   A  M 10.2  // Second-start trigger
   FP M 10.3
   =  "TCON_DB2".REQ  // ... mapped to FB300.REQ for conn 2
   
   CALL FB 300, DB100   // instance for conn 1
   REQ    := M10.1
   ID     := W#16#0001  // (also visible in UDT)
   DONE   := M20.0
   ERROR  := M20.1
   STATUS := MW22
   
   CALL FB 300, DB101   // instance for conn 2
   REQ    := M10.3
   ID     := W#16#0101
   DONE   := M20.2
   ERROR  := M20.3
   STATUS := MW24

6. Confirm the partner side. The PC application must listen() on both ports before the PLC issues connect(). A netstat -an | findstr :2000 from a Windows shell will show whether the sockets are in LISTENING state.
7. Download and go online. Watch STATUS on both TCON calls. The expected sequence is 16#7000 (idle) → 16#7001 (job running) → 16#0000 (done) on a successful connection. A return of 16#7000 on the second call after a successful first call indicates the Connection ID collision; correct the ID and reload.

6. Connection Resource Planning on S7-315-2 PN/DP

CPU connection resources are finite and shared with all other communication partners: HMI, PG/PC online, S7 communication (PUT/GET), routing, and Open User Communication. For the 6ES7 315-2EH14-0AB0 (CPU 315-2 PN/DP, firmware V3.3):

7. Active vs Passive Connection Establishment

The active_est BOOL inside UDT65 selects the endpoint role:

For two simultaneous sockets to a single PC, the most common pattern is both set to TRUE. The PLC then dials the same PC IP twice on two different remote ports. This works because the CPU picks a unique local port for each outgoing connection, even when the destination IP is identical. If the field environment is sensitive to outbound connection attempts (corporate firewall), use one active + one passive — but the ID uniqueness rule still applies.

8. Status Code Reference for FB300 TCON

9. Verification Procedure

1. Watch the CPU diagnostic buffer. Online → CPU → Diagnostic Buffer. A successful TCON produces entry "Connection established" with the configured ID. A failed attempt leaves a "Connection aborted / setup error" entry that points at the offending ID.
2. Inspect the connection table. STEP 7 → NetPro → right-click the CPU → "Connection Status". Both connections should appear in state ESTABLISHED.
3. Check the PC side. From a Windows shell, run netstat -ano | findstr :2000 and netstat -ano | findstr :2001. Each command should return one row with state ESTABLISHED and the PLC IP as the foreign address.
4. Run a one-shot TSEND / TRCV cycle. Send a 4-byte handshake (e.g. 16#11 22 33 44) from the PC on port 2000, verify receipt via FB202 TRCV on the matching ID, and repeat on port 2001.
5. Force a disconnect / reconnect cycle. Call FB301 TDISCON on connection 1, observe 16#0000, then re-trigger FB300. Both connections should re-establish without cycling the CPU.

10. Troubleshooting Matrix

11. Related Blocks and Companion Calls

12. Field-Proven Notes

• Match ID across TCON, TSEND, TRCV, TDISCON. A common follow-on error is to update the id in the TCON_PARAM DB but leave the literal ID input on the FB call set to the old value. The runtime accepts the literal; the UDT value is ignored. Always pass the same WORD via the FB's ID input.
• Keep the parameter DB standard-access. On S7-300/400 classic blocks, optimised (sliced) access is not supported. If you allow STEP 7 to default to optimised access on a new DB, FB300 will return 16#8086 or behave erratically. Set the DB to Standard in the DB properties.
• Update the CPU firmware if reusing IDs across reboots. On older firmware (V2.x of the 315-2 PN/DP), the connection table was not always cleared on a warm restart, leading to apparent ID collisions after a stop/run. Upgrade to V3.3 or later if your project is new.
• Document the IDs in NetPro even if using Open User Communication. A placeholder S7 connection in NetPro with a free ID is a useful bookkeeping trick to avoid the Hi-byte collision in the first place.

13. FAQ