STEP 7 V5.5: Compile S7 Sources Directly to Ladder (LAD)

Overview: STEP 7 V5.5 Source Compilation Behavior

When you export S7-300 or S7-400 program blocks to an S7 source file (.src) and re-compile the source inside STEP 7 V5.5, every output block in the S7 program appears with its authoring language set to STL (Statement List) — regardless of the language the block was originally written in. The "Compile Source" dialog in SIMATIC Manager does not expose a switch to change this default, and no command-line option or registry value overrides it. The only documented way to switch the rendered language to LAD (Ladder Logic) or FBD (Function Block Diagram) is to open each block in the LAD/FBD/STL editor, change the view, and save the block back to the offline program.

For a project that contains 30, 50, or several hundred function blocks (FCs) and function blocks (FBs), the per-block open / view / save / close cycle is impractical. This reference documents why the source compiler behaves this way, the precise manual conversion sequence, the supported semi-automated paths in STEP 7 V5.5 SPx, and a complete VBA automation macro that drives the SIMATIC Manager OLE interface to bulk-convert every eligible block to LAD in a single unattended run. The procedure applies to STEP 7 V5.5 through V5.5 SP4 with the appropriate hotfixes installed, and to any CPU family that STEP 7 V5.5 supports (S7-300, S7-400, C7, WinAC). Where S7-300 and S7-400 differ in the conversion behavior, both are noted.

Why S7 Sources Always Compile to STL

The S7 source file format is a textual export of the compiled block in STL. The source compiler (S7COMP, the s7comp.dll module shipped in the STEP 7 ...\S7BIN directory) parses the input stream, performs syntax and semantic checks against the loaded symbol table, and emits the MC7 machine code that the CPU executes at runtime. There is no intermediate LAD or FBD representation in the source pipeline: the parser walks an STL-like token stream (BEGIN, NETWORK, A, O, =, JU, and so on) and produces an STL-authored block. The "programming language" attribute of the resulting block is therefore set to STL by the compiler, even if the original network uses symbolic ladder structures in the editor.

The reason is rooted in the editor architecture of the LAD/FBD/STL block editor. The source view is a one-way export of the block contents. The reverse path — re-parsing a textual ladder into MC7 — does not exist in the STEP 7 V5.5 codebase. STEP 7 does not ship a "compile source to LAD" toggle because the source language itself is effectively STL with a richer comment and section structure. The "language setting" of a block is a metadata attribute on the offline block container, and the View menu in the LAD/FBD/STL block editor can re-render an STL block into LAD or FBD whenever the network structure permits. This re-rendering is what the manual conversion procedure exploits, and it is what the bulk automation macro below drives programmatically.

For S7-300 and S7-400 targets compiled in STEP 7 V5.5, the supported workflow is therefore: compile from source → open block → switch view to LAD → save. The View > LAD command is implemented inside the STEP 7 block editor and uses the live MC7 code plus the original symbol and comment information to rebuild a ladder representation. The view command does not alter the MC7 code itself; the CPU executes the same machine code before and after the conversion.

Manual Block-by-Block Conversion Procedure

The standard manual workflow is documented in the STEP 7 V5.5 online help under "Displaying STL Programs in LAD or FBD" and in the STEP 7 — Programming with STEP 7 reference manual. The procedure for a single FC is as follows.

1. In SIMATIC Manager, open the S7 project and navigate to the target station, CPU, and S7 program. Expand the Blocks container.
2. Double-click the FC (or FB) to open it in the LAD/FBD/STL block editor. STEP 7 first attempts to display the block in its declared source language; because the source was compiled as STL, the editor opens in STL view.
3. From the menu bar, choose View > LAD. The editor re-renders the current network in ladder representation. If a network cannot be represented in LAD — for example, it uses indirect addressing on a multi-instance, or contains a LBL/JU goto construct — the view command fails and the editor reports the network number in a dialog and stops at that network.
4. Save the block with File > Save or Ctrl+S. The block's Created in language attribute is updated and the offline block is flagged as modified in the S7 program.
5. Close the block with File > Close. The block editor is single-instance: only one block can be open at a time. Repeat for the next block.

For an S7 program with 50 FCs, the operation must be repeated 50 times. The block editor is single-instance: only one block can be open at a time, so the user cannot run a parallel batch. Each open / view / save / close cycle takes roughly 3-8 seconds on a typical project, so 50 blocks translates to 2.5-7 minutes of pure interaction time, plus the overhead of scrolling the Blocks container and locating each FC. The cycle is CPU-bound by the editor's re-rendering pass, not by I/O on the project file.

Block Attributes: "Created in" vs. "View" Language

Each offline block in an S7 program carries two language-related attributes visible in the block properties dialog. Open the dialog with a right-click on the block and choose Object Properties (or Special Object Properties > General). The relevant fields are:

The source compile step always sets Created in to STL. The View attribute is initialized to the Created in value when the block is opened. Changing the view does not change Created in until the user saves. Once the block is saved in LAD view, the Created in attribute is updated to LAD and subsequent openings default to LAD view. This is the mechanism the manual procedure — and the bulk macro — exploits.

Importantly, the Created in language has no effect on CPU execution. The CPU executes the MC7 code in the block body regardless of the authoring language. The attribute exists for documentation, version-control, and team-convention reasons. Setting it to LAD does not change how the CPU runs the block; it changes only how the offline program represents the block to the editor and to the next source export.

SIMATIC Manager Batch Operations: What Exists Out of the Box

STEP 7 V5.5 does not include a built-in "compile all sources to LAD" menu command. The relevant batch operations shipped with the software are:

None of these operations modify the Created in attribute. To change a block's authoring language after a source compile, you must open the block, switch the view, and save. The only native STEP 7 path to bulk-convert a set of blocks is therefore the editor-driven manual procedure. The next section covers the supported automation path through the SIMATIC Manager OLE / COM interface.

The S7 Automation COM Interface

STEP 7 V5.5 exposes its SIMATIC Manager object model through the SIMATIC Automation Manager COM interface, also documented in the STEP 7 online help as the STEP 7 OLE Automation Interface. The interface allows external scripts — most commonly written in VBA from within Office applications or from the SIMATIC Manager's own VBA IDE (Alt+F11), but also in any COM-capable language such as VBScript, Python via win32com, or C# via COM interop — to enumerate projects, stations, CPUs, S7 programs, and blocks, and to call the same Open, View, Save, Close operations the editor exposes to the user.

The relevant entry points for the bulk-conversion use case are:

• S7Simatic.S7App — root automation object; instantiated via CreateObject("S7Simatic.S7App") from any COM host.
• S7App.ActiveProject — the currently open SIMATIC Manager project.
• Project.Programs(i) — collection of S7 programs in the project (index 1-based).
• Program.Blocks — collection of blocks in the S7 program.
• Blocks.Item(name) / Blocks.Item(i) — returns a single block dispatch.
• Block.Type — block type enumeration: 1 = FB, 2 = FC, 3 = DB, 4 = SDB, 5 = SFB, 6 = SFC, 7 = OB (exact constants per the STEP 7 manual).
• Block.Language — current Created in attribute (0 = STL, 1 = LAD, 2 = FBD; SCL/GRAPH/HiGraph/CFC use higher indices).
• Block.View — view language in the open editor (same enumeration as Language).
• Block.Open, Block.Save, Block.Close — editor lifecycle methods.

The View property is read-write while the block is open. Setting it triggers the same re-rendering pass that the View > LAD menu command runs, and is subject to the same network-level conversion constraints. A failure on a specific network raises a COM error which the caller can trap and continue past.

VBA Automation: Bulk-Convert All FCs to LAD

The following VBA procedure runs inside the SIMATIC Manager's built-in VBA IDE (Alt+F11 in SIMATIC Manager) and converts every FC in the active S7 program to LAD. The script performs two passes: a first pass to collect block names (so the enumeration is not affected by intermediate edits), and a second pass to open, view, save, and close each eligible FC. The procedure reports a summary dialog at the end.

If the S7 Automation COM type library is not registered on the machine (typical for fresh STEP 7 installations that have not been started once), run the following from an elevated command prompt before launching the macro:

regsvr32 "C:\Program Files\Siemens\Automation\SIMATIC Manager\EXE\S7Simatic.dll"

On 64-bit Windows with 32-bit STEP 7, the DLL lives under C:\Program Files (x86)\Siemens\Automation\SIMATIC Manager\EXE\. Re-run the command after every STEP 7 service pack install, because SP installers sometimes re-register the type library with a refreshed GUID.

Python Equivalent (pywin32)

Engineers who prefer scripting in Python can drive the same COM interface through win32com.client. The object model and method calls are identical; only the syntax changes. The script runs on any Windows host with STEP 7 installed and Python 3.x with the pywin32 package.

VBScript Variant for Scheduled / Unattended Runs

For engineers who need the conversion to run as part of a build script, VBScript wrapped in a .vbs file driven by the Windows Task Scheduler or by a CI runner is a common pattern. The script is identical in structure to the VBA version, with the COM automation handled by CreateObject in the global namespace.

Place the script in the same Windows user profile that owns the SIMATIC Manager session. The COM interface does not support cross-session automation; the script must run in the interactive session that owns the running SIMATIC Manager process.

SCL as an Alternative Path to Cleaner LAD Output

S7-SCL (Structured Control Language) is the Pascal-like high-level language option for S7-300 and S7-400, available as a separate optional package on top of STEP 7 V5.5. The package article number is 6ES7811-1CC04-0YX0 (or its successor). SCL sources compile through the SCL compiler, which emits STL-authored blocks whose networks are written in a more structured form. As a result, SCL-compiled blocks convert to LAD with a higher success rate than hand-written STL because the compiler inserts the network markers, branch markers, and stack-balance instructions that the LAD view requires.

Practical guideline: if you need the final block to live in LAD, write the original logic in SCL and let the SCL compiler emit the MC7 code. The subsequent View > LAD step will succeed for the overwhelming majority of networks. Direct LAD authoring in the editor remains the most LAD-friendly path, but for engineers who prefer textual editing and version control, the SCL → STL → LAD pipeline is the closest equivalent to "compile to LAD directly."

STL-to-LAD Conversion: What Cannot Be Converted

The View > LAD command can refuse specific networks. The most common reasons are listed in the STEP 7 online help under "Why Can You Not Display an STL Program in FBD or in LAD?" and summarized in the STEP 7 manual. The full list of unrepresentable constructs includes:

• Indirect memory access via the address register (LAR1, TAR1, +AR1, -AR1, LAR2, +AR2, etc.) that the LAD parser cannot statically resolve.
• Use of the BR binary result word in mid-network stack manipulation.
• Multi-instance DB access with a calculated instance name (e.g., DB[Idx] patterns compiled to indirect opens).
• Network labels (LBL / JU / JC) used as goto targets — ladder is strictly linear per network.
• Calls to system functions (SFC) where the ANY pointer parameter is built dynamically in STL.
• Use of the accumulator 1 / accumulator 2 as a working register for arithmetic that spans networks.
• Direct bit access on the local stack (L LW + offset, T LW + offset) that the LAD view cannot reconstruct symbolically.
• Use of the loop instructions LOOP with the loop counter in the local word stack.
• Calls to system blocks (SFB / SFC) that themselves contain unconvertible STL internally — the call is allowed, but inlined inline code inside the calling block is not.
• Bit slice operations on data words (SLW / SRW on non-constant counts where the count is computed at runtime).

When the editor encounters one of these constructs, it stops the view conversion at the offending network, displays a dialog identifying the network number, and leaves the rest of the block in STL. The block will not save as LAD; it stays STL. The VBA macro above catches the failure (via On Error Resume Next) and continues with the next block. A subsequent manual pass on the failed list is required.

STEP 7 V5.5 Service Pack and Hotfix Considerations

The behavior described here is consistent across the STEP 7 V5.5 family, including SP1, SP2, SP3, and SP4. The S7 Automation COM interface was first introduced in STEP 7 V5.0 and reached a stable shape in V5.3. The VBA bulk-conversion macro is supported from STEP 7 V5.3 SP2 onward. No service pack adds a "Compile source to LAD" menu command — the underlying source compiler architecture has not been changed in this regard.

Known issues addressed by service packs that interact with the bulk conversion workflow:

The current STEP 7 V5.5 SP level is SP4 (K5.5.4.0) plus the HF7 / HF8 / HF13 hotfixes distributed through Siemens Industry Online Support. Install at minimum SP3 to run the bulk conversion macro without dialog interaction; the SP2 "re-install prompt" requires either VBScript dialog suppression or a manual click on each block, which defeats the purpose of the macro.

S7-300 vs S7-400 Differences

From the perspective of the source compile and view-conversion workflow, the two CPU families behave identically — both consume the same MC7 code and both render through the same LAD/FBD/STL editor. The differences that matter in practice for this workflow are environmental:

The only behavioral difference for the bulk-conversion macro is the optional filter on block type. The S7-300 environment sees FBs and FCs; the S7-400 environment additionally sees multi-instance-aware FBs whose view conversion may fail more often because of the multi-instance patterns in the network. The macro above filters to FCs only; expand the filter to include FBs (Type = 1) if those need conversion as well, but expect a higher failure rate on FBs with multi-instance DBs.

Verification: Confirming That the Conversion Took Effect

After running the macro, verify the change with the following checks. These steps are essential to confirm that the view conversion was not a no-op and that the modified blocks are valid.

1. In SIMATIC Manager, right-click the S7 program and choose Object Properties. The Blocks container statistics (visible in the dialog) include a count of blocks authored in each language; it should now show N LAD FCs (where N is the number of blocks the macro successfully converted).
2. Open any converted FC. The editor must open directly in LAD view; the title bar of the editor window shows FC1 — [LAD] if the Created in attribute is LAD.
3. Cross-check the source export: right-click the Blocks folder > Generate Source. The generated .src file still uses STL syntax internally; the Created in attribute is preserved in the source header comment, and you will see // LAD markers next to the FC declarations in the SECTION header.
4. Consistency check: PLC > Check Block Consistency must return no errors. The View > LAD command does not change the block interface, but if any FC failed to convert, the consistency check will highlight the mixed-language FC for review.
5. Compile to MC7: PLC > Compile and Download Objects (or Compile only) must complete without errors. This confirms that the LAD view is a valid rendering of the underlying MC7 code and that no bit-pattern corruption occurred in the save cycle.
6. Online block comparison: with the CPU online, right-click the Blocks folder and choose PLC > Compare Online / Offline. The comparison must report no logical differences (only metadata differences, which are expected and acceptable).

Best Practices for Teams That Need LAD in Source

• Standardize on SCL for any new text-sourced logic. SCL compiles to STL that converts to LAD more reliably than hand-written STL. Adopt an internal style guide for SCL constructs that map cleanly to LAD (avoid pointer arithmetic, prefer static array indices, avoid LABEL/GOTO constructs).
• Tag blocks with the language convention in the block comment. After bulk conversion, the Created in attribute is the source of truth. Set the block comment to include a marker such as {LAD} so a future source export / import cycle does not silently revert to STL view.
• Run the bulk conversion once, after the final source compile, before download. Re-importing a source file will revert the Created in attribute back to STL. Treat the conversion as a post-import polish step, not as part of the canonical build pipeline that owns the .src file.
• Filter out SDBs, SFBs, SFCs, and system blocks in the macro. They are not eligible for view conversion; the macro should skip them by checking the block type. The sample above filters to Type = 2 (FC) only; expand the filter to include FBs (Type = 1) or DBs (Type = 3) if those need conversion as well, but be aware that FBs with multi-instance DBs may not be view-convertible.
• Keep a backup of the offline program before the macro runs. The macro modifies offline blocks. Although view changes are non-destructive to MC7, the bulk save modifies the S7 program file on disk. A SIMATIC Manager archive (File > Archive) of the project takes seconds and protects against any unexpected editor behavior. The archive can be retrieved with File > Retrieve if a rollback is needed.
• Document the conversion in the project change log. Add a {LAD-converted 2025-11-14 by macro ConvertAllFCsToLAD} marker to the block comment of every converted block. The marker persists in the .src file and makes the next build audit trivial.
• Schedule the macro as a build-server post-step, not a developer desktop step. The COM interface requires an interactive SIMATIC Manager session. Run the macro on a dedicated engineering workstation that always has the project open, and trigger it from a CI job that uses Windows Scheduled Tasks or a Jenkins Windows agent.

Troubleshooting Matrix

Integration with Version Control

Teams that store the S7 program as a .src file in Git, SVN, or another VCS face a recurring conflict: the canonical source is STL, but the team wants to develop in LAD. The recommended pattern is the SCL → STL → LAD pipeline described above. Store the SCL sources in the VCS; let the SCL compiler emit the STL on the build server; let the bulk-conversion macro render the offline blocks in LAD; check the rendered blocks into a separate "distribution" branch that the developers consume. The build server is the single point where the conversion runs, which prevents the "re-import reverts to STL" failure mode that the FAQ addresses.

For teams that prefer to commit the rendered offline program directly, the export format is the S7 project .s7p file (or the archived .zip from File > Archive). The .s7p file is a binary container; use a binary diff tool (e.g., git diff --binary) to track changes. The view-conversion macro produces a single, identifiable change to the .s7p per block, which is easier to review than the per-character noise of a hand-edited source export.

Frequently Asked Questions