Configuring CopyStrIntoArray FB in TIA Portal for S7-1200 and S7-1500

This reference documents the correct deployment of the CopyStrIntoArray function block (FB) inside TIA Portal V15.1 through V18, targeting S7-1200 (firmware V4.2 and higher) and S7-1500 (firmware V1.8 and higher) controllers. The block copies the character payload of a STRING tag into a typed ARRAY buffer and is typically used when downstream code (peer-to-peer telegrams, ASCII protocol stacks, code-page conversion, label printing) needs character-by-character index access rather than the opaque STRING container the Siemens runtime normally provides.

The single most common deployment failure is a data-type mismatch on the FieldRead / FieldWrite instruction pair inside the block. The block body operates on CHAR elements, but users routinely wire Byte arrays. The PLC compiles fine, the call returns no error code, and the buffer fills with garbage. The procedures below eliminate that failure mode and cover the surrounding pitfalls (length handling, padding, non-printable characters, multi-byte code pages).

1. Function Block Interface and Semantics

The published CopyStrIntoArray FB exposes the following formal interface. Pin names vary by library version; the table below maps the standard convention used in the community FB circulating as CopyStrIntoArray in the Siemens global library exchange.

2. Prerequisites

1. Installed TIA Portal V15.1 or later. Earlier versions (V13, V14) lack the ARRAY[*] variable-length formal parameter introduced in V14 SP1.
2. CPU firmware compatible with the formal parameter type used:
   • S7-1200: firmware V4.2 or later (S7-1200 CPU firmware update V4.2 to V4.6 for full ARRAY[*] support).
   • S7-1500: firmware V1.8 or later (S7-1500 CPU firmware update V1.8 to V2.9).
3. Global library containing the CopyStrIntoArray FB. Obtain the .zip from your internal library server or Siemens Application Examples catalog. Verify the SHA-256 checksum before import.
4. An instance DB for the FB call. TIA Portal generates this automatically when the FB is dragged onto a network.
5. A STRING tag populated from an upstream process (HMI tag, receive buffer, recipe DB).
6. A target ARRAY declared in a global DB or as a static tag of the calling FB.

3. Library Import and Master Copy Setup

1. Open TIA Portal and load the project. In the Project tree, right-click the CPU and choose Open the global library.
2. Select Libraries → Open global library → Browse and navigate to the supplied .zip file.
3. Drag the CopyStrIntoArray folder from the library pane into the Program blocks node of the CPU. TIA Portal creates a Master Copy of the FB.
4. Compile the Program blocks folder. The Master Copy is now stored in the project. Updates to the source library require manual propagation.

4. Step-by-Step Configuration of the Call

4.1 Declare the Target ARRAY

Create a global DB (for example Data_Dest) and add a tag named CharBuffer:

The dimension 0..53 matches the original example discussed in the field (54 characters). If you use a different size, update the endIndex accordingly.

4.2 Declare the Source STRING

In the same DB (or in the calling FB's Input section) add:

Length is the maximum payload plus 1 (the trailing null is implicit). STRING[80] holds up to 80 characters.

4.3 Wire the Call

1. Open the OB or FB where the copy should occur (typically OB1 for testing, a cyclic interrupt OB for production).
2. From Program blocks → Master Copies, drag CopyStrIntoArray onto a network. TIA Portal creates an instance DB named CopyStrIntoArray_DB.
3. Connect the inputs and outputs:
   • enable → tag or boolean condition (for example, "Trigger".bCopy).
   • sourceString → "Data_Dest".SourceStr.
   • startIndex → 0 (constant INT).
   • endIndex → 53 (constant INT). For dynamic length, read LEN(SourceStr) - 1 from the standard function and pass it.
   • targetArray → "Data_Dest".CharBuffer.
4. Compile the block. TIA Portal performs type checking; any Byte/Char mismatch is now flagged with error 0706 "Type mismatch in the FB call".

4.4 Verify the FB Body

Open the Master Copy of the FB and inspect Network 3. The original implementation contains two instructions:

1. %FieldRead block reading from the source STRING.
2. %FieldWrite block writing to the destination ARRAY OF CHAR.

Both must be configured with the formal InOut parameter, not a concrete data block tag. Right-click the FieldRead input labeled Input and select Interconnect to formal parameter → sourceString. Repeat for Output → targetArray.

The index inputs of the FieldRead/FieldWrite must use the same DINT tag that the block exposes internally (commonly named iIndex). Confirm by hovering the connector; the tooltip should show "#iIndex", not a global tag name.

5. Common Error Conditions

6. Why BYTE Fails and CHAR Works

Siemens' STRING data type stores each character in 8 bits. The numeric representation matches BYTE (0…255), and the two are layout-compatible. The visible difference emerges at the symbolic layer:

• CHAR is interpreted as an ASCII / ISO-8859-1 / UTF-8 code point. The TIA Portal watch table displays it as 'A'.
• BYTE is interpreted as a numeric value. The same bit pattern appears as 16#41 or 65.

When the FB body uses FieldRead with a CHAR formal parameter, the compiler inserts a width check (DWORD → CHAR = 1 byte) and emits optimized copy code. When the parameter is BYTE, the same instruction runs, but the symbolic watcher prints the cell as a number. Engineers who read the array in the watch table then see numbers instead of characters and assume the copy failed. In reality, the data is correct; the presentation layer is wrong.

If the downstream consumer requires a BYTE array (for example, a raw TCP send buffer that must be transmitted as bytes), use one of three approaches:

1. Declare the InOut parameter as VARIANT and perform an explicit MOVE_BLK on the underlying BYTE view.
2. Use ATC (Any Type Conversion) functions to copy CHAR to BYTE after the FB returns.
3. Convert the destination to CHAR and re-interpret each cell as a byte when assembling the telegram. This is the recommended route for ASCII protocols.

7. Verification Procedure

After deployment, run the following checks before handing the system to commissioning:

1. Online watch: Open the instance DB and the destination DB in a watch table. Force enable = TRUE. The done bit should pulse for one cycle and status should read 16#0000.
2. Element comparison: In the watch table, expand the CharBuffer array. Each cell should display the corresponding character of SourceStr. If the array shows numeric values, the array was declared as BYTE. Fix the declaration and recompile.
3. Length check: Confirm that the trailing cells (positions 54+) of the array are untouched. The FB does not clear the buffer; it only overwrites positions startIndex to endIndex. Pad the buffer with $00 or $20 before each call if your consumer is sensitive to residual content.
4. Edge case — empty string: Set SourceStr = '' and trigger the FB. status should return 16#0000 and no array element should be modified. If status = 16#8202, the block's start index handling rejects the empty string. Wrap the call with a guard: IF LEN(SourceStr) > 0 THEN ....
5. Edge case — extended characters: Characters above 0x7F (e.g., ü, Ö, ß in ISO-8859-1) are copied as single bytes. If the consumer expects UTF-8, encode before the call. If it expects UTF-16, do not use this FB; use Character_Set_Convert from the Siemens standard library.

8. Alternative Implementations

For projects where importing a third-party FB is undesirable, the same operation can be written in five networks of ladder or three statements of SCL:

8.1 SCL Implementation

// Copy STRING payload to ARRAY OF CHAR
// Source: SourceStr : STRING[80]
// Target: CharBuffer : ARRAY[0..79] OF CHAR

FOR #i := 0 TO MIN(LEN("Data_Dest".SourceStr) - 1, 79) DO
    "Data_Dest".CharBuffer[#i] := "Data_Dest".SourceStr[#i+1];
END_FOR;

// Pad remainder with space (0x20) or null (0x00)
FOR #i := MIN(LEN("Data_Dest".SourceStr), 80) TO 79 DO
    "Data_Dest".CharBuffer[#i] := ' ';
END_FOR;

8.2 Ladder / FBD Implementation

For users restricted to graphical languages, instantiate the Siemens standard block MOVE_BLK_VARIANT (S7-1500) or BLKMOV (S7-1200) and configure the source as P#DB.SourceStr BYTE 80 and the destination as P#DB.CharBuffer BYTE 80. This treats both regions as raw byte arrays and bypasses the symbolic CHAR/BYTE distinction. The price is loss of symbolic debugging; values appear as bytes in the watch table.

9. Performance and Cycle-Time Considerations

The block uses a software loop. On an S7-1516 (firmware V2.8), a 54-character copy completes in roughly 8–12 µs of OB1 time. The block is suitable for cyclic execution at 10 ms without cycle-time impact. For high-frequency burst use (1 ms OBs, 200+ bytes per call), profile with the TIA Portal Task analysis tool and consider replacing the loop with MoveBlock for a 5–10× speedup.

10. Diagnostic and Commissioning Checklist

11. Frequently Asked Questions