Converting S5 to S7-300: Complete Migration Guide Using STEP 7

Overview

The SIMATIC S5 platform served as the Siemens workhorse for programmable logic control from the late 1970s through the 1990s, with the S5-115U, S5-135U, and S5-155U systems still in service in thousands of plants worldwide. The transition to the SIMATIC S7-300 and S7-400 families introduced a new CPU architecture, a redesigned memory model, and a fundamentally different programming environment in STEP 7. Migrating an installed S5 program base to S7-300 hardware is a structured engineering task that can be accelerated with the Siemens-supplied "Converting S5 Files" tool but always requires manual review of the resulting code.

This guide covers the complete conversion workflow for a typical four-CPU S5-to-S7-300 retrofit, the addressing and instruction-set differences between S5 Statement List (STL) and S7 STL, and the manual steps required to bring the converted program to a clean, compilable, and verified S7-300 project under STEP 7 V5.3 through V5.5.

Prerequisites

Before beginning any conversion work, assemble the following hardware, software, and source material:

• Source files. Obtain the original S5 STL source on disk or as a printed PDF listing. Programs originally written for S5-115U through S5-155U are typically delivered in *.st (sequencer), *.awl (statement list), or older *.s5d S5-DOS format. If only a paper printout exists, the file must be re-typed or scanned before electronic conversion is possible.
• STEP 7 V5.3 or later. The "Converting S5 Files" converter ships with STEP 7 V5.x and is launched from Start → SIMATIC → STEP 7 → Converting S5 Files. STEP 7 V5.5 with the latest Service Pack is recommended for new projects.
• S5 for Windows (IBH softec). Useful for reading and printing legacy S5 programs when an original STEP 5 license is unavailable. The English demo executable S5_S7DEMO_ENG.exe is a self-extracting archive that installs on Windows XP and later Windows versions and can import and re-export Siemens-style STEP 5 STL files.
• Target S7-300 station. CPU 314, 315-2 DP, or 317-2 are the typical S5-115U replacement candidates. Confirm the I/O count, communication interfaces, and program size against the original S5 CPU to avoid under-sizing.
• STEP 7 reference manuals. Two Siemens documents are mandatory reading: the STEP 7 – From S5 to S7 conversion manual and the broader SIMATIC S5 to S7 Migration – Renewal Manual.

S5 to S7 Architecture and Addressing Differences

The most important conceptual shift between S5 and S7 is the addressing model. Engineers who attempt to convert code without internalising these differences will spend a disproportionate amount of time on errors that are mechanical to fix once the model is understood.

Byte vs Word Addressing

S5 addresses memory in 16-bit words. The first data word is DW0, the second DW1, and so on. S7 addresses memory in 8-bit bytes. The first data byte is DBB0, followed by DBB1, and a 16-bit word is constructed from two consecutive bytes: DBW0 covers DBB0 and DBB1. The converter rewrites DWn to DBW(2n) in most cases, but any code that bit-tests inside a word using the S5 byte-swap convention will require manual verification.

I/O Addressing

Organisation Blocks

S5 program execution is split into OB1 (cyclic), OB2 (interrupt-driven) and a number of fixed interrupt OBs. S7 uses a larger fixed set, with OB1 still the cyclic main and OB10 through OB17 for time-of-day interrupts, OB40 through OB47 for hardware interrupts, OB80 through OB87 for error handling, and OB100/OB101/OB102 for startup. The converter cannot restructure program flow; it can only map the linear S5 STL into S7 STL inside OB1. Any time-of-day, process, or error logic originally coded inline must be lifted into the appropriate S7 OB and driven by the hardware configuration.

Function Blocks and Data Blocks

S5 Function Blocks (FBs) and Program Blocks (PBs) become S7 Function Blocks (FBs) and Functions (FCs). S5's instance data is held in a global "DX" extension data block; S7 stores instance data in an Instance DB that is generated automatically when an FB is called. The converter renames PBn to FCn and FBn to FBn but does not rebuild the DX into an Instance DB – this is one of the most common post-conversion manual fixes.

Timers and Counters

S5 supplies five timer types (SP, SE, SD, SS, SF) and three counter types (CU, CD, S, R, CS). S7 implements timers as IEC 61131-3 standard S_PULSE, S_PEXT, S_ODT, S_ODTS, S_OFFDT and counters as CTU, CTD, CTUD. The converter emits S5-style mnemonic L, SD, SP, etc., and S7 still supports them for compatibility, but new code should use the IEC FB versions with named instance DBs.

Step-by-Step Conversion Workflow

The end-to-end migration is executed in five phases. Each phase has a defined deliverable and an exit gate; do not advance until the gate is met.

Phase 1 – Acquire the S5 Source

1. Identify all PBs, FBs, DBs, and OB1 in the original program listing. The PDF or printout must show the block headers with the block number, the author, the block checksum, and the STL body.
2. If the source is a paper printout, reconstruct the *.awl text file in a plain-text editor. Use the same line numbering and tab stops as the original printout to make error localisation easier.
3. If the source is on an EPROM, S5 floppy, or S5-DOS file, use a STEP 5 PG or IBH softec S5 for Windows to read it out to *.awl. The English demo build is sufficient for read-only inspection and re-export.

Phase 2 – Run the Converting S5 Files Tool

1. Launch the converter from Start → SIMATIC → STEP 7 → Converting S5 Files.
2. Open the original *.awl file as the source.
3. Select the target S7-300 CPU family. The converter adjusts memory layout and available instructions based on the selected CPU.
4. Execute the conversion. A *.awl text file is produced in the destination directory. The converter logs warnings (cosmetic differences, automatic substitutions) and errors (instructions with no S7 equivalent) to a separate log file.

The converter typically translates 80% of a representative S5 program automatically. The remainder is flagged with an instruction reference and a description. Open the log file in a text editor and triage each error before continuing.

Phase 3 – Create the S7 Project and Import the Source

1. Launch the SIMATIC Manager and create a new S7-300 station project.
2. In the project tree, right-click S7 Program → Sources and select Insert New Object → External Source.
3. Give the new external source a name (e.g. converted_program), then drag the converted *.awl file from the destination directory onto the external source object. Alternatively, use File → Open from inside the source editor and navigate to the file.
4. Open the source by double-clicking the external source object. The STL body will be loaded into the editor.
5. Trigger a compile with File → Compile (or Ctrl+B). The compiler writes a structured error list to a separate window.

Phase 4 – Resolve Compilation Errors

The compiler errors fall into a small number of well-understood categories. The table below maps each category to the standard fix.

Phase 5 – Compile Clean and Download

1. Iterate Phase 4 until the compiler produces zero errors. Warnings can be accepted if reviewed.
2. Open HW Config and rebuild the S7-300 station with the CPU, IM, SM, FM, and CP modules that match the original S5 I/O footprint. Save and compile the hardware configuration.
3. Download the hardware configuration to the CPU first, then download the user program blocks.
4. Perform an initial CPU restart (cold restart, OB102) and verify that the CPU enters RUN with no SF (system fault) LED indication.

Verification and Commissioning

Compilation success is necessary but not sufficient. A converted program must be functionally verified against the original S5 behaviour before it is allowed to control a running process. Use the following structured approach.

Static Verification

• Cross-check the block call hierarchy in the converted S7 project against the original S5 call structure. The SIMATIC Manager "Reference Data → Program Structure" view should match the S5 block list one-for-one.
• Compare the I/O address assignments in HW Config with the original S5 E / A addresses. A common field error is the loss of the input byte 0 / output byte 0 mapping when the IM360/IM361 backplane is reconfigured for S7-300.
• Audit every Instance DB to confirm that the data layout matches the original DX extension data block. Off-by-one byte errors are the most frequent finding.

Dynamic Verification

1. Download the program with the CPU in STOP and perform a warm restart to OB100, then a cold restart to OB102, and confirm that the startup OB executes cleanly.
2. Use a STEP 7 Online watch table on each block to step through OB1 execution and verify that the accumulator state, status word, and RLO match the S5 reference behaviour at key program points.
3. Force inputs in the watch table to simulate process conditions and verify that outputs respond identically to the S5 reference. Document the test cases in a signed-off test sheet.
4. Where the S5 program controls a safety-rated function, run a separate SIL verification and update the safety case file; do not assume that a code-converted non-safety program can be promoted to a safety function without re-validation.

CPU Diagnostic Buffer

Inspect the CPU diagnostic buffer (PLC → Diagnostic Buffer) after every commissioning step. The buffer records OB start/stop events, time-of-day interrupts, and any stop events with their associated event IDs. A typical S5-to-S7 conversion that has not been fully validated will produce periodic OB85 (process image update error) and OB122 (I/O access error) events, which indicate that an I/O address is being polled before the module has updated its PI.

Tool Reference Summary

Field-Proven Pitfalls

These are the most frequent field problems encountered during S5-to-S7 conversions, recorded here as a checklist rather than as a tutorial section.

• Accumulators 1, 2, 3, 4. S5 uses a single accumulator for most operations. S7 has four. The converter inserts hidden POP / accumulator-load instructions in many places but misses cases where S5 code intentionally left a value in the accumulator across blocks. Recheck any code path that crosses an FB/FC boundary.
• BCD / integer conversion. S5 BCD timers and counters store the value in BCD. S7 BCD timers also exist, but the IEC counter/timer FBs use binary. If the original S5 program read a timer word with L T 5 and processed it as BCD, the S7 program must use LC T 5 (load BCD) rather than L T 5 (load binary).
• Process image update. S5 updates the process image on every OB1 scan by default. S7 updates it once per OB1 scan only if the relevant inputs are in the configured process image. Accessing inputs outside the PI requires PID / direct I/O and does not benefit from the PI update.
• Retentive flags. S5 non-retentive flag area is M 0.0 – M 199.7; retentive area is M 200.0 – M 255.7. S7 retentive behaviour is configured in HW Config → CPU Properties → Retentive Memory. The default S7 retention is zero bytes of MB and zero timers/counters, which differs from the S5 default and is a frequent source of warm-restart faults.
• German comments. The original S5 program is often authored in German, with instruction labels, symbol table names, and FB comments in German. Plan a symbol-table translation pass before commissioning to keep the converted program maintainable by the operations team.

FAQ