S7-300 CPU 315-2 PN/DP Open TCP Communication via PN Port

1. Overview and Problem Statement

Two Siemens SIMATIC S7-300 CPU 315-2 PN/DP stations must exchange user data over their integrated PROFINET (PN) interfaces. Engineers familiar with the classic S7-300/400 approach (NetPro configured S7 connection, PUT/GET, BSEND/BRCV) attempt the same workflow on the PN port and find that the connection editor behaves differently: the PN interface of an S7-300 CPU does not expose the same configured-connection resources as a CP343-1 or a CP443-1 module.

The correct approach is the Open Communication via Industrial Ethernet family of function blocks. Instead of configuring a static S7 connection, the programmer builds a connection description DB that is handed to FB65 TCON at runtime, then transfers payload with FB67 TUSEND / FB68 TURCV and tears the link down with FB66 TDISCON. The connection DB replaces the NetPro dialog and is the only valid configuration entry point for open TCP, ISO-on-TCP and UDP over the integrated PN port of the CPU 315-2 PN/DP.

Typical symptoms that drive engineers to this article:

• Local/remote port fields are missing in HW Config because the PN interface is not a CP module.
• PUT / GET blocks time out (SF LED on, diagnostic buffer entry "connection resource not configured").
• Only one direction works (A → B) while the reverse path stays idle.
• NetPro shows the two stations online but no S7 connection object exists between them.

2. Hardware and Software Prerequisites

Firmware matters: CPU 315-2 PN/DP ships with two main firmware generations (V2.x and V3.x). V3.x increased the number of open communication resources to 16, whereas V2.x is limited to 8. If you plan bidirectional data plus reserved HMI connections, prefer V3.2 or V3.3.

3. Why NetPro Does Not Configure the PN Port

On an S7-400 or an S7-300 with a CP343-1, NetPro shows a "PN-IO" or "Ethernet" interface object that accepts a configured S7 connection. For the integrated PROFINET interface of a CPU 315-2 PN/DP, NetPro displays the port properties (IP address, subnet mask, router) but the right-click "New Connection" option is grayed out for S7 connections. The reason is architectural: the PN stack of the S7-300 CPU does not contain the configured-connection resource class; it only contains the open-communication resource class.

Consequences:

1. IP, subnet, and PROFINET device name are still configured in HW Config or in the device properties of the PN interface.
2. Transport ports (TCP/UDP port numbers, e.g. 2000) are not an HW Config field. They live in the connection DB that you hand to TCON.
3. The connection itself is established at runtime, not at project download time.

4. Project Setup and IP Configuration

1. Open SIMATIC Manager and create a new S7-300 station for each CPU.
2. Insert the CPU 315-2 PN/DP from the hardware catalog (SIMATIC 300 → CPU 300 → CPU 315-2 PN/DP → 6ES7 315-2EH14-0AB0).
3. Double-click the PN port row (X2) in the station view. In the Properties dialog, assign a fixed IP address (avoid DHCP for deterministic control traffic):
   • CPU A: IP 192.168.0.10, Subnet 255.255.255.0, no router.
   • CPU B: IP 192.168.0.11, Subnet 255.255.255.0, no router.
4. If the two CPUs are directly patched, set the PROFINET device name to match the station name (e.g. cpu_a, cpu_b) and disable the PROFINET IO controller role. Open communication does not require PROFINET IO, only the IP layer.
5. Compile and download HW Config to both CPUs.

5. The Open Communication Wizard

Manually building the connection DB is error-prone (the TCON_PAR UDT has dozens of fields). Siemens provides the Open Communication Wizard that generates a ready-to-use DB plus a starter instance of FB65 TCON.

1. Launch the wizard from the Windows Start menu (installed with STEP 7) or download the current version from Siemens Support entry 24239907.
2. Select the S7 project, the CPU station, and the protocol: TCP (not ISO-on-TCP and not UDP for this use case).
3. Specify the partner:
   • Partner type: specified partner (active or passive) or unspecified for broadcast-free server mode.
   • Partner IP: 192.168.0.11 (CPU B).
   • Partner port: 2000 (decimal).
   • Local port: 2000 (decimal).
4. Connection name: e.g. TCP_A_to_B. The wizard creates DB100 (configurable) containing the TCON_PAR structure.
5. Tick "Generate instance DB for TCON" – the wizard inserts FB65 with its instance DB into OB1.
6. Repeat on CPU B, mirroring local/remote IP and ports.

6. Connection Parameter DB Layout

The generated DB contains a structure of type TCON_PAR. The fields relevant to TCP are:

7. Calling the Open Communication Blocks

The four FBs sit in the standard library Communication Blocks under CP 300 / CPU 300. Copy them into your program so the calls become part of the project, not the library reference.

7.1 FB65 TCON – Establish connection

CALL "TCON" , DB_TCON   // instance DB auto-generated by wizard
REQ    := M10.0          // rising edge starts the connect attempt
ID     := W#16#0001      // matches the id field in the connection DB
DONE   := M20.0          // one cycle TRUE on success
BUSY   := M20.1          // TRUE while the connect attempt runs
ERROR  := M20.2          // TRUE on protocol error
STATUS := MW22           // detailed error code (see section 10)
CONNECT:= "TCP_A_to_B".TCP_PAR  // pointer to TCON_PAR in DB100

7.2 FB66 TDISCON – Tear down

CALL "TDISCON" , DB_TDIS
REQ    := M11.0
ID     := W#16#0001
DONE   := M21.0
BUSY   := M21.1
ERROR  := M21.2
STATUS := MW24

7.3 FB67 TUSEND – Send user data over TCP

CALL "TUSEND" , DB_SEND
REQ    := M12.0          // trigger with rising edge
ID     := W#16#0001
LEN    := 20             // bytes to send, <= 8192
DONE   := M22.0
BUSY   := M22.1
ERROR  := M22.2
STATUS := MW26
DATA   := P#DB20.DBX0.0 BYTE 20   // source data area

7.4 FB68 TURCV – Receive user data over TCP

CALL "TURCV" , DB_RCV
EN_R   := M13.0          // enable reception
ID     := W#16#0001
RCVD_LEN := MW28         // actually received length
NDR    := M23.0          // new data received
ERROR  := M23.2
STATUS := MW30
DATA   := P#DB21.DBX0.0 BYTE 800   // receive buffer

8. Bidirectional Data Flow on One Connection

A common engineering question after the first successful transfer is: "A sends to B and it works, but how does B send to A on the same connection?"

TCP is full-duplex. A single established connection carries traffic in both directions simultaneously. The send and receive FBs use the same connection ID and operate independently:

• CPU A calls TUSEND with ID=1 → bytes leave A, arrive at B's receive buffer managed by TURCV with ID=1.
• CPU B calls TUSEND with ID=1 → bytes leave B, arrive at A's receive buffer managed by TURCV with ID=1.

No second connection is required. The asymmetry in the early-stage report comes from a typical mistake: the receive FB is never called on the receiving CPU, or its instance DB is not loaded, so RCVD_LEN stays at 0 and the user thinks the path is dead. Cyclically call TURCV in OB1 (with EN_R := TRUE) so the stack can dispatch incoming frames into the receive buffer at any time.

9. Active vs Passive Connection Establishment

For two CPU 315-2 PN/DP units, configure one side active and the other passive. If both are active, the SYN packets race and at least one side may report error 0x80C4 (connection already established, second attempt rejected). If both are passive, neither initiates, and the link never opens.

10. Status and Error Code Reference

11. Verification Procedure

1. On CPU A, force M10.0 to TRUE once. Observe M20.1 go TRUE, then M20.0 TRUE → connection established.
2. On CPU B, the stack should report the incoming connection on its TURCV background path. Check the diagnostic buffer of CPU B for entry "Connection established (active: yes, ID=1)".
3. Set a recognizable pattern in DB20 (e.g. 20 bytes of 16#AA), trigger TUSEND on CPU A, and watch DB21 on CPU B fill with the same pattern after a few OB1 cycles.
4. Reverse the direction: write to DB30 on CPU B, trigger its TUSEND, verify DB31 on CPU A updates.
5. Use the STEP 7 online dialog PLC → Information → Connection Overview to view the live state of connection ID 1. It should show status Established with bytes-sent and bytes-received counters increasing in both directions.

12. Troubleshooting Matrix

13. Field-Proven Caveats

• Watchdog during long blocking calls. TUSEND and TURCV complete in one OB1 cycle for short payloads, but a 4 KB transfer may span two or three cycles. Increase OB1 cycle budget accordingly or partition the data into ≤ 1 KB chunks.
• Port 2000 is the historical Siemens default but is not reserved; any free port 1024..65534 is acceptable. Some plant firewalls block high ports, so 2000 often works in production networks already permitted for S7 communication.
• CPU 315-2 PN/DP firmware V2.x ships with a smaller open-communication stack. If you hit STATUS = 80C3 even with a single connection, upgrade to V3.2 or later.
• PROFINET device name and IP are independent. Open TCP needs only the IP. You can disable the PROFINET IO controller role entirely to free CPU resources if the controller functionality is not used.
• Connection DBs are downloaded as part of the S7 program. A common field failure is the programmer updates the DB online and forgets to save it offline. After a CPU stop/start, the wizard-generated value is lost.

14. Summary Workflow

1. Assign fixed IP addresses to both PN ports in HW Config.
2. Run the Open Communication Wizard on each CPU, generate connection DB and TCON instance.
3. Download HW Config + program blocks (FB65..FB68 + instance DBs + connection DB) to both CPUs.
4. Wire the send/receive FBs in OB1 (and OB100 for restart handling).
5. Trigger TCON once on power-up, then call TUSEND / TURCV cyclically.
6. Verify both directions via the connection overview and the receive DB contents.

Following this procedure turns the PROFINET port of the CPU 315-2 PN/DP into a deterministic TCP transport, supporting both unidirectional and bidirectional user-data exchange between two S7-300 stations without requiring a CP module or a configured S7 connection.