Resolving STEP 7 Error 34:4470 LAD Converting to STL

Problem Overview

When opening a STEP 7 V5.x project—especially an online uploaded program from an S7-300 or S7-400 CPU—LAD (Ladder Diagram) and FBD (Function Block Diagram) blocks sometimes appear as STL (Statement List) source code. This automatic conversion is not a defect in the editor; it is the editor's documented fallback when the block container no longer carries the "additional information" needed to render the graphical view. Siemens surfaces this condition with diagnostic messages such as error 34:4470, often chained after 30:503 and followed by 34:175 the first time the block is opened.

This reference explains what triggers the conversion, what each error code in the chain means, how to recover the original LAD or FBD representation, and how to prevent the condition in development teams that span STEP 7 V5.4 SP5 through V5.5 SP3, V5.5 SP4, V5.6, and the TIA Portal V16/V17/V18/V19/V20/V21 migration boundary.

Error Code Reference

Root Cause Analysis

STEP 7 V5.x stores every block (OB, FB, FC, DB, UDT, SFB, SFC instance DBs) inside an S7 container that holds three logical layers:

1. Compiled code section — the MC7 machine code that the S7 CPU executes directly. Identical across the V5.x line and forward-compatible.
2. Symbolic interface — the ordered IN, OUT, IN_OUT, STAT, TEMP parameter list (and the source/sink section for instance DBs) used to resolve multi-instance and call wiring at compile time.
3. Additional information (Zusatzinformationen) — the graphical network layout, network titles, network comments, column-aligned rung comments, symbol associations, and the data-type-check flag required to redraw LAD/FBD without losing formatting.

The editor can only re-render a block in LAD or FBD if the additional information is still valid against the current interface and against the STEP 7 version that last saved the block. When any of the following conditions occur, STEP 7 discards the additional information and falls back to STL display:

• The block was uploaded from a CPU whose last compile was performed by a different STEP 7 V5.x service pack (cross-version upload).
• The block's interface signature changed (a parameter was added, removed, renamed, reordered, or had its data type altered in the declaration table) but the calling blocks were not recompiled to absorb the new signature.
• The project was archived in an older SDB/STEP 7 format and the receiving system rewrites the container structure on first save.
• The block was originally created with the "Type check off" option (a LAD/FBD editor compatibility toggle for legacy portability) and the new station enforces type checking on open.
• A multi-instance parent FB signature changed and downstream instance DBs were not regenerated.

Version Mismatch Mechanics

STEP 7 V5.4 SP5, V5.4 SP6, V5.5, V5.5 SP1, V5.5 SP2, V5.5 SP3, V5.5 SP4, V5.6, and the V5.6 HF releases each ship with incremental revisions to the block container format. The compiled MC7 section is forward-compatible across the entire V5.x line, but the additional information section is not. Opening a V5.4-compiled block in V5.5 SP3 for the first time triggers a format migration: STEP 7 regenerates the additional information based on the current interface and saves the block. Until that save happens, the editor shows STL and raises the 30:503/34:4470 chain. After the save, the block reopens in LAD/FBD as expected.

Interface Signature Drift

The interface signature is the ordered tuple of (name, type, initial value) for every IN, OUT, IN_OUT, STAT, and TEMP variable. STEP 7 also computes a hash of that tuple and stores it in the block header. If you insert a parameter in the middle of the IN section of an FB, every block that calls that FB inherits a new parameter-to-argument mapping. STEP 7 flags the inconsistency with warning 34:175 and, on the next compile of the caller, strips the additional information from the caller so the STL view becomes the only safe representation. The original author's LAD network cannot be regenerated from the decompiled STL automatically—network titles, comments, and graphical layout are gone.

How STEP 7 Decides to Decompile

When the editor cannot reconstruct a valid graphical view from the additional information, it performs an STL decompile. The decompiler walks the compiled MC7 code section and emits one STL statement per machine instruction. The output is byte-equivalent in execution; it is simply less readable. Key properties of the decompiled view:

• Symbolic identifiers are preserved (you still see Motor_Start rather than DB123.DBX0.0) provided the symbol table is loaded and the address-to-symbol resolution succeeds.
• Network titles, network comments, and column-aligned rung comments are lost.
• Code is shown as a flat sequence of A, AN, O, ON, S, R, L, T, U, UN, =, :=, JC, JCN, CALL instructions rather than graphical contacts and coils.
• Cross-references to the call sites are recomputed on the next compile; stale cross-reference entries are marked with a red dot until the project is recompiled.
• Uploads from older CPU firmware (e.g., S7-300 CPUs running firmware V2.x with blocks last compiled in V5.4) display STL until the project is resaved offline.

This is the same behavior documented for STEP 7 versions before V5, which is why the error text references those older releases explicitly.

Solution 1: Re-Save to Regenerate Additional Information

The simplest resolution is to let STEP 7 rebuild the additional information by saving the block.

1. Open the affected block from the offline program (S7 Program → Blocks → [block number]).
2. Right-click in the editor and choose File > Save (or press Ctrl+S).
3. When prompted "Valid additional information will be constructed at the next save," click OK.
4. Close and reopen the block; it should now display in LAD or FBD as originally authored.

For a project with many decompiled blocks, automate the save pass with an S7Script:

' VBScript run from the STEP 7 S7Script interface
Dim oBlock, oProject
Set oProject = Application.ActiveProject
For Each oBlock In oProject.Blocks
    If oBlock.Language = 3 Then   ' STL = 3
        oBlock.Save
    End If
Next
MsgBox "Save pass complete."

Solution 2: Resolve Interface Signature Mismatch

When the message chain includes 34:175, the root cause is a drifted interface. Use the following procedure:

1. In the SIMATIC Manager project tree, select the S7 program.
2. Choose Options > Check Block Consistency. STEP 7 enumerates every block whose interface is out-of-sync.
3. Right-click the result list and choose Compile All (or Compile for individual blocks).
4. STEP 7 recompiles the calling blocks against the updated interface, regenerating their additional information in the process.
5. Save the project. Reopen any previously decompiled blocks to confirm LAD/FBD rendering.

If the call wiring is wrong after recompiling (a parameter slot now binds to the wrong actual), correct the input/output wiring at the call site. For multi-instance FBs, verify that the parent FB's STAT section lists the instance name with the correct data type; renaming a multi-instance forces all child instance DBs to be regenerated.

Solution 3: Align STEP 7 Versions Across the Team

Where development spans multiple STEP 7 V5.x service packs, normalize the editor version used for the final compile:

The migration path from classic STEP 7 to TIA Portal retains STL exactly; LAD/FBD round-trip only when the source additional information has not been invalidated. Plan a one-time open → Check Block Consistency → save pass before the migration to keep the visual source.

Solution 4: Handle Disabled Data Type Check Blocks

The "Type check off" mode (LAD/FBD editor menu Options > Customize > LAD/FBD tab → "Type check off") was used historically to author blocks that mixed BOOL with INT operands or assigned different data types to the same wire. When such a block is opened on a station that enforces type checking, STEP 7 strips the additional information and shows STL.

1. Open the block. Note the warning that type checking has been disabled on the block.
2. Re-enable type checking: Options > Customize > LAD/FBD → uncheck "Type check off".
3. Address any type mismatch the editor now reports by inserting explicit conversions: WORD_TO_INT, INT_TO_WORD, BOOL_TO_INT, REAL_TO_DINT, or the IEC-standard casts.
4. Save the block and reopen it to confirm LAD/FBD rendering.

For a project-wide re-enable, iterate every block via S7Script and toggle the flag, then run Check Block Consistency to surface every conversion the editor now requires.

Verification Steps

1. Open SIMATIC Manager > Options > Check Block Consistency. The result list must be empty.
2. Compile the S7 program (Program > Compile All). The output window should report zero errors and zero warnings related to additional information.
3. Download the blocks to the CPU (PLC > Download) and confirm the CPU enters and remains in RUN.
4. Open each previously affected block and verify the title bar reads [LAD] or [FBD] and not [STL].
5. Compare the online block against the offline block (PLC > Compare Online / Offline) — code sections should be identical; symbol and comment sections may differ if the symbol table was edited.
6. Trigger a CPU restart (PLC > Operating Mode > Cold Restart) to confirm the regenerated blocks are accepted by the CPU firmware.

Troubleshooting Matrix

Prevention and Best Practices

• Standardize on a single STEP 7 V5.x service pack across the engineering team. Lock the installer version in your software CMDB and reject mixed-version archives.
• Run Check Block Consistency as a pre-commit gate before archiving or uploading to the CPU. Treat any 34:175 warning as a release blocker.
• Maintain the project on offline storage that matches the live version. A V5.4 SP5 archive should not be edited under V5.5 SP3 without first performing a migration save pass.
• When changing an FB interface, follow the change across every call site in the same session. Do not commit an FB change with stale callers.
• Avoid disabling data type check except for legacy single-bit INT workarounds. If the workaround is required, document it in the block header comment so future engineers know why the flag exists.
• Export the project as a *.S7P file in source control with a clear version marker. The export preserves the additional information; a raw ZIP archive without a re-save may not.
• Keep the S7 program blocks folder separate from the Sources folder; STL sources imported via Sources regenerate additional information on first compile and can mask a real interface drift.
• After every CPU firmware update, re-download the program blocks. New firmware versions occasionally alter how the upload buffer captures additional information, surfacing previously hidden mismatches.

Notes on Cross-Platform Migration

When migrating a STEP 7 V5.x project to TIA Portal V16, V17, V18, V19, V20, or V21, blocks whose additional information was already invalidated will import only as STL. To preserve the original LAD/FBD source in the migrated project:

1. In the classic STEP 7 editor, run Check Block Consistency and resolve every entry.
2. Save each affected block in LAD/FBD view.
3. Export the project as a *.S7P archive or a ZIP container.
4. In TIA Portal, choose Project > Migrate project and select the archive. LAD/FBD blocks transfer in their original representation; STL blocks transfer as STL with no graphical rebuild.
5. After migration, run Compile > Software (rebuild all blocks) in TIA Portal to generate fresh additional information under the new container model.

If the original STEP 7 station is no longer available, recover LAD/FBD manually by editing the STL representation; the decompiler output is functionally complete but lacks network comments. Add network titles and comments after rewriting, and re-validate the block with Check Block Consistency in the migrated project.

Frequently Asked Questions