S7-300 CPU 319-3 PN/DP Ethernet OUC with TCON TSEND TRCV

Overview

The SIMATIC S7-300 CPU 319-3 PN/DP (order number 6ES7318-3EL01-0AB0, firmware V3.x) provides three integrated interfaces: PROFIBUS DP/MPI (X1), PROFIBUS DP (X2), and PROFINET/Ethernet (X3, two-port switch). The PROFINET interface supports Open User Communication (OUC) without requiring an additional CP module or NetPro/STEP 7 configuration of a connection table. Two CPUs can therefore exchange data block content directly across the X3 ports using the standard library blocks TCON, TSEND, TRCV, and TDISCON.

This document describes how to transfer the contents of two data words from DB1 of one CPU 319-3 PN/DP (the active partner) to DB1 of a second CPU 319-3 PN/DP (the passive partner) using TCP. The procedure also applies to UDP by switching the ConnectionType parameter and replacing TSEND/TRCV with TUSEND/TURCV.

Reference documentation:

• SIMATIC S7-300 CPU 31xC and CPU 319-3 PN/DP Manual (entry ID 12996906)
• Open User Communication - Communication and Services FAQ (entry ID 20982954)
• STEP 7 V5.5 / STEP 7 Professional - Communication Blocks, Standard Library.

Prerequisites

1. Two functional CPU 319-3 PN/DP stations with firmware 3.2 or higher (OUC was enabled on the PN interface from FW 2.x onward, but FW 3.x is recommended for stable behavior on the integrated port).
2. STEP 7 V5.5 SP2 or later (or STEP 7 Professional V14/V15/V16 with S7-300 work area) with the Standard Library -> Communication Blocks installed.
3. An Ethernet patch cable (Cat 5e or higher) or shared 100 Mbit switch between the two X3 PROFINET ports.
4. Unique IPv4 addresses on the same subnet for both CPUs.
5. Programming device (PG) with online access to both CPUs (e.g., via PROFIBUS MPI or one of the PROFINET ports).

Hardware and Interface Topology

The CPU 319-3 PN/DP front panel exposes the following connectors, listed left-to-right:

The integrated 2-port managed switch means the two CPUs can be cabled back-to-back (P1 of CPU A to P1 of CPU B) or via a third-party switch. Link/Activity LEDs are present on each RJ45 port.

Network and IP Configuration

Configure static IPv4 addresses in HW Config (or via the PG online function Accessible Nodes) before commissioning the OUC blocks. A simple example:

Open HW Config, double-click CPU 319-3 PN/DP -> Properties PN-IO, and enter the IP address and subnet mask. Save and download hardware configuration to each CPU individually before continuing.

Connection Planning - Active vs Passive

In TCP, one side must actively open the socket. With TCON this is controlled by the ActiveConnection bit inside the connection description (UDT 65 "TCON_PAR"). Either side can be active; the typical pattern is:

• Active side (CPU A): establishes the connection on rising edge of REQ at TCON, then triggers TSEND with a periodic or event-driven REQ.
• Passive side (CPU B): calls TCON with ActiveConnection = FALSE; this opens a listen socket and TRCV is then permanently enabled to capture incoming frames.

Only one active partner is required. Multiple passive partners can be reached by using distinct local ports or by using UDP broadcast/multicast, but for the basic two-CPU scenario described here a single active/passive pair is sufficient.

Step-by-Step Configuration

Step 1 - Declare the Connection Description (UDT 65 "TCON_PAR")

The TCON, TSEND, TRCV, and TDISCON blocks share a connection identifier. Each connection requires a DB of UDT 65 ("TCON_PAR") describing the endpoint. Open the S7 program, create a shared DB (e.g., DB100 "ConnDB"), and declare a variable of type TCON_PAR (UDT 65 from the Standard Library):

DATA_BLOCK DB100
TITLE = OUC Connection Description
STRUCT
  TCON_Params : TCON_PAR;     // UDT 65
END_STRUCT
BEGIN
  TCON_Params.BlockType       := B#16#01;   // 1 = TCON
  TCON_Params.ConnectionType  := B#16#11;   // 17 decimal = TCP
  TCON_Params.ActiveConnection:= TRUE;      // TRUE = active open
  TCON_Params.LocalDeviceID   := B#16#01;   // 1 = integrated PN
  TCON_Params.LocalTSelectorID:= 0;
  TCON_Params.LocalTSelector  := '';
  TCON_Params.RemoteTSelectorID := 0;
  TCON_Params.RemoteTSelector   := '';
  TCON_Params.RemAddress      := '192.168.0.20';  // Remote IP (CPU B)
  TCON_Params.RemPort         := W#16#09C4; // 2500 decimal
  TCON_Params.LocalPort       := W#16#0000; // 0 = let CPU assign for active side
  TCON_Params.ConnectionName   := 'PLC_A_to_PLC_B';
END_DATA_BLOCK

For the passive side (CPU B), use ActiveConnection := FALSE, set LocalPort := W#16#09C4 (2500), and set RemAddress to '192.168.0.10'.

Step 2 - Create the Send/Receive Data Blocks

Both CPUs need a DB whose data area will be referenced by TSEND/TRCV. The structure must match on both sides; for two words use a simple WORD array or a STRUCT of two WORDs:

DATA_BLOCK DB1
TITLE = Application Data
STRUCT
  W1 : WORD;     // First word to exchange
  W2 : WORD;     // Second word to exchange
END_STRUCT
BEGIN
  W1 := W#16#0000;
  W2 := W#16#0000;
END_DATA_BLOCK

Step 3 - Call TCON in OB1 (Active Side, CPU A)

Call the TCON FB (FB65) with a unique instance DB, the connection ID, and a one-shot trigger to establish the connection:

       CALL  FB65  "TCON" , DB65
       REQ        :=M10.0          // Rising edge starts connect
       ID         :=1              // Connection ID 1..16 (must be unique)
       CONNECT    :=P#DB100.DBX0.0 BYTE 40   // Pointer to TCON_PAR
       DONE       :=M20.0
       BUSY       :=M20.1
       ERROR      :=M20.2
       STATUS     :=MW22

On the passive side (CPU B), TCON is called with REQ := TRUE and held - TCON on a passive partner listens indefinitely and only requires a single edge when the connection drops and needs re-establishment. A typical pattern is to call TCON cyclically with REQ tied to the negation of the connection's status (or with the output of a watch-dog block).

Step 4 - Call TSEND (Active Side, CPU A)

       CALL  FB63  "TSEND" , DB63
       REQ        :=M11.0          // Edge triggers one send
       ID         :=1
       LEN        :=4              // 2 words = 4 bytes
       DATA       :=P#DB1.DBX0.0 BYTE 4
       DONE       :=M21.0
       BUSY       :=M21.1
       ERROR      :=M21.2
       STATUS     :=MW24

Set M11.0 every 100 ms (e.g., from a clock bit) for periodic transmission, or trigger from a process event. The TCON connection must be established (DONE=TRUE, BUSY=FALSE) before the first TSEND, otherwise STATUS returns W#16#8085 (job still active or wrong call order).

Step 5 - Call TRCV (Passive Side, CPU B)

       CALL  FB64  "TRCV" , DB64
       EN_R       :=TRUE           // Always ready to receive
       ID         :=1
       LEN        :=4              // Max bytes expected per call
       DATA       :=P#DB1.DBX0.0 BYTE 4
       NDR        :=M23.0          // New data received flag
       BUSY       :=M23.1
       ERROR      :=M23.2
       STATUS     :=MW26
       RCVD_LEN   :=MW28

With EN_R = TRUE, TRCV is permanently ready and writes the received payload into DB1.W1 and DB1.W2. The NDR flag pulses for one cycle each time a new telegram is accepted.

Step 6 - Call TDISCON on Shutdown

Use TDISCON (FB66) in OB100 (restart) or on a controlled stop to release the connection cleanly:

       CALL  FB66  "TDISCON" , DB66
       REQ        :=M0.0           // Stop signal (e.g., from OB100)
       ID         :=1
       DONE       :=M30.0
       BUSY       :=M30.1
       ERROR      :=M30.2
       STATUS     :=MW32

Complete Active-Side OB1 Snippet (STL)

// ---- Establish connection ----
A   M 10.0           ; Connect trigger (one-shot)
=   L 0.0
CALL FB65, DB65
   REQ    :=L0.0
   ID     :=1
   CONNECT:=P#DB100.DBX0.0 BYTE 40
   DONE   :=M 20.0
   BUSY   :=M 20.1
   ERROR  :=M 20.2
   STATUS :=MW 22

// ---- Send data when connected ----
A   M 20.0           ; Only send when TCON DONE
A   M 100.5          ; 100 ms clock bit from OB35 or CPU clock
=   L 0.0
CALL FB63, DB63
   REQ    :=L0.0
   ID     :=1
   LEN    :=4
   DATA   :=P#DB1.DBX0.0 BYTE 4
   DONE   :=M 21.0
   BUSY   :=M 21.1
   ERROR  :=M 21.2
   STATUS :=MW 24

Complete Passive-Side OB1 Snippet (STL)

// ---- Listen for incoming connection ----
CALL FB65, DB65
   REQ    :=M 10.0
   ID     :=1
   CONNECT:=P#DB100.DBX0.0 BYTE 40
   DONE   :=M 20.0
   BUSY   :=M 20.1
   ERROR  :=M 20.2
   STATUS :=MW 22

// ---- Receive data continuously ----
CALL FB64, DB64
   EN_R   :=TRUE
   ID     :=1
   LEN    :=4
   DATA   :=P#DB1.DBX0.0 BYTE 4
   NDR    :=M 23.0
   BUSY   :=M 23.1
   ERROR  :=M 23.2
   STATUS :=MW 26
   RCVD_LEN:=MW 28

Connection Resource Limits on CPU 319-3 PN/DP

Connection IDs 1-16 may be used for OUC on the integrated PN interface. They must be unique across all FBs/FCs on a CPU.

Status and Error Codes

For a complete list, consult the STEP 7 online help on TCON/TSEND/TRCV/TDISCON and the manual entry for CPU 319-3 PN/DP at entry ID 12996906.

Verification Procedure

1. Download the hardware configuration and the program to both CPUs. The active side should be downloaded last so the active open does not time out against an unprepared partner.
2. In STEP 7, open Online -> Accessible Nodes and verify both CPUs respond on the assigned IP addresses.
3. On CPU A (active), trigger M10.0 once (e.g., from a VAT table). TCON DONE (M20.0) should set within 1-2 seconds; STATUS should be 0000.
4. On CPU B (passive), monitor TRCV.NDR (M23.0). Each pulse indicates a new telegram arrived; RCVD_LEN should equal 4 (two words = 4 bytes).
5. Write distinct values into DB1.W1 and DB1.W2 of CPU A (e.g., W#16#1234 and W#16#5678). Confirm the same values appear in DB1.W1 / DB1.W2 of CPU B within one cycle of the send period.
6. Reverse the test: write into CPU B's DB1 and trigger a separate TSEND on CPU B paired with a TRCV on CPU A if bidirectional exchange is required. The same ID range (1-16) can be reused with a different connection DB (e.g., DB101) and a different ID (e.g., 2).
7. Use Monitor/Modify with a VAT on the active side to confirm the FB65 STATUS = 0000 after the connection is established.

Diagnostics in the Online View

STEP 7's online diagnostic tools surface OUC state through the CPU's diagnostic buffer (accessible via CPU -> Module Information -> Diagnostic Buffer) and through the system status list (SZL) of the integrated PN interface. The following SZL indices are useful:

• SZL W#16#0132 - Communication status data (lists connection IDs, types, states).
• SZL W#16#0131 - Detailed communication parameters for the integrated PN interface.
• SZL W#16#00A0 - Port statistics (link state, discarded frames, errors on X3 P1/P2).

A web server is also available on the CPU 319-3 PN/DP (FW 3.2+) and can be used to confirm link state on X3 ports without a STEP 7 license on the PG.

Common Pitfalls and Field-Proven Caveats

1. TDISCON forgotten during restart. A warm restart or stop-to-run transition leaves the previous connection resource in a "wait" state. Without TDISCON in OB100, the next TCON call returns STATUS 80B3 ("connection already exists").
2. Local port conflict. When both sides pick the same local port (e.g., both 2500), the active open still succeeds but routing becomes confusing. Use distinct local ports for passive listeners and let the active side use LocalPort = 0.
3. Subnet mismatch. If the IP addresses are not on the same subnet and no router exists, ARP fails silently and STATUS shows 80A7 after the retry interval.
4. Wrong LocalDeviceID. For the integrated PROFINET interface set LocalDeviceID := B#16#01. Setting it to 2 (CP) on a CPU 319-3 PN/DP returns STATUS 80B4 because no CP is present in slot 2.
5. LEN vs. DATA length mismatch. TSEND's LEN is the exact number of bytes to transmit. For two WORDs use LEN = 4, not 2 and not 8.
6. Receive block not enabled before first send. If TRCV is not called at least once before TSEND fires, the partner's TCP stack rejects the data; the active side sees 80A7 on subsequent sends. Always call TCON + TRCV on the passive side before the first TSEND on the active side.
7. Connection ID collision with PUT/GET. PUT/GET configured in NetPro uses connection IDs in the same range. Reserve IDs 1-16 exclusively for OUC, or start at ID 200 for S7 communication and ID 1 for OUC, with documentation kept in the project.
8. High cycle time on active side. The CPU 319-3 PN/DP tolerates OUC sends at OB1 priority; however, very high send rates (sub-10 ms) saturate the PN interface and can block PROFINET IO. Use OB35 (cyclic interrupt) at 50-100 ms for periodic transmission.

Alternatives and Extensions

• S7 Communication (PUT/GET) - easier to configure via NetPro but limited to 160-byte payloads on PUT. Useful when both stations already participate in the same S7 connection.
• UDP (TUSEND/TURCV) - lower overhead, broadcast-capable, but no built-in acknowledgment. Replace UDT 65 with UDT 66 "TCON_PAR_UDP" and set ConnectionType = B#16#12.
• ISO-on-TCP (RFC 1006) - set ConnectionType = B#16#12 in UDT 65 and supply LocalTSelector / RemoteTSelector (TSAP) strings. Useful when both stations are Siemens and you want message boundaries preserved across large payloads.
• iDevice / PN IO proxy - if the CPU 319-3 PN/DP must also act as a PROFINET IO device on the same X3 port, configure the PN interface in HW Config accordingly. OUC shares the port bandwidth with PROFINET IO.

Frequently Asked Questions