Siemens S7-400 Open UDP: Resolving TCON 7002H & 80B5H Errors

Problem Overview

Engineers configuring Open UDP communication between a Siemens SIMATIC S7-400 CPU and a third-party sensor — most commonly a Leuze barcode reader, distance sensor, or RFID reader — using the standard Open Communication blocks (FB65 TCON, FB66 TDISCON, FB67 TUSEND, FB68 TURCV) frequently encounter a stuck-state condition that suggests the UDP "connection" has never been established. The TCON instance DB shows DONE=0, BUSY=1, ERROR=0, STATUS=7002H on every cycle, and the active_est bit inside the UDT65 TCON_Param structure never transitions to TRUE even when the initial value is preset. A subsequent attempt to repeat TCON or to send data via TUSEND then returns STATUS=80B5H. This article documents the root cause, the correct parameterization of UDT65 for UDP, the meaning of every status code encountered, and the verification procedure required for S7-400 Open UDP against a Leuze or equivalent UDP endpoint.

For the reference network the addressing is fixed as:

• S7-400 CPU IP/port: 192.168.1.1:2801
• Leuze sensor IP/port: 192.168.1.209:3601
• CPU: 414-3 PN/DP (6ES7 414-3EM07-0AB0, firmware V6.0.7)

Hardware and Software Stack

The configuration described here applies to any SIMATIC S7-400 CPU with integrated PN interface or with an external CP443-1. The Open Communication blocks FB65 through FB68 are part of the standard STEP 7 V5.x library "SIMATIC_NET_CP" and have been delivered with every release since STEP 7 V5.0. There is no firmware-specific behavior change in the Open Communication blocks between CPU firmware V4.x and V6.x; differences appear only in the supported maximum number of simultaneous connections (currently 16 for the integrated PROFINET interface of CPU 414-3 PN/DP). Reference documentation is available in the Siemens Industry Online Support at support.industry.siemens.com.

The reference OpenUDP example provided by Siemens is published as entry 32038773 in the Siemens support database and includes a working STEP 7 V5.5 project, the UDT65 layout, and the FB65/FB67/FB68 call skeletons. The example is the canonical starting point for any S7-400 Open UDP application: Siemens Support Entry 32038773 — OpenUDP Example.

Root Cause Analysis

The 7002H status with BUSY=1 is not an error — it is the standard "job in progress" indicator returned by TCON while it is performing the configuration. For TCP connections the busy phase lasts until the three-way handshake completes; for UDP there is no handshake, but TCON still validates the UDT65 structure, opens the local socket, and binds the local port. This processing takes between one and three OB1 cycles on a CPU 414-3 PN/DP.

The reason the active_est bit never becomes TRUE is fundamental to how UDP is implemented on the S7-400. UDP is a connectionless protocol. The S7-400 Open Communication stack does not maintain a state machine for a UDP "connection" — there is no SYN, no ACK, no FIN. TCON only registers the local UDP socket descriptor in the CP firmware and writes the remote IP and remote port into the routing table so that TUSEND/TURCV know where to send and from where to expect datagrams. Because there is no handshake, the parameter active_est is intentionally ignored when connection_type = 19 (UDP). The bit is always FALSE on a properly configured UDP endpoint, regardless of whether the user has preset it to TRUE.

The 80B5H error code returned by the second TCON call confirms the first call did succeed. Per the Siemens Open Communication manual, STATUS=80B5H from TCON means "connection already established" — the connection ID is already bound in the CP firmware and cannot be reconfigured without first calling TDISCON. The user is therefore caught in a paradox: TCON appears to never complete (because BUSY stays 1 in the online monitor), yet the connection ID is already allocated. The discrepancy is explained by the online monitor behavior — TCON sets BUSY=1 for the single cycle in which it processes the request and clears it to 0 on the next cycle if the operation completed. If TCON is called more than once per cycle, or if the online monitor is refreshing on a slower cycle than the OB1 scan, the user observes BUSY=1 indefinitely.

UDT65 (TCON_Param) Parameter Reference for UDP

The UDT65 structure has a fixed length of 64 bytes and is the only configuration interface for TCON, TUSEND, and TURCV. The fields must be initialized with the desired values and the structure passed to TCON by reference in the CONNECT parameter. For UDP the following mapping applies:

Important detail: although UDT65 lists rem_staddr as 16 bytes, the CPU only reads the first rem_staddr_len bytes. Setting rem_staddr_len = 4 and writing the four IP address octets in network byte order (big-endian) is sufficient. The same applies to local_tsap_id and rem_tsap_id: only the first len bytes are consumed.

Step-by-Step Resolution

Follow this procedure to bring S7-400 Open UDP communication into operation. The procedure assumes STEP 7 V5.5 SP4 with the standard SIMATIC_NET_CP library. A working reference example is available as Siemens Support Entry 32038773.

1. Insert the four Open Communication blocks from the library into your S7-400 project (FB65 TCON, FB66 TDISCON, FB67 TUSEND, FB68 TURCV). Each block automatically creates an instance DB when first opened. Accept the default instance DB numbers or assign your own range (e.g. DB500..DB503).
2. Declare a data block of type UDT65 for the TCON_Param. Place it in a global DB (DB510 for example) and initialize every field according to the table above. The block must be 64 bytes long — verify the byte length in the DB declaration.
3. Write the IP address and port values into the UDT65. For the Leuze sensor on 192.168.1.209:3601 and local 192.168.1.1:2801 the values are:
   local_tsap_id[1] := B#16#0A; // high byte of 2801 = 0x0AF1 local_tsap_id[2] := B#16#F1; // low byte rem_staddr[1] := B#16#C0; // 192 rem_staddr[2] := B#16#A8; // 168 rem_staddr[3] := B#16#01; // 1 rem_staddr[4] := B#16#D1; // 209 rem_tsap_id[1] := B#16#0E; // high byte of 3601 = 0x0E11 rem_tsap_id[2] := B#16#11; // low byte
4. Set connection_type to B#16#13 (decimal 19) and active_est to FALSE. Do not preset active_est to TRUE — the CPU ignores it for UDP and it confuses diagnostics.
5. Configure the network interface in HW Config: assign the IP 192.168.1.1 to the CPU PROFINET interface X1, subnet mask 255.255.255.0, no router. Compile and download the hardware configuration.
6. Configure the Leuze sensor (or equivalent) for UDP unicast on port 3601, target IP 192.168.1.1, target port 2801. Confirm with the Leuze configuration tool (Sensor Studio / webConfig) that the sensor transmits datagrams on each trigger.
7. In OB1, call FB65 TCON with REQ=TRUE on the first scan and FALSE thereafter. Pass the UDT65 by reference (e.g. "DB510".TCON_UDP) as the CONNECT parameter. On CPU startup OB100 or the first OB1 cycle, set REQ=TRUE. The block then returns DONE=1, ERROR=0, STATUS=0000H after one or two OB1 cycles. Subsequent cycles with REQ=FALSE do not initiate a new connection — the connection ID remains bound.
8. Verify the connection by inspecting the instance DB. After successful TCON, the internal state area shows BUSY=0, DONE=1, STATUS=0000H, and the connection ID is locked. The active_est flag remains FALSE — this is correct behavior, not an error.
9. Call FB67 TUSEND with REQ=TRUE on a send trigger. Pass the same connection ID and the data buffer. The block returns DONE=1 after the datagram leaves the PROFINET interface (typically 5 to 20 ms later). Use FB68 TURCV to receive the Leuze response.
10. For shutdown or connection reconfiguration, call FB66 TDISCON with REQ=TRUE. After DONE=1 the connection ID is released and a new TCON call can re-bind it.

Status Code Reference

The status codes returned by FB65 to FB68 follow the SIMATIC Open Communication convention. DONE/BUSY/ERROR/STATUS combinations and their meaning:

Sample FB65/FB67/FB68 Implementation

The following SCL (Structured Control Language) snippets show a clean cyclic implementation of Open UDP communication. The example uses connection ID 1 for the Leuze sensor and assumes the UDT65 instance is named TCON_UDP in DB510.

// OB100 - first scan initialization
// Trigger TCON on cold restart; bind the UDT65 instance
FB65_TCON_DB(
    REQ     := TRUE,
    ID      := 1,
    CONNECT := "DB510".TCON_UDP);

// OB1 - cyclic operation
// Edge-trigger REQ on first OB1 scan only
IF "First_Scan" THEN
    FB65_TCON_DB.REQ := TRUE;
ELSE
    FB65_TCON_DB.REQ := FALSE;
END_IF;

// Capture DONE/ERROR for persistent diagnostics
IF FB65_TCON_DB.DONE = TRUE AND FB65_TCON_DB.ERROR = FALSE THEN
    "UDP_Connected"    := TRUE;
    "UDP_Last_Status" := FB65_TCON_DB.STATUS;
END_IF;
IF FB65_TCON_DB.ERROR = TRUE THEN
    "UDP_Last_Error"  := FB65_TCON_DB.STATUS;
END_IF;

// Send trigger - rising edge from application
IF "Send_Trigger" AND "UDP_Connected" THEN
    FB67_TUSEND_DB(
        REQ  := TRUE,
        ID   := 1,
        LEN  := "Send_Length",
        DATA := "Send_Buffer");
ELSE
    FB67_TUSEND_DB.REQ := FALSE;
END_IF;

// Continuous receive - call TURCV every cycle
FB68_TURCV_DB(
    EN_R := TRUE,
    ID   := 1,
    LEN  := "Recv_Length",
    DATA := "Recv_Buffer",
    NDR  => "Recv_New_Data",
    RCVD_LEN => "Recv_Actual_Len");

For ladder logic implementation in STEP 7 the equivalent calls are made via the FB blocks directly on the network. The instance DBs generated by STEP 7 expose all inputs as static variables, so the REQ edge-triggering can be performed by an auxiliary marker (M_TCON_Req) initialized in OB100 and cleared after the first successful TCON completion.

Network Configuration and Firewall Considerations

UDP open communication uses the standard Ethernet II frame on UDP/IP. No special routing is required between the S7-400 and the sensor provided they share the same IP subnet. The following checklist applies:

• Confirm the Leuze sensor and the S7-400 PROFINET interface are on the same subnet (192.168.1.0/24). A mismatched subnet mask or router entry is the most common cause of 80A0H errors.
• Disable any managed switch features (IGMP snooping, broadcast storm control, DHCP snooping) on the port connected to the CPU. These features do not block unicast UDP but may delay or drop datagrams under load.
• If a Windows engineering station is on the same network and runs the Windows Firewall, add inbound rules for UDP port 2801 if the engineering PC is to act as a UDP listener for diagnostic capture.
• Configure the Leuze sensor for unicast UDP (not broadcast). Broadcast UDP (connection_type = 20) requires an additional subnet ID configuration and is supported only on CP443-1 with firmware V3.x or later; the integrated PN interface of CPU 414-3 PN/DP supports broadcast but with restrictions on the number of receivers.
• Use a network tap or Wireshark on a mirrored port to confirm the datagram is leaving the sensor and arriving at the CPU. A missing datagram is indistinguishable from a CPU configuration error if only the instance DB is monitored.
• Check the maximum UDP payload size. The S7-400 Open Communication stack limits a single TUSEND call to 2048 bytes per datagram. Leuze sensor responses typically fit within 64 to 512 bytes; if a custom configuration produces larger frames, segment the payload across multiple TUSEND calls.

Verification Procedure

After the TCON call returns STATUS=0000H, perform the following verification in order:

1. Open the instance DB of FB65 TCON in STEP 7 online (Monitor/Modify). Confirm that the internal state block shows STATUS=0000H, ERROR=0, BUSY=0. The active_est bit will still be FALSE — this is correct.
2. Trigger a TUSEND call with a known 4-byte payload (e.g. 16#01020000). Monitor the TUSEND instance DB until DONE=1, ERROR=0, STATUS=0000H. If DONE=1 with STATUS=0000H but no datagram appears at the sensor, the issue is on the sensor side or the network.
3. Use Wireshark on a mirrored port to capture the datagram. The source IP must be 192.168.1.1, source port 2801, destination IP 192.168.1.209, destination port 3601. The UDP checksum should be non-zero.
4. On the Leuze sensor, check the transmission counter (most Leuze sensors expose a TCP/UDP frame counter). It must increment on every TUSEND call. If the counter is zero, the datagram did not reach the sensor.
5. Trigger a sensor response and verify with TURCV that NDR toggles to TRUE and RCVD_LEN reflects the actual payload length. Cross-check against the expected response from the Leuze protocol documentation.
6. Stress-test by sending 1000 TUSEND calls in rapid succession (OB35 cyclic interrupt at 100 ms is a good test rate). Monitor for any instance DB status that is not 0000H after the burst. Any non-zero STATUS indicates intermittent routing or buffer pressure issues.
7. Power-cycle the CPU and confirm that the connection auto-reestablishes on the next OB1 scan. The instance DB values from the previous session are lost; the UDT65 initialization values must be correct in the DB load image.

Common Pitfalls and Field Notes

Difference Between S7-400 and S7-1500 Open Communication

The TCON / TUSEND / TURCV family of blocks on S7-1500 has been renamed and extended. On S7-1500 with TIA Portal V14+ the blocks are TSEND_C, TRCV_C, TCON, TDISCON, TUSEND, and TURCV — and they are integrated in the instruction list, not in a separate library. The behavior of TCON for UDP is identical (active_est ignored, connection_type=19), but the UDT layout has changed and TCON_Param is now a PLC data type (UDT) with a different field order. Migration of an S7-400 Open UDP project to S7-1500 requires recreating the TCON_Param in TIA Portal; copying the S7-400 instance DB does not work because the byte offsets of the address fields differ.

For S7-300 the blocks are named differently (FC5 AG_SEND, FC6 AG_RECV) and the Open Communication blocks FB65 to FB68 are not available. The S7-300 path uses the AG_SEND / AG_RECV interface over an ISO transport connection or a UDP connection configured with the older "Open Communication Wizard" tool. If the same application must run on S7-300 and S7-400, the UDP endpoints must be re-implemented for the S7-300 with FC5/FC6 plus a configured UDP connection in NetPro.

For S7-1200 with firmware V4.0 or later, TUSEND and TURCV exist as TSEND_C and TRCV_C but only support TCP. UDP open communication on S7-1200 is not available through the standard instruction set — a third-party CP or a user-defined UDP implementation via the T-INDICATOR block family is required. This is a documented limitation of the S7-1200 PLC firmware; see the S7-1200 system manual on Siemens Industry Online Support for the protocol support matrix.

Frequently Asked Questions