Siemens S5 to S7 Program Conversion Tools, Limits, and Migration

1. Overview of the S5 to S7 Migration Challenge

The Siemens SIMATIC S5 family reached end-of-service in 2014 for most CPUs, and the SIMATIC S7-300/S7-400 (and successor S7-1200/S7-1500) platforms are now the only supported Siemens controllers for new and service projects. Migrating from S5 to S7 is not a one-step automatic process. The STEP 5 programming model uses block types and operand concepts that do not map cleanly onto STEP 7, and a number of S5 constructs (register-indirect addressing, certain absolute DB word operations, multi-instance data access patterns, and the German "Zuordnungsliste" / assignment list format) have no direct S7 equivalent.

Three practical conversion paths exist:

1. Siemens STEP 7 S5/S7 Converter (optional add-on to STEP 7 V5.x) — an automatic translator that lifts STL/FBD/LAD blocks from STEP 5 to STEP 7 with operator-controlled mapping.
2. TIA Portal Migration (TIA Portal V13 and later) — converts STEP 7 V5.x SPx projects and, where the S5 source is already in STEP 7, leaves a known starting point.
3. Manual / hybrid conversion — automatic conversion first, then a structured manual rewrite into idiomatic S7 (instance DBs, multi-instances, IEC timers/counters, structured tag names).

Field experience consistently shows that even a "successful" automatic conversion must be reviewed and cleaned up. The translated STL often compiles but will not behave like a native S7 program: flag (Merker) usage explodes, indirect addressing becomes syntactically illegal, and block parameter semantics shift.

2. Siemens' Native Conversion Tools

2.1 STEP 7 V5.x S5/S7 Converter

The S5/S7 Converter ships as an optional install on the STEP 7 V5.x installation media and is invoked from the SIMATIC Manager. It accepts STEP 5 source files (STL.S5D, S5 project archives) and produces a STEP 7 S7 program (sources and compiled blocks). The converter operates at the STL level, so LAD and FBD in S5 are first decompiled to STL before translation.

Typical workflow:

1. Create a new STEP 7 project with the target CPU (e.g., S7-300 with CPU 314, S7-400 with CPU 414, or S7-400H if migrating from S5-115H / S5-155H).
2. Insert an S5 program source from Options > S5/S7 Converter and select the STEP 5 source files.
3. Run conversion; the converter emits an HTML or text report listing every block and the conversion status of each network.
4. Compile the converted S7 blocks in SIMATIC Manager; resolve any remaining STL syntax errors manually.
5. Download to the target hardware and verify against the S5 reference if available.

2.2 TIA Portal Migration (V13+)

TIA Portal V13 introduced a project migration tool that imports STEP 7 V5.x projects (and STEP 7 Professional V11..V12 projects) and converts them to the TIA Portal data model. For an S5 program that has already been lifted to STEP 7 V5.x via the S5/S7 Converter, this is the recommended path to a modern S7-1500 or S7-1200 target. Migration to S7-1500 carries further restrictions (S7-1500 does not support STL in the same way as S7-300/400); most migrated blocks must be converted to LAD, FBD, SCL, or GRAPH at this stage.

3. S5 to S7 Converter: What It Handles Automatically

The converter translates the most common STEP 5 STL statements. The table below summarizes the mapping behavior. Where the mapping is partial, the converter inserts a comment and an error stub so the engineer can resolve the case manually.

4. Known Limitations of Automatic Conversion

The S5/S7 Converter emits a conversion report. The categories of issue that consistently appear are summarized below; each one requires manual resolution by the engineer.

4.1 Indirect Addressing

S5 supports four forms of indirect addressing that map poorly to S7:

• Memory-indirect via flags (e.g., L MW [AR1] in S5-style) — in S7 STL this becomes L MW [AR1,P#0.0], but only if the area pointer is set up first.
• Register-indirect via AR1/AR2 — requires conversion to the S7 area-pointer model (P#DBX0.0, P#M0.0).
• DB-indirect via DO DW / DO FW patterns — the S5 implicit "open DB by operand" is not supported in S7; convert to OPN DB [MW] and L DBB [MD].
• Parameter indirect access inside FBs that read parameters by name (BA/BB/BE/BY/BI/BD) — must be replaced with explicit IN/OUT/STAT parameter slots and renamed.

4.2 DB Addressing Errors

The converter often botches DB addressing for two reasons:

• S5 allows multiple open DBs concurrently via A DB / AX DB; S7 has only one open DB. The converter typically picks the first declaration and drops the second, so any L DR reads of the secondary DB return zero or wrong data.
• S5 data words are numbered starting at 0; S7 data words also start at 0, but bit access (D X x.y vs DBX x.y) and byte/word/dword alignment differ in subtle ways. The converter frequently shifts an address by one byte.

4.3 Flag (Merker) Explosion

S5 programs commonly use flags F 0.0 ... F 255.7 as scratch variables. The converter carries them across as M 0.0 ... M 255.7, which works but yields an S7 program that is hostile to commissioning. Field practice is to convert the most heavily used flags into instance DB variables inside the FB that uses them, and to drop the global M area to a small set of cross-block coordination bits.

4.4 Formal Operand Blocks (FX/FY/FW)

S5 lets an FB call another FB through a formal operand (FX for FB call, FY for PB/SB call, FW for data word reference). The converter emits a CALL with a stub comment, but the called FB cannot be resolved without an explicit instantiation table. Manual fix: declare an FC wrapper that picks the correct FB based on a control word.

4.5 Block Type Mapping

5. CPU-Specific Migration: 115U CPU943/944 to CPU945

The SIMATIC S5-115U hosts three relevant CPU variants for migration: CPU 943, CPU 944, and CPU 945. The CPU 945 extends the address space, increases the flag and timer/counter budgets, and adds instructions that CPU 943/944 do not have. When an S5 program is moved from CPU 943/944 to CPU 945 — or, more commonly, when the program is converted to S7 from a CPU 943/944 source — these differences matter:

• Address space: CPU 945 extends flag area and DB area. Any program that uses addresses above the CPU 943/944 limit is legal on CPU 945 but will silently overflow on the smaller CPUs. Validate flag and DB limits before conversion.
• Instruction set additions: CPU 945 adds extended bit/word operations and additional timer/counter organization blocks. The converter may emit instructions that have no direct STL equivalent on a smaller CPU target; choose the S7-300/S7-400 target with sufficient instruction coverage (e.g., CPU 315-2 PN/DP, CPU 416-3 PN/DP).
• OB structure: CPU 945 has additional OBs (e.g., OB 21/22 for restart, OB 31/32 for time-of-day interrupt). The converter preserves OB calls but does not always wire the OB correctly in OB 1.

For the official Siemens reference, see the Siemens Industry Online Support article "Conversion of S5 programs from CPU943/944 to CPU945" (ID 144611). This article lists the mandatory checks before moving a STEP 5 project onto a CPU 945 (or onto an S7 target that emulates CPU 945 behavior).

6. Assignment List (ZULI) Language Conversion

The STEP 5 assignment list (German: Zuordnungsliste, abbreviation ZULI) maps symbolic names to absolute addresses. STEP 5 installations shipped with German operand mnemonics (E / A / M / T / Z / D for inputs/outputs/flags/timers/counters/data) and STEP 7 installations use English mnemonics (I / Q / M / T / C / DB) by default. The assignment list is stored in the S5 project file alongside the STL sources.

To convert a ZULI from German to English operand mnemonics:

1. Back up the file. Make a copy of the original S5 project archive before any modification; the ZULI cannot be reconstructed if the conversion corrupts it.
2. Open the STEP 5 program editor (PG 2000 / STEP 5 V7.x) and switch the editor language to English.
3. Load the S5 program and re-export the assignment list. The editor will transliterate operand mnemonics automatically.
4. Cross-check every symbolic name against the S5 STL sources to confirm the symbolic resolution did not shift byte addresses. Pay attention to SY / SR flag references and to DB word symbols that share a name with a flag symbol.
5. Re-import the English ZULI into the S5 program and recompile. The output STL must be functionally identical to the German-original STL; diff the STL byte-for-byte to confirm.

The official Siemens Support article "Assignment list: convert operands German - English" (ID 51092) is the authoritative procedure for this conversion and should be read in full before any production ZULI is touched.

7. Restructuring S5 Patterns for S7 Best Practice

The conversion gets the program running, but the result is rarely idiomatic. The most useful follow-on restructuring is to move from global flag-based state to instance-based state.

7.1 Flags to Instance Data Blocks

In S5, an FB that needs state variables carries them as flags set by the calling block. In S7, the same state is expressed as STAT variables inside the FB, with each instance getting its own DB. Conversion pattern:

// S5 pattern
      L   F 100       // Step number
      L   3
      <>F              // Compare to 3
      JC  STEP3
      L   F 102       // Counter
      +   1
      T   F 102
STEP3: ...

// S7 pattern (instance DB "iDB_Motor")
      L   #iStep
      L   3
      <>I
      JC  STEP3
      L   #iCounter
      +   1
      T   #iCounter
STEP3: ...

The flag area in S7 is then reserved for cross-block coordination only (start/stop bits, handshakes, alarm bits).

7.2 Timers and Counters to IEC Blocks

S5 timers (SP, SE, SD, SS, SA, SF) and counters (CU, CD, S, R) are fixed-function blocks with a static area in the S5 CPU. S7 supports the legacy S5-compatible blocks (S_PULSE, S_PEXT, S_ODT, S_ODTS, S_OFFDT) as well as IEC 61131-3 instances (CTU, CTD, CTUD). Best practice after conversion is to replace each timer/counter call with an IEC instance inside the relevant FB so the timing is part of the FB's data context.

7.3 Symbols and Comments

The S5 symbol table exports cleanly into the STEP 7 symbol table, but bit-level comments (// F 12.3 = Pump 1 running) are often dropped. Re-enter these comments in the S7 source before commissioning; they are the only documentation the next engineer will have.

8. Third-Party Conversion Tools

Several third-party packages exist; they generally fall into three categories:

1. Siemens S5/S7 Converter alternatives — claim better coverage of indirect addressing or DB addressing than the Siemens tool. Field reports indicate marginal improvement; no tool closes the gap fully.
2. Engineering service firms — provide a human-led conversion: automatic pass first, then a senior engineer rewrites the program into native S7. This is the most reliable path for production lines that cannot tolerate a behavior shift.
3. Demonstration / trial packages — restricted to a few hundred STL statements but useful for evaluating the converter on a representative snippet of the S5 source before commissioning a full project.

When evaluating any third-party tool, the decisive test is a sample conversion of the most complex S5 code in the plant: the sequencer (SB / DO blocks), the recipe block (DB with indirect addressing), and the alarm-handling block (FB with formal operand call). If the tool handles these three correctly, the rest will follow.

9. Manual Conversion Strategy and Workflow

For a complete migration, follow this order:

1. Inventory the S5 program. List every OB, PB, FB, SB, DB, and the symbol table. Note which blocks use indirect addressing and which use formal operand calls. Mark OB blocks separately.
2. Pick the S7 target. Choose CPU, signal modules, and any required fail-safe or redundancy configuration. S7-300 with CPU 319-3 PN/DP is a common target for S5-115U; S7-400 with CPU 417-4 is the target for S5-135U / S5-155U.
3. Run the automatic converter. Convert the S5 source to STEP 7 STL. Save the full conversion report.
4. Compile and fix syntax errors. The first compile pass will produce a list of illegal STL statements. Fix them one at a time, starting with the lowest-level FBs.
5. Rework the program structure. Replace global flag state with instance DBs; replace DO sequences with GRAPH or FC-based state machines; replace legacy timers/counters with IEC instances.
6. Re-enter comments and symbols. Symbol names cross over; comments do not.
7. Compile the final S7 program and run the STEP 7 consistency checker.
8. Simulate with PLCSIM if available; otherwise, run a controlled test on the target hardware with the process in a safe state.
9. Download and commission. Walk every input/output from the I/O list to confirm the wiring, then run the process under operator supervision.

10. Verification and Commissioning

Verification after conversion has three layers:

10.1 Static Verification (Offline)

• Cross-reference check: confirm every symbol used in STL is declared in the symbol table or in an FB parameter list.
• Address overlap check: scan for two FBs writing the same flag bit or DB byte.
• Block call check: every CALL target exists; every FB instance DB is correctly sized to the FB's STAT footprint.
• OB coverage: every OB that the S5 program relied on (OB 21/22 for restart, OB 31/32 for time-of-day interrupt) is present in the S7 program.

10.2 Dynamic Verification (Online)

• Status / control: monitor the converted FB in RUN; step through the STL network by network against the S5 reference trace.
• Trigger sequence: replay the input sequence that exercises the most complex S5 code path (sequencer transitions, recipe loads, alarm handling).
• Edge cases: short-pulse detection, lost-interrupt handling, power-down / power-up restart. S5 and S7 differ in restart behavior; OB 100 in S7 replaces S5 OB 22.

10.3 Process Acceptance

• Run the production line for a defined period under the converted program with the S5 program on standby.
• Capture any anomaly (timing shift, alarm that did not fire, latched bit) and roll back to the S5 if the anomaly is unacceptable.
• Document every manual change made during conversion in a "migration delta" report.

11. Troubleshooting Matrix

12. Practical Recommendations

• Convert to STL first, then to LAD/FBD/SCL only where required. STL preserves the most fidelity in the conversion. Do not ask the converter to output LAD for an S5 program that was originally STL — the round trip loses information.
• Keep the S5 source under version control alongside the converted S7 source. Any future re-conversion (e.g., if the S7-300 is replaced by an S7-1500) starts from the S5 original, not from a half-converted S7 program.
• Plan the cutover at a process stop. Conversion will surface at least one unexpected issue that requires a manual patch. A four-hour stop is more reliable than a hot cutover.
• Keep a written conversion report. The S5/S7 Converter's HTML report, plus the manual changes, plus the verification logs, form the audit trail for the next engineer.