S7-1200 TSEND_C: Sending Real, Int, and String Data Over TCP/IP to a PC Application

Engineers integrating a SIMATIC S7-1200 PLC with a PC-based data acquisition or test application (e.g. NI LabWindows/CVI, LabVIEW, Python, .NET) frequently hit the same wall: the example program in TIA Portal uses a 10-element Array of Char, the data round-trips perfectly through HyperTerminal, and the moment the developer switches the data type to Real, Int, or String, the receiver reports "junk". This is not a bug in TSEND_C — it is a misunderstanding of what the instruction actually moves on the wire. TSEND_C is a transparent byte-pipe: it copies the contiguous byte image of the DATA tag to the TCP socket and tells the receiver the length. The CPU performs no conversion. If the PC application expects ASCII characters but the PLC is shipping the IEEE-754 bit pattern of a floating-point value, the terminal will display garbage. The fix is to convert on the PLC side, convert on the PC side, or move to a higher-level protocol.

This reference walks through the engineering discipline required to make S7-1200 ↔ PC communication deterministic, including firmware prerequisites, TSEND_C/TRCV_C parameter layouts, byte-order conventions, conversion instruction selection, and a working STL/SCL pattern that ships Real, Int, and String values to a LabWindows/CVI TCP client without data loss.

1. What TSEND_C Actually Does

Per the SIMATIC S7-1200 manual, TSEND_C ("Send and receive data using Ethernet") establishes a TCP or ISO-on-TCP connection, transmits a data block, and (optionally) terminates the connection in a single call. Its companion TRCV_C accepts bytes from the partner and writes them into a configured data tag. Both instructions sit on top of the TCON connection description block (specified through the IDB/connection parameters), and both copy raw bytes — not typed values — into the transmit buffer.

The instruction signature is:

The crucial point: DATA is a VARIANT pointer. The instruction does not inspect the element type; it reads LEN bytes starting at the address of DATA. Therefore a Real tag occupies 4 bytes of IEEE-754 little-endian, an Int occupies 2 bytes, a DInt 4 bytes, and a String[20] occupies 22 bytes (2-byte length header + 20-byte payload). The PC must reconstruct the value from those exact bytes.

2. Firmware and Software Prerequisites

3. The Data-Type Problem: Why the PC Sees "Junk"

The S7-1200 stores values in little-endian byte order, with the following on-wire footprints:

When the PC application uses HyperTerminal or a generic printf/recv call, the C runtime interprets each received byte as an ASCII code point. 0x00 0x00 0x9A 0x45 (the IEEE-754 image of 1234.5) becomes four NUL, NUL, non-printable, 'E' characters — exactly the "junk" reported in the source thread. Three options resolve the issue:

1. Convert on the PLC to ASCII before sending. Use S_CONV / REAL_TO_STRING / INT_TO_STRING instructions to produce a String tag, then transmit the string. The PC receives printable characters and parses with atof() or strtod().
2. Transmit raw bytes and decode on the PC. Send a REAL tag directly with LEN=4; the PC reads 4 bytes and reinterprets them as a little-endian IEEE-754 float using memcpy.
3. Switch to a higher-level protocol. Use Siemens Open User Communication framing, OPC UA, Modbus TCP, or the S7 communication protocol — each carries typed data without manual byte manipulation.

4. Recommended Approach: ASCII Framing for Maximum Compatibility

For a PC application written in C (LabWindows/CVI, Visual Studio) or Python, the lowest-friction solution is to convert every numeric value to a fixed-width ASCII string on the PLC, optionally append delimiters, and let the PC parse the line with standard strtok / sscanf. This mirrors how industrial serial protocols (Modbus RTU ASCII, NMEA 0183) have worked for 40 years and avoids endian, padding, and alignment concerns.

4.1 PLC Data Block Definition

DATA_BLOCK "DB_Comms"
  STRUCT
    bTriggerSend   : Bool;        // Pulse to start a send cycle
    rTemperature   : Real;        // 22.5  °C
    rPressure      : Real;        // 1013.2 mbar
    iCount         : Int;         // 1234 pulses
    sSerial        : String[20];  // "SN-A12345"
    sPayload       : String[64];  // Assembled ASCII line
    sReceiveBuf    : String[128]; // TRCV_C target
    iRxLen         : UInt;        // Bytes actually received
  END_STRUCT;
END_DATA_BLOCK

4.2 SCL Build Code for the ASCII Payload

// "DB_Comms".sPayload := 'T=' + REAL_TO_STRING("DB_Comms".rTemperature)
//                      + 'P=' + REAL_TO_STRING("DB_Comms".rPressure)
//                      + 'N=' + INT_TO_STRING("DB_Comms".iCount)
//                      + 'S=' + "DB_Comms".sSerial
//                      + '$R$L';

Note that REAL_TO_STRING returns a string of length up to 14 characters (sign, 10 digits, decimal point, exponent). For a deterministic byte count, convert the real to a fixed-format string using String format instructions (TIA V16+) or, if unavailable, use S_CONV with explicit scaling:

iTempInt := REAL_TO_INT("DB_Comms".rTemperature * 10.0);
"DB_Comms".sPayload := 'T=' + INT_TO_STRING(iTempInt) + '/10;';

4.3 Sending the ASCII String

5. Alternative Approach: Raw Binary Transfer

If you need maximum throughput (e.g. 1 kHz waveform streaming) and the PC application can handle a binary protocol, the most efficient path is to concatenate a fixed-format frame and transmit it with a known length. Define a structure with no padding (use STRUCT with packed layout) and send it raw.

TYPE "UDT_Telemetry"
  STRUCT
    rTemperature : Real;   // 4 bytes
    rPressure    : Real;   // 4 bytes
    iCount       : DInt;   // 4 bytes
    byStatus     : Byte;   // 1 byte
    sId          : String[8]; // 10 bytes (length + 8 chars)
  END_STRUCT;
END_TYPE

Transmit with LEN := SIZEOF("UDT_Telemetry"). On the PC side (C example):

struct Telemetry {
    float  temperature;   // 4 bytes, little-endian
    float  pressure;      // 4 bytes, little-endian
    int32_t count;        // 4 bytes, little-endian
    uint8_t status;       // 1 byte
    uint16_t id_len;      // 2 bytes
    char    id[8];        // 8 bytes
};
// Total = 23 bytes per frame
// recv(sock, &frame, sizeof(frame), MSG_WAITALL);

6. Receiving on the PC: LabWindows/CVI Pattern

LabWindows/CVI provides the TCP/IP Library. A minimal client loop that parses ASCII frames from the S7-1200:

int CVICALLBACK TCPClientCallback(unsigned handle, int event,
                                  int error, void *callbackData) {
    char rxBuf[256];
    int  nRead = 0;
    switch (event) {
        case TCP_DATAREADY:
            nRead = ClientTCPRead(handle, rxBuf, sizeof(rxBuf)-1, 1000);
            rxBuf[nRead] = '\0';
            // Parse payload e.g. "T=22.5;P=1013.2;N=1234;S=SN-A12345\r\n"
            float T, P; int N; char S[32];
            sscanf(rxBuf, "T=%f;P=%f;N=%d;S=%31s", &T, &P, &N, S);
            // Update GUI / log
            break;
        case TCP_DISCONNECT:
            // Reconnect with ConnectToTCPServer
            break;
    }
    return 0;
}

For binary telemetry, replace the sscanf line with a memcpy into a C struct and read sizeof(struct Telemetry) per frame using the MSG_WAITALL flag.

7. TCON Connection Configuration (TIA Portal Step-by-Step)

1. Open the device view of the S7-1200 CPU and double-click the PROFINET interface.
2. Set the IP address and subnet mask (e.g. 192.168.0.10 / 255.255.255.0). Match the PC subnet.
3. Add a new Open User Communication connection block (right-click the CPU → Properties → Open User Communication). Configure:
   • Connection type: TCP
   • Partner IP address: 192.168.0.20 (PC running LabWindows)
   • Partner port: e.g. 2000
   • Local port: any (e.g. 0 = dynamic)
   • Active connection establishment: enable on the PLC side (TSEND_C is an active client)
4. Compile and download the hardware configuration.
5. Create a global DB holding the connection ID (Word) and a TCON_PARAM instance, or use the system-supplied instance DB created when you drop TSEND_C into a network.

8. Status and Error Codes

TSEND_C/TRCV_C return a 16-bit STATUS word. The high byte (bits 15…8) maps to the protocol class, the low byte to the actual error. The most common values encountered when sending wrong data types:

9. Verification Procedure

1. Online watch table: Place "DB_Comms".sPayload, TSEND_C.DONE, and TSEND_C.STATUS in a watch table with trigger on bTriggerSend.
2. Wireshark capture: Run Wireshark on the PC with filter tcp.port == 2000. Confirm the byte count equals the populated String length.
3. HyperTerminal round-trip: A 22-character string with LEN=0 must produce exactly 22 bytes in the capture.
4. Raw-Real verification: Send a Real tag with value 1234.5 and LEN=4. The 4-byte payload must be 00 00 9A 45 on the wire.
5. Connection state: Monitor TCON.DONE and TCON.STATUS after a CPU RUN↔STOP cycle to confirm auto-reconnect logic.

10. Troubleshooting Matrix

11. When to Use a Higher-Level Protocol

If the PC application needs typed data without parsing, the engineering effort of conversion on both sides — the original complaint in the field report — becomes unjustified. For greenfield projects, prefer:

• OPC UA: The S7-1200 firmware V4.4+ supports OPC UA server. The PC consumes typed variables directly via any OPC UA client SDK (Siemens, .NET, Python opcua, LabVIEW DataFinder).
• Modbus TCP: Use the MB_CLIENT instruction (S7-1200 firmware V4.0+). Register mapping handles integer and float values natively; dozens of PC libraries exist.
• S7 Communication: The PC uses libnodave, Snap7, or the official Siemens S7 protocol to read DBs directly without a custom byte protocol.

For the specific use case of "send a few strings of size 20 and a few real values" described in the source, the ASCII-framing approach in Section 4 yields the shortest development time and the fewest moving parts. For 100+ tags or sub-100 ms update rates, move to OPC UA or S7 communication.

12. Frequently Asked Questions