Migrating SCL Code from STEP 7 V5.5 to TIA Portal V12 Complete

1. Overview: Why STEP 7 V5.5 SCL Migration to TIA Portal V12 Fails

Engineers who maintain long-lived SIMATIC S7-300/S7-400 installations frequently face a forced migration when a customer standardizes on TIA Portal V12 or higher, but the existing logic was authored in STEP 7 V5.5 with SCL (Structured Control Language). The classic SIMATIC Manager editor and the TIA Portal editor are not source-compatible at the block level: the same `.scl` source compiles to a different container, the data type registry is different, and the project container format is incompatible. A bulk project conversion commonly fails with cryptic compile errors referring to UDT instances, multi-instance DB arrays, or implicit type coercion that worked in V5.5 but is rejected by the V12 compiler.

The most common blocking error is "The project must be compiled before it can be migrated" even when the V5.5 project was just saved and compiled without errors. The root cause is that the V5.5 project file carries historical inconsistencies (residual symbols, hidden blocks, partial saves) that the migration toolchain flags. The only durable workaround is to strip the project down to a minimal "diet version" that contains only the blocks actually in use, regenerate the UDTs from a clean source, and then re-import the trimmed source into TIA Portal.

This guide consolidates the field-proven procedure used by commissioning engineers, references the official Siemens SCL expressions and operations documentation, and walks through every step from the V5.5 source files to a buildable V12 program.

2. Prerequisites

Before starting the migration, verify the following:

• STEP 7 V5.5 SP4 or later installed with SCL option package. Hotfix HF9 or later is recommended for clean source exports.
• SIMATIC TIA Portal V12 SP1 Update 4 (or higher) installed. The Update 4 release stabilized the V5.5-to-V12 migration toolchain; earlier V12 service packs have known UDT array conversion bugs.
• S7-SCL V12 option installed inside TIA Portal (separate license, ships in the TIA Portal Setup under "STEP 7 Professional" options).
• SCL source conversion wizard ("Wizard for converting SCL source files from V5.x to V1x") installed. The wizard is delivered on the TIA Portal installation media under Optional Components.
• Read/write access to the V5.5 project directory, including the Sources subfolder containing the `.scl` files.
• Customer-supplied FB and DB blocks that were hand-edited outside the SCL toolchain must be re-exported to clean SCL source files first; binary block imports do not survive the wizard.

3. Architectural Differences Between the V5.5 and V12 SCL Editors

The two editors differ in three structural areas that drive almost every migration error.

3.1 Project Container

STEP 7 V5.5 stores blocks in a .s7p project file referencing individual block containers (FB, DB, UDT, FC, OB, SDB, SFB, SFC) inside the S7Program directory. TIA Portal V12 stores the same blocks inside a single compressed .ap12 (or .ap13, depending on the build) project archive, indexed by a SQLite database. The migration toolchain unwraps the V5.5 container, re-registers the block headers, and re-indexes them inside the V12 container. Any orphaned or non-standard block header aborts the import.

3.2 Block Declaration Interface

In V5.5 SCL, the block declaration (VAR_INPUT, VAR_OUTPUT, VAR_IN_OUT, VAR, VAR_TEMP, CONST) and the code body are written sequentially in one source file. In TIA Portal V12, the declaration is split into a tabbed Interface pane and the code body in the SCL editor. The wizard handles the split automatically, but it will fail on declarations that V12 cannot represent, such as:

• Pointer parameters of type ANY with non-standard byte layout
• Multi-instance declarations that reference an FB whose interface itself uses POINTER or ANY parameters
• Symbolic I/O addressing using older E/A/M/L prefixes that have been remapped through a global symbol table

3.3 UDT Registration

A User-Defined Type (UDT) in V5.5 is a stand-alone block (UDT 1, UDT 2, ...) referenced by DBs and FB VAR sections as "udt_name" or UDTxx. In V12, UDTs are first-class types stored under PLC data types. The wizard translates numeric UDT references (UDT 1) to named references ("udt_Datatype"), but the symbol table must already contain a matching name; otherwise the imported DB is flagged with a type error.

4. Declaring an Array of UDT in STEP 7 V5.5 vs TIA Portal V12

One of the most common fields engineer questions is how to declare an array whose element type is a custom UDT. The syntax looks similar but the registration steps differ.

4.1 STEP 7 V5.5 SCL Syntax

TYPE
  udt_Datatype : STRUCT
    i_Value   : INT;
    r_Scale   : REAL;
    s_Tag     : STRING[20];
    b_Active  : BOOL;
  END_STRUCT;
END_TYPE

DATA_BLOCK db_LogBuffer
  STRUCT
    arr_Records : ARRAY[1..100] OF udt_Datatype;
  END_STRUCT;
BEGIN
END_DATA_BLOCK

4.2 TIA Portal V12 SCL Syntax

In V12 the TYPE / END_TYPE wrapper is removed; the UDT becomes a PLC data type registered in the project tree. The DB declaration uses the ARRAY keyword identically to V5.5:

// "udt_Datatype" must already exist under PLC data types
DATA_BLOCK "db_LogBuffer"
  STRUCT
    arr_Records : ARRAY[1..100] OF "udt_Datatype";
  END_STRUCT;
BEGIN
END_DATA_BLOCK

Note the quoted name: V12 requires type identifiers declared in the PLC data types folder to be referenced with double quotes inside SCL. The wizard performs this quoting automatically when the source file imports cleanly.

4.3 Indexed Access Patterns

Both editors allow indexed read/write using the [index] suffix. Compound assignment via := is also identical, following the SCL expressions and operations rules defined in the Siemens SCL reference manual:

// Write element 5
"db_LogBuffer".arr_Records[5].i_Value := 1234;
"db_LogBuffer".arr_Records[5].r_Scale := 1.5;

// Loop over the array (Tia Portal V12 supports FOR/WHILE/REPEAT)
FOR i := 1 TO 100 DO
  IF "db_LogBuffer".arr_Records[i].b_Active THEN
    // ... process record
  END_IF;
END_FOR;

5. The SCL Source Conversion Wizard

The SCL source file conversion wizard is the only Siemens-blessed path for converting `.scl` source files written in V5.5 syntax into V12-compatible source files. It does not convert the project — it converts sources only, which is why a clean source export is mandatory.

5.1 Launching the Wizard

1. In STEP 7 V5.5, open the customer project in SIMATIC Manager.
2. Right-click the S7 Program node and select Generate Source > SCL Source (not the generic STL source).
3. Save the generated source as CustomerFbs.scl in the Sources folder.
4. Close SIMATIC Manager.
5. Launch Start > Siemens Automation > SCL Conversion Wizard.
6. Browse to CustomerFbs.scl, set the target to TIA Portal V12, and click Convert.
7. The wizard emits a new file CustomerFbs_V12.scl next to the original.

5.2 Wizard Output Inspection

Open the converted file in a text editor and verify:

• All UDT n references have been replaced with the symbolic name in quotes.
• The TYPE / END_TYPE wrapper has been stripped from the UDTs (they are now file-level TYPE definitions expected by V12).
• All BEGIN END_DATA_BLOCK blocks survived the round-trip.

6. Step-by-Step Migration Procedure (Field-Proven)

The following procedure has been validated on multiple customer migrations from V5.5 to V12. It is the "diet version" approach: instead of migrating the full project, the engineer rebuilds a minimal project that contains only the blocks in use, then re-attaches the remaining logic once the core compiles cleanly.

6.1 Step 1 — Create a Clean V5.5 Working Project

In SIMATIC Manager, create a new project named Migration_Source. Copy from the customer project only the following block types:

• Hardware configuration (HW Config export, re-imported into the new project)
• All UDTs referenced by the FBs and DBs you will carry over
• The FBs and DBs themselves (FB 100–199, DB 100–199 are common for application code)
• The OBs that the customer specified (typically OB 1, OB 35, OB 82, OB 100, OB 121)

Do not carry SFBs, SFCs, SDBs, or the symbol table unless the customer explicitly states that they were modified.

6.2 Step 2 — Verify V5.5 Project Consistency

Run PLC > Compile and Check Consistency. Fix every error. Save the project. Close SIMATIC Manager.

6.3 Step 3 — Export SCL Sources

Use Generate Source > SCL Source to write a single `.scl` file containing every UDT, FB, FC, DB, and OB. Name it AllBlocks.scl.

6.4 Step 4 — Run the Conversion Wizard

Run the wizard on AllBlocks.scl and output AllBlocks_V12.scl. Inspect for the issues listed in section 5.2.

6.5 Step 5 — Create a New TIA Portal V12 Project

1. Open TIA Portal V12.
2. Create a new project Migration_Target with the same CPU type (e.g. CPU 315-2 PN/DP, order number 6ES7 315-2EH14-0AB0).
3. Configure the device view to match the customer hardware.

6.6 Step 6 — Import the Converted Sources

1. In the project tree, expand PLC_1 > Program blocks.
2. Right-click External source files and select Add new external file.
3. Browse to AllBlocks_V12.scl.
4. Right-click the imported file and select Generate blocks from source.
5. Watch the Compile output for warnings. The most common warnings are unused variables, signed/unsigned mismatches, and obsolete system function calls.

6.7 Step 7 — Address Compile Errors Iteratively

Expect to fix the following class of errors:

6.8 Step 8 — Build the Diet Version

If the full import still produces too many errors, repeat from step 1 with a thinner block set. Keep only the UDTs that are referenced by the FBs you are migrating, the FBs themselves, and the minimum DBs. Comment out the rest. The goal is a V12 project that compiles with zero errors and only warnings. Once the thin version compiles, paste additional blocks back in batches of 5–10, recompiling after each batch.

7. Compilation Errors Specific to the V12 SCL Compiler

The TIA Portal V12 SCL compiler is stricter than the V5.5 compiler. The following issues are not present in V5.5 source but are flagged immediately by V12.

7.1 Strict Type Checking on Assignments

V5.5 silently coerced INT to DINT and vice versa. V12 raises a warning. Use explicit casts (INT_TO_DINT, DINT_TO_INT) or change the variable types to match.

7.2 Block Interface Order

V12 requires the declaration order INPUT → OUTPUT → IN_OUT → STATIC → TEMP → CONST. V5.5 SCL allowed any order. The wizard reorders automatically; manual edits to the converted source must respect the order.

7.3 Symbolic vs Absolute I/O

V12 prefers symbolic addressing through the PLC tag table. Absolute addressing (e.g. %I0.0, %Q4.0) is permitted but the V12 compiler will emit a warning for every absolute reference. The cleanest path is to define a complete tag table during migration.

7.4 EN/ENO Behavior

FBs and FCs written in V5.5 SCL with implicit EN/ENO handling may behave differently under V12 when called from LAD/FBD. Wrap the call in an IF EN = TRUE THEN ... END_IF; block to preserve behavior.

8. Verification Procedure

After the migrated project compiles cleanly, perform the following checks before signing off the migration.

8.1 Offline Simulation

Use the TIA Portal PLCSIM option (S7-PLCSIM V12) to load the program into a simulated CPU. Step through OB 1 with breakpoints in each migrated FB. Verify that the UDT array is initialized correctly by reading db_LogBuffer.arr_Records[1] in the watch table.

8.2 Online Compare

Compare the online block timestamp of the migrated program against the customer's reference build. The timestamp on every block should reflect the V12 import date, not the original V5.5 date.

8.3 Watch Table Cross-Check

Create a watch table in V12 with one entry per UDT element of the first three array elements. Force each element to a known value, then read back to confirm round-trip integrity.

8.4 Customer Acceptance Test

Run the customer's FAT script against the migrated program. Pay special attention to the logging computer communication path, which was the original driver for the migration request.

9. Troubleshooting Matrix

10. Common Pitfalls and Field-Proven Caveats

• License mismatch: TIA Portal V12 requires a STEP 7 Professional V12 license to run the SCL editor. The SCL option license from V5.5 does not carry over.
• Firmware version check: The customer's CPU firmware (e.g. CPU 319-3 PN/DP firmware V3.2) must be supported by V12. If the CPU is older, TIA Portal will refuse to compile the hardware configuration.
• Symbolic I/O conversion: After migration, every EW0 reference becomes %IW0. Code that relied on byte-swap behavior of word-oriented I/O may need adjustment.
• Library blocks: Customer-specific libraries (*.s7l in V5.5, *.al12 in V12) must be re-built from sources. Binary library migration is not supported.
• Time-stamp collisions: If the V5.5 project was last saved within seconds of a previous save, the wizard may emit a timestamp collision warning. Save the V5.5 project, wait 10 seconds, then re-export.

11. Performance and Optimization Notes

Code migrated from V5.5 to V12 often runs faster on the same CPU because the V12 compiler performs stronger optimizations on SCL (constant folding, dead-code elimination, multi-instance array inlining). The runtime cost of an array of UDT access is O(1) at the SCL source level but the compiled STL emits indexed DB access. For arrays larger than 256 elements, prefer ARRAY[*] dynamic bounds (S7-1500) or split into multiple smaller DBs (S7-300/400/WinAC).

Watch table reads on UDT arrays are slower in V12 than in V5.5 because the watch table now reads the full snapshot rather than streaming changes. For high-speed debugging, use a separate non-UDT shadow DB and read from the shadow.

12. FAQ