Fixing S7-1500 UDP Broadcast Reception with TURCV and TCON

Problem Statement: TURCV Stuck in Status 16#7002 on UDP Broadcast

Engineers deploying S7-1500 CPUs (S7-1516-3 PN/DP and similar) frequently hit a wall when implementing a UDP broadcast subscriber: the TRCV / TURCV instruction never sets the NDR bit even though the TCON block reports a healthy connection. The instruction outputs STATUS = 16#7002 with BUSY = TRUE continuously, the receive DB stays empty, and the address DB never records a sender. TCON itself shows no error, so the socket appears bound. Wireshark on a peer PC and a C# application on the same subnet capture the broadcast frames without issue, confirming the packets are on the wire.

This article dissects the precise configuration gap between a working point-to-point UDP "send-and-receive" link and a broadcast receive link, the role of the TCON_Param structure (UDT 65) used by TCON, the meaning of the 16#7002 status code returned by TRCV/TURCV, and the PROFINET interface settings that determine whether the S7-1500 actually consumes a broadcast frame. The diagnostic procedure applies to firmware V2.0 onward on the S7-1500 CPUs and to TIA Portal V14 SP1 through V18.

Root Cause: Why UDP Broadcast Reception Fails by Default

Three concurrent faults typically produce this symptom. They are not mutually exclusive, and field experience shows that at least two are usually present simultaneously on a first deployment.

1. RemoteAddress filter mismatch. The default UDT 65 "TCON_Param" instance generated by TIA Portal is configured for point-to-point UDP. The RemoteAddress field is left at 0.0.0.0 with a non-zero remote TSAP/port, or set to the unicast address of a specific partner. For broadcast reception, RemoteAddress must equal the subnet-directed broadcast (e.g., 192.168.0.255 for a /24 subnet) or be set to 0.0.0.0 with RemoteTSAPLength = 0 so the socket accepts any sender. When the field is left at the partner's unicast address, the S7-1500 communication stack filters incoming datagrams by remote endpoint and silently discards anything that does not match.
2. LocalPort bind mismatch. For UDP on S7-1500, the local TSAP/port must be set explicitly to the port on which the broadcaster targets the PLC. If LocalPort is left at 0, the stack opens an ephemeral port, and broadcast packets aimed at the well-known target port are dropped at the IP layer.
3. Layer-2 broadcast suppression. The X1 PROFINET interface on the S7-1500 accepts broadcast by default, but a managed switch between the broadcaster and the PLC may have IGMP/MLD snooping, broadcast storm control, or port isolation enabled. Wireshark on a directly attached PC still sees the frame because it sits in the same broadcast domain, but the PLC port may be filtered.

When STATUS = 16#7002 is reported, the connection has been successfully established, the receive job is active, and the socket is waiting for the first datagram. Because the socket filter rejects every incoming packet, BUSY stays TRUE forever and NDR never transitions from FALSE to TRUE. This is the diagnostic signature of a UDP receive filter mismatch on an otherwise healthy socket.

Connection Model: How TCON Handles UDP on S7-1500

Contrary to common intuition, UDP "connection" handling on S7-1500 is implemented as a unidirectional or bidirectional socket bind. TCON does not establish a connection in the TCP sense; it creates a socket, binds it to a local endpoint, and optionally associates it with a remote endpoint for filtering purposes. TRCV/TURCV then reads from that socket. For broadcast reception, three combinations of TCON_Param are valid.

The S7-1500 firmware supports ConnectionType = 16#0B for UDP on most CPU variants. The value 16#11 is the explicit UDP code and is accepted on firmware V2.6 and later. The official SIMATIC S7-1500 / ET 200MP Communication Function Manual documents the UDT 65 layout for both connection types.

Prerequisites

TCON Connection Data Structure (UDT 65) Parameter Mapping

TCON receives a pointer to a connection description DB that contains a UDT 65 "TCON_Param" instance. The fields that determine broadcast behavior are listed below with their byte offsets inside the structure.

Local and remote TSAP IDs are encoded in big-endian byte order. To listen on UDP port 3000 (decimal), LocalTSAP[1] = 16#0B and LocalTSAP[2] = 16#B8 (0x0BB8 = 3000). For port 5000, use 16#13 and 16#88 (0x1388 = 5000).

TURCV / TRCV Block Parameter Reference

For continuous broadcast reception, hold EN_R permanently TRUE. The block keeps the receive job active and sets NDR for one cycle each time a datagram arrives. If the application toggles EN_R only on demand, broadcast packets that arrive between jobs are discarded by the socket.

PROFINET Interface Configuration

1. Open the device configuration of the S7-1516-3 in TIA Portal.
2. Select the X1 PROFINET interface.
3. In Properties → Ethernet addresses, assign an IP address inside the broadcast subnet (e.g., 192.168.0.10/24).
4. Verify the subnet mask is /24 (255.255.255.0). A /16 mask would push the subnet broadcast to 192.168.255.255, and a /24 broadcast is filtered.
5. Confirm "Use router" is unchecked unless the broadcaster routes through a router that forwards directed broadcasts (most do not by default).
6. Disable PROFINET functionality if not needed; PROFINET consumes some protocol handlers but does not affect UDP broadcast reception directly.
7. Under Properties → Advanced → Port options, verify that no MAC or broadcast ACL is configured that would drop unknown frames.

Step-by-Step Configuration Procedure

1. Add a global DB named "ConnectionDB" with a single variable of type "TCON_Param" (UDT 65). TIA Portal auto-generates UDT 65 the first time TCON is dragged into a code block.
2. Configure the ConnectionDB instance with the following values for broadcast RX on port 3000 / subnet 192.168.0.0/24:
   - ID = W#16#0001
   - ConnectionType = 16#0B (or 16#11 for FW V2.6+)
   - ActiveEstablished = FALSE
   - LocalAddress[1..4] = 0,0,0,0
   - LocalTSAPLength = 2
   - LocalTSAP[1] = 16#0B, LocalTSAP[2] = 16#B8 (port 3000)
   - RemoteAddress[1..4] = 192,168,0,255 (subnet broadcast)
   - RemoteTSAPLength = 0
   - RemoteTSAP[1..2] = 0,0
3. Create an instance DB for TRCV (e.g., "iDB_TRCV").
4. Call TCON in OB1 with REQ = TRUE (one-shot rising edge), ID = 1, CONNECT = "ConnectionDB". TCON completes with STATUS = 16#7000 (idle) once the socket is bound.
5. Create a receive DB "DB_RcvData" with Array[0..1499] of BYTE (covers the standard Ethernet MTU minus headers).
6. Create an address DB "DB_RcvAddr" using UDT "TADDR_Param" (UDT 66) to capture the sender's IP and port on each receive.
7. Call TRCV with EN_R = TRUE, ID = 1, LEN = 0 (any), DATA = "DB_RcvData", ADDR = "DB_RcvAddr".
8. Monitor NDR. On the first received datagram, NDR pulses TRUE for one cycle and the data appears in DB_RcvData with the sender's IP and port recorded in DB_RcvAddr.

Equivalent Structured Text (SCL) skeleton for the receive side:

// One-shot TCON in OB100 or first scan
IF "FirstScan" THEN
    "TCON_DB".REQ := TRUE;
END_IF;

"TCON_DB".ID := 1;
"TCON_DB".CONNECT := "ConnectionDB";

// Continuous TRCV in OB1
"TRCV_DB".EN_R := TRUE;
"TRCV_DB".ID := 1;
"TRCV_DB".LEN := 0;
"TRCV_DB".DATA := "DB_RcvData";
"TRCV_DB".ADDR := "DB_RcvAddr";

IF "TRCV_DB".NDR THEN
    // process "DB_RcvData"[0.."TRCV_DB".RCVD_LEN-1]
END_IF;

TRCV_C vs TRCV (TURCV) Differences

TRCV_C is the higher-level wrapper that internally calls TCON, TRCV, and TDISCON in sequence. It is convenient for short-lived connections. For long-lived broadcast subscriptions, the lower-level TRCV with explicit TCON is preferred for diagnostic clarity.

The two wrappers consume the same TCON_Param structure, so a working TRCV_C configuration can be migrated to direct TCON + TRCV by moving the connection parameters out of the TRCV_C instance DB into a global connection DB.

Status and Error Code Reference

Verification Procedure

1. On the PC running the broadcast sender, launch Wireshark on the interface that connects to the PLC's subnet.
2. Apply the filter udp.port == 3000 (substitute the actual port).
3. Trigger a broadcast send and verify the packet appears in Wireshark with destination address 192.168.0.255 (or the relevant subnet broadcast).
4. If Wireshark shows the packet but the PLC still reports 16#7002, mirror the PLC's X1 port to a monitor port and confirm the packet arrives at the PLC's physical port. If it does not, the switch is dropping the broadcast.
5. If the packet arrives at the PLC port but NDR never fires, open the project online, monitor all, and inspect the ConnectionDB. Confirm RemoteAddress, LocalTSAP, ConnectionType, and ActiveEstablished match the values in the table above.
6. Change RemoteAddress to 0,0,0,0 and RemoteTSAPLength to 0 to accept any sender. If NDR now fires, the previous filter was rejecting the packet.
7. Once NDR fires, restore the specific broadcast address and a non-zero RemoteTSAPLength for production hardening.
8. Validate the sender's address DB (TADDR_Param) is populated; it confirms the datagram passed the IP layer and was delivered to the socket.

Common Pitfalls Matrix

Alternative Approaches and Workarounds

If broadcast reception remains unreliable due to switch configuration, consider these patterns.

1. Unicast subscription. Modify the PC application to send unicast UDP packets to each subscribed PLC individually, using the PLC's IP as the destination. This bypasses broadcast storm controls and is the recommended approach on managed industrial networks.
2. Multicast (PIM/IGMP). Convert to IP multicast (e.g., 239.255.0.1) and configure IGMP snooping properly on the switches. The S7-1500 supports multicast via TCON with ConnectionType = 16#11 and the multicast group in RemoteAddress.
3. Use the CP 1543-1 communications processor. Offload UDP handling to a dedicated CP module, which can provide additional firewalling and broadcast filter controls via the security configuration.
4. TUSEND from a sender instance. If the broadcast originates from another S7-1500, use TUSEND with the broadcast address as the remote endpoint rather than relying on a Windows application.
5. PROFINET IO alarm model. For control-relevant broadcast, consider mapping UDP events onto PROFINET IO alarms instead, leveraging PROFINET's reliable channel.

Behavior Comparison: S7-1500 vs S7-1200 vs S7-300/400

Frequently Asked Questions