Resolving TIA Portal V14 Pointer-to-STRING Type Mismatch in Migrated S7-1200/1500 Code

When a STEP 7 V5.6 project is migrated to TIA Portal V14 and compiled against an S7-1200 or S7-1500 CPU, classic block calls that pass a POINTER (P#DBx.DBXn.m) into a formal parameter declared as STRING will fail compile with the error:

"The data type POINTER of the actual parameter does not match the data type STRING of the formal parameter."

The error is raised by the TIA Portal compiler because the S7-1200/1500 POINTER data type can only reference elementary data types and cannot carry the 2-byte header that precedes a STRING value in the operand area. The implicit dereference that worked under STEP 7 V5.6 and the legacy S7-300/400 instruction set is not part of the S7-1200/1500 type system. The same source code that compiled for an S7-300 (e.g. 6ES7315-2EH14-0AB0, firmware V3.3) will be rejected after migration to a CPU 1515-2 PN (6ES7515-2AM02-0AB0, firmware V2.0+) or CPU 1214C DC/DC/DC (6ES7214-1AG40-0XB0, firmware V4.x).

This reference documents the root cause, the two engineering-grade remedies (symbolic tag addressing and the VARIANT pointer), and the verification workflow for engineers migrating classic STEP 7 sources into TIA Portal.

1. Problem Definition: Migrated FC31 REPLACE Call

The reported pattern is a user-defined FC31 carrying the REPLACE semantics imported from a STEP 7 V5.6 source:

CALL  FC    31
IN0   :=#STAT7
IN1   :=P#DB206.DBX 0.0
IN2   :=#TEMP20
IN3   :=#TEMP19
RET_VAL:=#STAT2

Under STEP 7 V5.6, IN1 was declared STRING, and the actual operand P#DB206.DBX 0.0 was accepted because the classic STL/ST editor performed an implicit pointer-to-string dereference at runtime. The compiler warning was suppressed or absent on S7-300/400 because the POINTER there was a 6-byte structure that could be loaded into AR1/AR2 and walked through any operand layout.

After the TIA Portal migration tool (Project → Migrate project) ports the S7-300/400 program to an S7-1200/1500 CPU, the compiler performs strict type-checking and raises:

2. Root Cause: S7-1200/1500 POINTER Semantics

The S7-1200/1500 family implements three address-pointer data types with different capabilities. The official definition is published in the TIA Portal S7-1200 manual collection — Variant pointer data type and the S7-1500 system manual.

Because the legacy POINTER cannot address a STRING, the compiler rejects the assignment in the migrated block. The runtime behavior that the original S7-300 code relied on — AR1 load, indirect addressing through the DB number, hand-walking the 2-byte STRING header — is no longer exposed to user code on S7-1200/1500.

3. Affected Versions, Firmware, and CPUs

The error is observed on any TIA Portal project that compiles an FC/FB whose interface declares a formal parameter as STRING, WSTRING, STRUCT, UDT, or ARRAY, and whose caller passes a P# pointer. The conditions that produce it:

The condition is not firmware-version dependent. It is a compiler-level decision in the TIA Portal offline editor. Firmware updates to the target CPU do not change the diagnostic.

4. Solution 1: Replace the POINTER with a Symbolic Tag Reference

The first, and recommended, remedy is to pass the STRING directly using its symbolic DB tag name. TIA Portal resolves the symbolic name to the DB number and the byte offset internally and dereferences the STRING correctly, including its 2-byte header (max-length and actual-length words).

If DB206 is named MyDB and its first tag is a STRING[80] named MyString, the migrated call becomes:

CALL  FC    31
IN0   :=#STAT7
IN1   :="MyDB".MyString
IN2   :=#TEMP20
IN3   :=#TEMP19
RET_VAL:=#STAT2

Notes on the rewrite:

1. The P# prefix is removed. TIA Portal accepts either a fully qualified symbolic tag ("MyDB".MyString) or, for a local variable in the same block, a simple symbolic name (#MyString).
2. The DB must be know-how protected compatible — i.e. its tags must be defined in the DB declaration, not generated by STL into the data area. Run Project → Compile → Software (rebuild all) before rewriting so the DB tags are visible to the FC editor.
3. Symbolic references survive future changes to MyDB layout. If another tag is later inserted at offset 0, the symbolic reference continues to point to the correct STRING. An absolute pointer would silently break.
4. Set the FC's access mode to Standard only if you also need to mix optimized DB access. For an S7-1500 with optimized block access (the default), the compiler resolves the symbolic tag through the compile-time symbol table without requiring a runtime DB number lookup.

5. Solution 2: Use the VARIANT Pointer

Where the source code intentionally uses indirect addressing — e.g. one FC must accept a string from any of several DBs depending on a mode input — declare the formal parameter as VARIANT instead of STRING. The TIA Portal S7-1200 manual — Variant pointer data type documents the rules:

• VARIANT occupies 0 bytes in the instance / work memory. It is a compile-time descriptor only.
• It can point to any tag including STRING, WSTRING, STRUCT, UDT, ARRAY, FB instance DBs, and partial slices (e.g. "MyDB".MyStruct.Field).
• Inside the called FC, use the VariantGet, VariantPut, and type-conversion instructions (STRING_TO_VARIANT / VARIANT_TO_STRING via the move/cast blocks) to read or write the referenced tag.

Example interface declaration for FC31 in SCL:

FUNCTION FC31 : String[80]
VAR_INPUT
  IN0  : DInt;
  IN1  : Variant;        // replaces the old STRING formal parameter
  IN2  : DInt;
  IN3  : DInt;
END_VAR
VAR_TEMP
  sTarget : String[80];
END_VAR
BEGIN
  // Validate the variant type at runtime before dereferencing
  IF TypeOf(IN1) <> Type_STRING THEN
    FC31 := '';
    RETURN;
  END_IF;

  // Move the STRING payload out of the variant
  VariantGet(SRC := IN1, DST := sTarget);

  // Perform the REPLACE semantics against sTarget using IN2/IN3
  // … user logic …
  FC31 := sTarget;
END_FUNCTION

And the call site, where the original P#DB206.DBX 0.0 is now any symbolic tag:

CALL  FC    31
IN0   :=#STAT7
IN1   :="MyDB".MyString        // symbolic tag, accepts any STRING
IN2   :=#TEMP20
IN3   :=#TEMP19
RET_VAL:=#STAT2

Rules and limits of the VARIANT approach:

• If IN1 is declared VARIANT, the compiler accepts any tag, but the block must dereference it explicitly with VariantGet/VariantPut — no implicit dereference is provided.
• Always test TypeOf() against TypeOf(...).Type = Type_STRING before dereferencing to avoid an STATUS error at runtime.
• The VARIANT cannot be used directly in arithmetic or string-function expressions; always extract to a typed temporary first.
• Supported on S7-1200 firmware V4.0+ and S7-1500 firmware V1.5+ (i.e. all CPUs TIA Portal V14 targets).

6. Solution 3: Let the TIA Portal Migration Tool Handle It

Siemens' migration toolchain (Project → Migrate project → S7-300/400 → S7-1500) is the prescribed workflow and frequently rewrites the affected P#DBx.DBXn.m operands into symbolic references automatically. Engineering notes from the migration documentation:

1. Open the classic project in SIMATIC Manager and run File → Save as → TIA Portal compatible (produces a .ap14 archive) or use Project → Migrate project directly from TIA Portal.
2. After migration, open the Migration log (Project tree → Common data → Logs). Search for entries containing POINTER or the block name FC31; the log lists every assignment the tool rewrote and every assignment it could not rewrite.
3. For each “Manual rework needed” entry, apply Solution 1 or Solution 2 above.
4. Run Compile → Software (rebuild all) to confirm the diagnostic is gone before downloading to the target CPU.

7. Comparison of the Three Remediation Strategies

8. Verification Steps After the Fix

Apply the four-step verification gate after either solution:

1. Compile gate: Project tree → CPU → right-click → Compile → Software (rebuild all). No diagnostics of type “data type ... does not match” must remain on FC31 or any caller.
2. Download gate: Online → Download to device. TIA Portal must show “Download successful” without converting the block to address-only access (a sign the symbolic info is lost).
3. Online monitor gate: Open FC31 online and expand IN1. The value column must show the STRING characters of the actual operand (e.g. 'Hello world'). For a VARIANT, confirm the “Type” column shows STRING and the “Pointer” column shows the expected DB number and byte offset.
4. Functional gate: Force STAT7 to a known input, force TEMP20 to the substring and TEMP19 to the position. Read STAT2 after one scan and confirm the expected replaced string. Repeat with ST2 = '', with a substring that does not occur, and with a position outside the source string length to confirm error handling.

9. Related Compiler Diagnostics and Their Root Causes

The same root cause produces a family of diagnostics. Use the matrix to triage:

10. Edge Cases and Field-Proven Caveats

Optimized block access. On S7-1500 with optimized block access (the project default), the symbolic tag is resolved at compile time and no DB number is loaded at runtime. This is the fastest and most maintainable choice.

Non-optimized block access. If the FB/FC has been toggled to non-optimized (compatibility with classic S7-300/400 code), the symbolic reference still works but the compiler emits a DB-OPEN around the access. Performance is slightly lower; tooling diagnostics remain identical.

STRING length truncation. When the actual operand is a STRING[80] and the formal parameter is declared STRING[254], the compiler truncates silently in some tool versions and warns in others. Set both ends to the same length or use WSTRING to avoid truncation.

WSTRING versus STRING. A P#DBx.DBXn.m operand cannot address a WSTRING either — same rule applies. The first two bytes of a WSTRING are also a length header, but each character is 2 bytes wide. Symbolic references work the same way.

Multi-instance and instance DBs. VARIANT can point to instance DBs of FBs (e.g. "Motor_1".Setpoint). A legacy POINTER cannot.

Know-how protection. If the migrated FC is know-how protected, the FC interface is invisible and symbolic rewriting inside it cannot be performed by you. Either obtain the unprotected source from the OEM or replace the FC with an unprotected equivalent. The compiled runtime behavior is identical.

S7-1500 software controller (CPU 1507S / CPU 1508S). The same rule applies. There is no POINTER-to-STRING implicit dereference on the software controller either.

S7-300/400 retain on the target. Some legacy P# operands rely on the S7-300/400 ability to walk into a multi-DB area. If the S7-1500 DB layout is consolidated (e.g. several classic DBs merged by the migration tool), symbolic references must be re-anchored against the new DB layout. The compiler does not catch this.

11. Best Practices for Future S7 → TIA Portal Migrations

1. Always run the TIA Portal migration tool against the whole project, never Generate blocks from source from STL fragments.
2. Read the Migration log end-to-end and resolve every entry marked “manual rework needed” before the first download.
3. Convert every P#DBx.DBXn.m operand in FC/FB input parameters to a symbolic reference during the same migration pass.
4. Prefer VARIANT formal parameters for FCs/FBs that are intentionally generic.
5. Enable optimized block access on every new S7-1200/1500 block to maximize compile-time symbol resolution.
6. Use the F1 help context for “POINTER data type” and “VARIANT data type” in TIA Portal for the current revision — Siemens revises the type rules between V14 and V18/V19 in subtle ways.
7. Run Project → Archive before and after the migration to compare offline if a regression appears.

12. FAQ