Resolving S7-1200 TSEND_C STRING Data in STRUCT Transfer Errors

When transferring batch numbers, lot codes, or any alphanumeric identifier between two SIMATIC S7-1200 CPUs over Industrial Ethernet, engineers frequently encounter a behavior where a STRING element declared inside a STRUCT cannot be used as a source operand on the DATA input of TSEND_C. The error appears even though a stand-alone STRING tag at the data block root transfers without complaint. This article walks through the underlying cause of that behavior, the precise byte-level layout of the S7-1200 STRING data type, three field-proven workarounds, the rules for running multiple TSEND_C / TRCV_C pairs in parallel, and the connection-resource limits you must respect on CPU firmware V4.x and V5.x.

1. Problem Description

The reported symptom in TIA Portal is one or more of the following compiler and runtime conditions:

• The STRING entry in the data block type-selection drop-down appears red when added under a STRUCT in the data block editor.
• Connecting a tag of type STRING declared inside a STRUCT to the DATA input pin of TSEND_C produces a compile error indicating that the data type is not permitted at this location.
• Attempting to use MOVE_BLK from "DB".string to "DB".array_of_char produces the compiler messages "only ARRAY elements can be used here" and "Access of elements of data type STRING is not allowed here".
• Selecting BLKMOV on a partial slice of a STRING is rejected by the compiler with the same access error.

Despite the failure inside the STRUCT, a top-level STRING tag in the same data block transmits and receives correctly when bound to TSEND_C.DATA and TRCV_C.DATA as a flat element. The inconsistency is the actual root cause: the TIA Portal compiler and the TSEND_C instruction treat struct member visibility differently from block-root tag visibility depending on firmware version.

2. Root Cause: How STRING Is Stored in the S7-1200

The S7-1200 STRING data type is not a flat sequence of ASCII bytes. It is a header-prefixed byte array with the layout shown in the table below. This layout is documented in the S7-1200 System Manual, Chapter 4 "Data types".

The full byte footprint of a STRING element is therefore 2 + max_length. A STRING[254] occupies 256 bytes, a STRING[10] occupies 12 bytes, and so on. When the tag is placed inside a STRUCT, the two-byte header is still present at the beginning of the struct member, and the DATA input of TSEND_C would, by default, transmit the entire 2 + max_length block — including the two header bytes that the receiver cannot interpret as ASCII.

This is exactly why TSEND_C with DATA = "DB".batch works when the batch tag is at the block root (the receiver buffers the whole 256 bytes and discards the header), but behaves inconsistently when batch is a member of a nested STRUCT: on some firmware versions the compiler refuses the binding outright, and on others the binding succeeds but the receiving CPU cannot decode the header bytes as part of the user data because the struct layout shifts the offsets of subsequent fields.

3. Why the Compiler Rejects Strings Inside Structs

When you create a data block in TIA Portal and add a STRUCT, then try to declare an element whose data type is STRING, the editor displays the type in red. The compiler does not actually forbid the declaration; it is signalling that the default maximum length of 254 cannot be inferred for a nested element. The remedy is to specify the maximum length explicitly, for example STRING[20]. The declaration must include the bracketed length:

TYPE "udtBatch"
  STRUCT
    BatchNumber : STRING[20];   // 22 bytes total: 2 header + 20 chars
    Quantity    : INT;          //  2 bytes
    Operator    : STRING[8];    // 10 bytes total
  END_STRUCT;
END_TYPE

If the brackets are omitted, TIA Portal flags the entry. Once the length is declared, the element is valid inside the struct, can be referenced as "DB".Batch.BatchNumber, and can be bound to TSEND_C.DATA as a single, flat tag.

4. Solution 1 — Declare STRING With Explicit Length Inside the Struct

This is the smallest possible change. It keeps the STRING element but forces TIA Portal to allocate the exact byte footprint, which the compiler and the TSEND_C instruction can both understand.

Step-by-step

1. Open the data block in TIA Portal.
2. Inside the STRUCT, create a new element.
3. Set Data type to STRING.
4. In the same row, after the data type, change the declaration from STRING to STRING[20] (replace 20 with your required maximum).
5. Compile the block. The red highlight on the type name disappears.
6. Bind the element to TSEND_C.DATA as "MyDB".MyStruct.BatchNumber.

Verification

Compile the project. The S7-1200 accepts the binding without error. Place the CPU in RUN, trigger a send, and confirm at the receiver that the entire 2 + length block arrives in the matching TRCV_C receive area. Read back the received string with the online watch table; the first two bytes are the header (max and actual length) and the ASCII payload starts at byte offset 2.

5. Solution 2 — Replace STRING With ARRAY OF CHAR Inside the Struct

Many engineers prefer a flat byte view of the payload because the receiving CPU can index the array without first reading the length prefix. The replacement is mechanical:

TYPE "udtBatch"
  STRUCT
    BatchNumber : ARRAY[1..20] OF CHAR;   // 20 bytes, no header
    Quantity    : INT;
    Operator    : ARRAY[1..8] OF CHAR;    //  8 bytes
  END_STRUCT;
END_TYPE

With this layout you lose the two-byte length header — the receiver cannot know how many characters are "valid" without a separate INT length tag. To compensate, add a length field:

TYPE "udtBatch"
  STRUCT
    BatchNumberLen : INT;                  // number of valid characters
    BatchNumber    : ARRAY[1..20] OF CHAR; // payload
    Quantity       : INT;
    OperatorLen    : INT;
    Operator       : ARRAY[1..8] OF CHAR;
  END_STRUCT;
END_TYPE

This variant transfers cleanly with TSEND_C because every element is a fixed-width primitive, and there is no STRING header to confuse the receiving PLC. It is the approach recommended in the STEP 7 Basic V19 Online Help entry for TSEND_C / TRCV_C when transmitting structures that contain alphanumeric data.

Copying a STRING into an ARRAY OF CHAR

To move a value from a STRING field into the ARRAY OF CHAR field at runtime, use the BLKMOV (block move) instruction with an ANY pointer that points at byte offset 2 of the source string. The snippet below shows the parameterization in Structured Text for a 20-character payload:

// Source: "DB_Src".stBatch.BatchNumber   (STRING[20], starts at DB_Src.DB[0])
// Target: "DB_Dst".stBatch.BatchNumber  (ARRAY[1..20] OF CHAR)
// Copy 20 bytes starting from the 3rd byte of the source STRING.

"DB_Dst".stBatch.BatchNumberLen := 20;
BLKMOV(
  SRCBLK := P#"DB_Src".stBatch.BatchNumber Byte 3,  // skip 2-byte header
  RET_VAL := "DB_Dst".stBatch.iBLKMOV_RetVal,
  DSTBLK  := "DB_Dst".stBatch.BatchNumber
);

The expression P#"DB_Src".stBatch.BatchNumber Byte 3 builds an ANY pointer of type BYTE with a 20-byte length, anchored at byte offset 3 of the source string. The first two bytes of the source — the maximum-length and actual-length fields — are skipped, and exactly the 20 ASCII characters are copied into the target array.

6. Solution 3 — Run Two TSEND_C / TRCV_C Pairs in Parallel

The original poster also asked whether two TSEND_C instances on the sender can target two TRCV_C instances on the receiver without cross-talk. The answer is yes, subject to three constraints:

1. Distinct connection IDs. Every TSEND_C and TRCV_C block must use a unique ID value in the range 0x0001 to 0x0FFF (the user connection range for the S7-1200 open user communication).
2. Distinct connection resources. The S7-1200 CPU firmware defines the maximum number of parallel open-user-communication connections. CPU firmware V4.x supports up to 8 active connections for TSEND_C / TRCV_C pairs. CPU firmware V5.x extends this to 16. See S7-1200 System Manual, Chapter on Communication.
3. Distinct connection parameters. Each pair needs its own CONNECT parameter block. For ISO-on-TCP connections this is a TCON_IP_v4 (or TCON_IP_RFC_v4) block with its own remote IP, remote TSAP, and local TSAP.

The configuration in the project tree typically looks like the following. Connection_1 and Connection_2 are two separate TCON configuration blocks, each referenced by its own TSEND_C and TRCV_C instance on each side.

// --- Sender (CPU A) ---
"instTSEND_C_1"(REQ := bTrigger1, DATA := "DB".Batch,
                CONNECT := "Connection_1", ID := 16#0001);
"instTSEND_C_2"(REQ := bTrigger2, DATA := "DB".Quantity,
                CONNECT := "Connection_2", ID := 16#0002);

// --- Receiver (CPU B) ---
"instTRCV_C_1"(EN_R := TRUE, DATA := "DB_R".Batch,
                CONNECT := "Connection_1", ID := 16#0001);
"instTRCV_C_2"(EN_R := TRUE, DATA := "DB_R".Quantity,
                CONNECT := "Connection_2", ID := 16#0002);

The block pairs are isolated at the TCP layer. The data sent on TSEND_C_1 / ID 16#0001 arrives only at TRCV_C_1 / ID 16#0001 on the partner. There is no broadcast or fan-out: a single TSEND_C cannot deliver to two TRCV_C blocks, and a single TRCV_C cannot receive from two TSEND_C blocks.

7. Maximum Data Block Size for TSEND_C / TRCV_C

The S7-1200 TSEND_C instruction accepts a DATA parameter of any length up to the limit of the CPU. Practical upper bounds are summarized in the table below. The values apply to firmware V4.2 and later, which is when TSEND_C replaced the older TSEND / TRCV pair.

For the original use case — a single batch number — a 256-byte STRING or a 32-byte ARRAY OF CHAR is far below any of these limits. The size-related "odd behavior" mentioned in the source content is therefore almost certainly caused by the STRING length declaration, not by a connection-level payload limit.

8. Status and Error Codes for TSEND_C / TRCV_C

The STATUS output of TSEND_C and TRCV_C returns a 16-bit word. The low byte carries the standard STATUS from TCON, TDISCON, TSEND, or TRCV depending on which sub-step is active. The high byte carries the function result. Selected codes that the field engineer will most often see:

These codes are documented in full in the STEP 7 online help under TSEND_C > STATUS output parameter and TRCV_C > STATUS output parameter, mirrored in Siemens Support entry 109748124.

9. Step-by-Step Commissioning Procedure

The following procedure assumes two S7-1200 CPUs on the same subnet, a single ISO-on-TCP connection, and the ARRAY OF CHAR solution for batch numbers. Adapt the IP addresses and TSAP values to the plant.

9.1 Prerequisites

• Both CPUs are configured in the same TIA Portal project, each with its own PROFINET interface and IP address (for example, CPU A: 192.168.0.10; CPU B: 192.168.0.11).
• The Ethernet subnet mask on both interfaces is identical (255.255.255.0 in this example).
• The PROFINET cable is connected between the two CPUs or via a switch.
• Both CPUs are online-reachable from the programming device.
• Firmware on both CPUs is V4.2 or later (V4.0 / V4.1 also work but predate some of the open-user-communication enhancements).

9.2 Create the connection block

1. In the project tree of CPU A, navigate to Devices & Networks > Network view.
2. Click the PROFINET interface of CPU A, then Properties > Ethernet addresses, and confirm the IP.
3. Repeat for CPU B.
4. From the right-hand Instructions palette, drag TSEND_C into OB1 of CPU A.
5. In the project tree of CPU A, double-click Connections; the connection wizard opens.
6. Select the partner as CPU B, choose ISO-on-TCP connection, set a unique local TSAP (for example 16#0001) and remote TSAP (also 16#0001).
7. Confirm. TIA Portal generates a Connection_1 data block.
8. Repeat for a second pair if you want to keep batch and quantity on separate connections; otherwise use one connection for both.

9.3 Create the data blocks

1. On CPU A, add a new global data block called DB_Send with Standard access mode (not Optimized — open user communication requires standard block access on firmware V4.x; firmware V5.x supports optimized blocks for TSEND_C / TRCV_C). See S7-1200 System Manual, "Communication".
2. Add the following elements:

   DATA_BLOCK "DB_Send"
     STRUCT
       BatchLen    : INT;
       Batch       : ARRAY[1..20] OF CHAR;
       Quantity    : INT;
     END_STRUCT;
   END_DATA_BLOCK

3. Create a matching DB_Rcv on CPU B with identical structure.

9.4 Wire up TSEND_C

// OB1, network 1 — send batch number on rising edge of bTrigger
"instTSEND_C"(
  REQ     := bTrigger,
  CONT    := TRUE,
  LEN     := 22,                // 2 (INT length) + 20 (CHAR payload)
  CONNECT := "Connection_1",
  ID      := 16#0001,
  DATA    := "DB_Send",         // whole DB; first 22 bytes are INT + ARRAY OF CHAR
  COM_RST := FALSE,
  DONE    => bDone,
  BUSY    => bBusy,
  ERROR   => bError,
  STATUS  => wStatus
);

9.5 Wire up TRCV_C on the partner

// OB1, network 1 — receive batch number
"instTRCV_C"(
  EN_R    := TRUE,
  CONT    := TRUE,
  LEN     := 22,
  CONNECT := "Connection_1",
  ID      := 16#0001,
  DATA    := "DB_Rcv",
  COM_RST := FALSE,
  DONE    => bDone,
  BUSY    => bBusy,
  ERROR   => bError,
  STATUS  => wStatus
);

9.6 Verification

1. Download both station configurations to the CPUs.
2. Set both CPUs to RUN.
3. Open an online watch table on CPU A and write 20 ASCII characters into DB_Send.Batch; write 22 into DB_Send.BatchLen.
4. Trigger bTrigger on CPU A. Observe that bBusy pulses, then bDone asserts and wStatus reads 16#0000.
5. On CPU B's online watch table, observe that DB_Rcv.Batch[1] through DB_Rcv.Batch[20] now contain the same characters and DB_Rcv.BatchLen reads 22.
6. Force a fault condition by setting LEN to 0. Observe STATUS = 16#8085 (LEN out of range), confirming that the diagnostic code path is wired correctly.

10. Troubleshooting Matrix

11. Best Practices

• Always declare the maximum string length with brackets. STRING without a length is invalid as a struct element and ambiguous as a block parameter.
• Prefer ARRAY OF CHAR for transmitted payloads. A flat byte layout avoids the two-byte header, simplifies length handling on the receiver, and removes the most common compile errors.
• Reserve a separate INT length tag. Without it, the receiver cannot determine how many bytes are valid ASCII.
• Use unique IDs and TSAPs. Two TSEND_C blocks on the same CPU must use different IDs and different local TSAPs; the same applies to the partner.
• Monitor STATUS at every cycle. Logging STATUS to a watch table or HMI tag is the fastest way to localize a connection or data-length fault.
• Avoid optimized blocks for TSEND_C on firmware V4.x. Open user communication historically requires standard (non-optimized) data block access on these firmware versions. Firmware V5.x removes this restriction; check the CPU's manual for the exact release notes.
• Document the byte layout. When sending a STRUCT, the partner's TRCV_C must reference a struct of identical layout and identical length; mismatches cause silent truncation.

12. FAQ