S7-1200 T_SEND UDP: Configuring TUSEND and TADDR_Param

The SIMATIC S7-1200 CPU integrates a PROFINET port that supports both PROFINET IO and open Ethernet communication. Beyond the PROFINET side, the S7-1200 firmware exposes a set of standard instructions for open user communication: TSEND, TRCV, TCON, TDISCON, TUSEND, TURCV, and the compact variants T_SEND_C / T_RECV_C. The compact variants combine connection establishment, send/receive, and termination in single FBs; the discrete variants give the application full control over each step. This guide focuses on the recurring problem of configuring the UDP-aware TUSEND block: missing TADDR_Param UDT, optimized data-block errors, an undefined LEN pin, and the underlying TCON wiring that the LCom blocks depend on.

1. Overview of S7-1200 Open User Communication

The S7-1200 PROFINET interface is a 10/100 Mbit/s port with auto-negotiation and auto-crossover. The firmware classifies every Ethernet service as one of:

• PROFINET IO (real-time, used for distributed I/O)
• S7 communication (PUT/GET for S7-S7 data exchange)
• Open user communication (TCP, ISO-on-TCP, UDP) — the layer that TUSEND lives in
• HMI / OPC UA / Web server (built-in services on firmware V4.0+)

For raw UDP datagram exchange, the S7-1200 firmware (V4.0 and later for the full UDP instruction set) supports up to 8 open user communications through the integrated PROFINET port. Each connection is identified by an ID in the range 1..0x0FFF (W#16#0001..W#16#0FFF) and is configured by a connection description UDT such as TCON_IP_V4 (V14+), TCON_ConfiguredConnection (legacy), or — for UDP specifically — the structured TADDR_Param used inside the application to describe the remote endpoint.

The S7-1200 open user communication model uses the classical ISO-on-TCP style of "connection" even for UDP. The firmware internally tracks a (local IP, local port, remote IP, remote port, connection ID) tuple and considers that tuple a "connection," although no TCP three-way handshake occurs. This is why a TCON call is still mandatory even when the application is sending raw datagrams.

2. T_SEND / TUSEND Block Identification and Selection

The discrete TSEND/TRCV instructions use a low-level TCON/TDISCON model and a P#-style ANY pointer. The LCom TUSEND/TURCV blocks were authored for the S7-300/400 environment and use a structured TADDR_Param for the remote endpoint plus a separate TCON call to bind the local port. The compact T_SEND_C/T_RECV_C blocks were designed for the S7-1200 from the start and accept symbolic, optimized buffers via SD_1 / SD_2 / RD_1 Variant inputs.

Selection rule: pick T_SEND_C / T_RECV_C for new projects on firmware V4.4+. Pick TUSEND / TURCV only when maintaining a legacy S7-300/S7-400 LCom library port and the customer is constrained to the LCom block interface. Pick the discrete TSEND/TRCV/TCON when full control of the connection lifecycle is required (e.g., to share a port binding across multiple send calls).

3. Connection Limits and Supported Protocols

Per the official S7-1200 communication support entry, the CPU supports 8 connections for open user communications, active or passive, using T_SEND_C, T_RECV_C, TSEND, TRCV, TUSEND, and TURCV. This 8-connection budget is shared with:

• PROFINET IO controller/device connections (typically 1..3 per CPU)
• S7 communication (PUT/GET) — server connections defined in CPU properties
• HMI connections (variable, configured per HMI panel)
• TCP / UDP / ISO-on-TCP open user connections

Each resource consumes a portion of the same internal connection table. Exceeding the 8-connection limit returns STATUS = 0x8086 (no resources, no connection available) at TCON. The protocols supported by the integrated PROFINET port for open user communication are TCP, UDP, ISO-on-TCP, and ISO (for the compact blocks and S7 communication). Note that the protocol count is also tied to the CPU firmware version: UDP as a transport for TUSEND requires firmware V4.0 or later on the S7-1200 side; on older firmware the ConnectionType = B#16#13 (UDP) is rejected by TCON with STATUS 0x80A0.

Reference: With which devices can the S7-1200 communicate via the integrated PROFINET interface and which protocols does the S7-1200 support?

4. Configuring TADDR_Param Data Type

TADDR_Param is a UDT (User-Defined Type) shipped with the LCom library and with the "SIMATIC S7-1200 Open User Communication" instruction set in TIA Portal V13 SP1 and later. The UDT structure is:

The IP address is encoded in network byte order (big-endian). For the address 192.168.0.50 the array must be set as {192, 168, 0, 50}. The two port fields are little-endian UINTs: a remote port of 2000 (decimal) is stored as 0x07D0 in low-byte / high-byte order, i.e., 0xD0 in the first byte and 0x07 in the second byte. A common commissioning bug is to set the port to 2000 but write it as WORD#16#2000 (8192 decimal) — confirm the byte order in the watch table.

If TADDR_Param is not visible when you open a global DB declaration, the LCom library is missing from the project. Add it through Project > Global libraries > Open library and load "LCom" from the default installation path, or create the UDT manually with the structure above. The UDT is then instantiated in a global DB and passed to the TUSEND / TURCV blocks as the ADDR parameter. The UDT DB must be a non-optimized DB (see Section 5) for the LCom blocks to interpret the offsets correctly.

For TIA Portal V11 SP2 — the version referenced in the original support case — TADDR_Param and the LCom library blocks TUSEND/TURCV are not part of the default installation. V11 SP2 only ships the discrete TSEND/TRCV/TCON instructions and the compact TSEND_C/TRCV_C. To use UDP on V11 SP2 you must either:

1. Upgrade the project to TIA Portal V13 SP1 or later, or
2. Manually install the LCom library and import TUSEND/TURCV, or
3. Use the TCON instruction directly with a TCON_ConfiguredConnection UDT (legacy) or TCON_IP_V4_PARAM UDT (V14+) and the discrete TSEND/TRCV instructions with ADDR = P# to a structured send area.

5. Optimized vs Non-Optimized Data Blocks

The standard TSEND/TRCV instructions and the LCom TUSEND/TURCV blocks were originally authored against the S7-300/400 memory model. On S7-1200, the default block attribute "Optimized block access" introduces symbolic-only addressing with non-deterministic byte offsets. TSEND/TRCV/TCON internally use absolute byte offsets resolved at compile time; symbolic-only optimized blocks break that resolution.

The fix:

1. Open the global DB that holds the TUSEND instance data, the TADDR_Param UDT instance, and the send/receive buffers.
2. Right-click the DB > Properties > Attributes > clear the "Optimized block access" checkbox.
3. Confirm "Accessible from HMI / OPC UA / Web API" is enabled if an HMI needs to read tags inside that DB (optimized blocks were the default, but HMI access still requires symbolic access in TIA Portal V15.1+).
4. Recompile the program. The DB now exposes the standard S7-300/400 address view; the blocks accept it.

For projects that must keep optimized blocks (because the rest of the program is symbolic), use the T_SEND_C / T_RECV_C compact instructions instead. The compact blocks were designed for the S7-1200 and accept symbolic, optimized buffers via the SD_1 and RD_1 (or RD_2) Variant inputs. The trade-off is loss of explicit TCON / TDISCON control over the connection lifecycle — the compact block does the TCON internally and reuses the connection across calls.

6. UDP Connection Configuration with TCON

Even when using the LCom TUSEND/TURCV, the underlying firmware still requires a TCON call to bind the local port and register the connection ID. A UDP "connection" in Siemens parlance is a logical binding of (local IP, local port, remote IP, remote port, ID) inside the firmware table, not a TCP three-way handshake.

Step-by-step TCON configuration for UDP on S7-1200:

1. Open the TCON instruction instance DB (e.g., iDB_TCON_UDP_1).
2. Set REQ = TRUE to trigger connection establishment.
3. Wire ID = W#16#0001 (or any unused value in the range 1..0x0FFF). Each TCON call must use a unique ID. Reusing an ID that is already in use by another TCON, a PROFINET connection, or an S7 server returns STATUS 0x80A1 or 0x80C3.
4. Set CONNECT to a TCON_ConfiguredConnection (legacy UDT 65) or TCON_IP_V4 (V14+ UDT 73/74) instance with:
   - InterfaceId = HW ID of the built-in PROFINET port (typically 64 decimal / 0x40 in TIA Portal V15.1+; check under Devices & networks > CPU > System constants for the actual HW ID)
   - ID = same as the ID pin above
   - ConnectionType = 19 (B#16#13 = UDP)
   - ActiveEstablished = TRUE for a client that initiates the first datagram, FALSE for server-side binding (waiting for an incoming datagram)
   - RemoteAddress = 192.168.0.50 (example — must be reachable on the same subnet as the PROFINET IP)
   - RemotePort = 2000 (example)
   - LocalPort = 2001 (example — or 0 for ephemeral assignment)
   
5. Monitor DONE and BUSY on TCON. STATUS = 0x0000 on success.
6. Once DONE = TRUE, call TUSEND with the same connection ID and the structured TADDR_Param as the ADDR input.
7. For bi-directional exchange, also call TURCV with EN_R = TRUE; TURCV fills its RD pin buffer with the next incoming datagram on the bound local port.

For TIA Portal V11 SP2, the TCON_ConfiguredConnection (UDT 65) and TCON_IP_V4_PARAM structures are reachable from the program editor's "Instructions > Communication > Open User Communication > Other" folder. Newer TIA Portal versions (V15.1 and later) replace the LCom-style UDTs with the TCON_IP_V4 UDT family and a more compact CONNECT input type.

7. LEN Parameter and Data Length Handling

The LEN pin behavior differs between the standard TSEND instruction and the LCom TUSEND block:

Set LEN to the number of bytes actually populated in the send buffer. Use SIZEOF on the symbolic tag if optimized access is enabled, or use a static constant when the buffer is a fixed-length ARRAY. Never tie LEN to a peripheral length (PEW/PAW) without a range check; doing so lets a process anomaly widen LEN beyond the buffer and force STATUS 0x8085.

For the discrete TSEND, the LEN input is a UINT and may take 1..8192. The TUSEND LCom block has the same UINT LEN range on firmware V4.2 and later. On firmware V4.0 and V4.1 the upper bound is 2048 for UDP; sending a larger buffer returns STATUS 0x8085. If the application needs UDP payloads above 2048 bytes, either upgrade the firmware to V4.2+ or fragment at the application layer.

8. TIA Portal Version Compatibility

The behavior of the open user communication instruction set has evolved across TIA Portal versions. The original support case mentions TIA Portal V11 SP2, which is well past its support window. The table below summarizes the relevant capability boundaries:

V11 SP2 is the version that produced the original issue. The cleanest path for a UDP project is to upgrade the project to TIA Portal V15.1 (or the current version) with firmware V4.4 or later on the S7-1200 CPU. The firmware upgrade is reversible only by Siemens service, so plan the upgrade during a maintenance window. Before upgrading, capture the program and PLC tag export — V11 SP2 projects must be migrated through the TIA Portal version-up wizard, which can fail on certain LCom block instances that have no successor in V14+.

9. Port and Protocol Reference

Per the S7-1200 communication protocols and ports reference, the following ports and protocols are active when UDP open user communication is in use:

Reference: Communication protocols and ports used by Ethernet communication

The CPU firewall (enabled by default in firmware V4.4+) blocks inbound UDP packets whose destination port is not in the LocalPort list of an established TCON. If the remote test tool cannot reach the CPU, verify that the CPU's firewall setting is "Restricted" or that the LocalPort used by TUSEND is explicitly allowed in the firewall rules under CPU properties > Communication > Firewall.

10. Troubleshooting Matrix

11. Verification and Commissioning Steps

1. Compile the S7-1200 program; resolve any "Unknown data type" or "Instance DB not generated" errors.
2. Download to the CPU. The CPU goes to RUN if no other fault blocks it. Check the CPU diagnostic buffer for SDO/communication errors before continuing.
3. Open the watch table that contains the TCON instance, the TUSEND instance, the TADDR_Param UDT, and the send buffer.
4. Force REQ on TCON to TRUE; wait one scan. DONE should be TRUE, STATUS = 0x0000.
5. Confirm TCON's CONNECT.ActiveEstablished matches your role (active = client initiating, passive = server waiting).
6. Use a separate UDP test tool (e.g., a packet capture with Wireshark filtered to the configured port, or a Python script with socket.socket(AF_INET, SOCK_DGRAM)) to send a datagram to the CPU's local port. The CPU is reachable as its PROFINET IP address (default 192.168.0.1 for the first CPU, or whatever was set in CPU properties > Ethernet addresses).
7. Force TUSEND REQ = TRUE; verify STATUS = 0x0000 (DONE = TRUE on the next scan).
8. Confirm the remote side received the datagram in Wireshark or the test tool. The datagram source port should match the LocPort from step 5, and the destination should match the RemPort from the TADDR_Param UDT.
9. Reverse the test: from the CPU, send to the test tool; confirm the tool received the datagram and the CPU's TUSEND returns DONE on the next call.
10. Stop forcing REQ and let the periodic OB1 call manage TUSEND with the rising edge of a dedicated trigger tag. Holding REQ = TRUE continuously will not cause multiple sends per scan — the FB itself is edge-triggered internally — but the cleaner pattern is to drive REQ from a one-shot (e.g., a P_TRIG instance or a set/reset flag).
11. Log the STATUS word and the connection ID into a cyclic data log (CSV on the SD card, or push to a WinCC Unified tag) for first-week commissioning visibility.

12. Frequently Asked Questions