Resolving Missing System Parameters in Siemens S7 Function Blocks

Problem Summary

When a Siemens S7-300/400 CPU program is uploaded to a programming device (PG) and compared against a backup project supplied by the machine builder, engineers frequently encounter a Step 7 dialog reporting that system parameters are missing, that block interface variables are missing, or that the interface is not current. After the warning is acknowledged with OK, called function blocks (FBs) and functions (FCs) open without their symbolic names, IN/OUT/STAT declarations, or local comment text. Cross-references from higher-level blocks show red (invalid) tag names, and online monitoring cannot resolve symbols to absolute addresses.

This behavior is not a corruption of the PLC program — the CPU is running correctly. The issue is a mismatch between the offline project on the PG and the online project inside the CPU, specifically in the block interface section that Step 7 calls the system parameters of the block (also referenced as the block header or interface description). This article documents the root cause, the architectural distinction between the symbol table and the block interface, and the field-proven procedures used to restore full readability in SIMATIC Step 7 V5.x and STEP 7 Professional (TIA Portal) for the S7-300/400 family.

Root Cause Analysis

Two artifacts hold the symbolic information that an engineer expects to see in a called block:

1. Block interface (system parameters) — stored inside the FB/FC block itself. For an FB this includes the INPUT, OUTPUT, IN_OUT, STATIC, and TEMP variable declarations together with their data types, initial values, and variable comments. For an FC the interface is limited to INPUT, OUTPUT, IN_OUT, and TEMP.
2. Symbol table — a separate .sdf file in the S7 program that maps symbolic names to absolute addresses (e.g. Motor_Start ↔ I 0.0). The symbol table is the only place where global symbolic I/O names live.

When a backup project is supplied by a machine builder, both files must be present and consistent with the compiled blocks. The conditions that produce the "system parameters missing" dialog are:

The local interface of an FB is part of the block — it travels with the FB inside the PLC. The symbolic names of absolute addresses used inside the FB body, however, are resolved through the symbol table and will appear as raw operand syntax (IW 4, DB5.DBD8) when the symbol table is missing or out of sync.

Understanding the Block Interface in Step 7

An FB/FC interface is structured into five sections (four for FCs). Each section may carry a symbol, a data type, an initial value, and a comment. The combination of these is what makes the block readable:

The interface is preserved across the upload operation (PG → PLC blocks are read into the offline project with their full interface). What is not preserved across an upload is the block title, block comment, network titles, and network comments. Those elements live in the STL/SCL source file inside the Sources container and are not stored in the CPU.

What Step 7 Calls "System Parameters"

In a Siemens S7-300/400 context, the phrase system parameters has three distinct meanings depending on the dialog that produces it:

• Block-level system parameters — the VAR_INPUT/OUTPUT/IN_OUT/STAT/TEMP declarations described above. Generated when the offline FB is opened and the online FB signature differs.
• CPU system parameters — configured in HW Config under Properties > CPU > Diagnostics/Clock/Memory/Protection. Stored in System Data Blocks (SDBs).
• Module system parameters — per-slot configuration (analog scaling, digital input debounce, etc.), also in SDBs.

When the dialog appears while opening a single block, it is the first meaning (block-level) that applies. The other two are addressed through HW Config and are not the cause of a missing interface in a called FB.

Symbol Table vs. Block Interface

A common confusion is to assume that copying the symbol table from the machine builder backup into the upload project will restore the missing comments and variable names in called blocks. It will not, because:

1. The symbol table contains only global I/O, flag, timer, counter, and DB-address names. It is consumed by the STL/SCL editor and by the symbol display column of the LAD/FBD editor.
2. The block interface is part of the compiled FB/FC binary. Its names, data types, and comments are stored inside the block object itself, not in the symbol table.
3. The comments shown in the variable declaration table (Comment column) and the network title/comment areas are stored in the source STL/SCL file, not in the compiled block.

Restoring a complete, readable project therefore requires three separate artifacts:

1. The Blocks container (FB, FC, OB, DB, SDB, SFB, SFC) — obtained from the CPU via PLC > Upload Station to PG.
2. The Symbols object — the Symbols editor entry. If missing, the project will compile and run but all global operands will be shown as IWxxx / MWxxx / DBx.DBBy.
3. The Sources container — the STL/SCL source file (or files). If present, a recompile restores every block title, block comment, network title, and network comment.

Prerequisites

Before starting the recovery procedure, confirm the following are available on the engineering station:

1. Step 7 V5.5 SPx or later, with the matching Hardware Support Package (HSP) for any newer IM/CP/FM modules. See the HSP update list.
2. The original machine builder backup project (S7 project archive or *.s7p container with all subfolders).
3. A working online connection (MPI/Profibus/PROFINET) to the CPU, or an offline topology of the network for the upload path.
4. PG/PC interface set correctly (PG/PC Interface applet in Control Panel — setpoint interface must match the physical adapter, e.g. TCP/IP → <adapter> → ISO-on-TCP).
5. CPU password, if one is configured. The Password field is under HW Config > CPU Properties > Protection.

Step-by-Step Recovery Procedure A: Compare Online vs. Offline

Use this method when the offline project from the machine builder exists, is openable in Step 7, and the goal is to reconcile differences rather than discard one of the two projects.

1. Open the machine builder backup project in SIMATIC Manager. Note the target CPU order number (MLFB) and firmware version in the project tree.
2. Connect to the CPU: PLC > Display Accessible Nodes, double-click the target CPU, then PLC > Upload Station to PG. Step 7 will prompt for a target directory; choose a new, empty folder so the existing backup is not overwritten.
3. Open the uploaded project in a second SIMATIC Manager instance. Verify the block list under S7 Program > Blocks matches the backup at the block-level. Use the right-click Object Properties > Block tab to inspect Last modified and Author for the FBs that show the missing-interface symptom.
4. Run the online/offline comparison: in the backup project, select Options > Compare Blocks (Online/Offline). Step 7 color-codes each block:
   • Green — identical
   • Red — online ≠ offline
   • Black with white background — missing in online
   • White with black background — missing in offline
5. For each red FBs where the interface differs, open the offline FB in the backup project, accept the prompt to update the call interface, and save the block. The interface is then re-aligned to the online version. If the offline FB is the one that is correct (e.g. the CPU is running an older revision), open the online FB and copy it over the offline one using Edit > Copy in the online view and Edit > Paste in the offline view.
6. Download the corrected blocks back to the CPU: select the affected FBs and choose PLC > Download. Stop the CPU first if the block contains an interface change that requires a STOP transition (most S7-300 CPUs allow online block replacement of FBs in RUN with caveats).

Step-by-Step Recovery Procedure B: Block Copy with Interface Preservation

Use this method when the only artifact available is the uploaded project, but the original STL/SCL source archive is missing. The interface is preserved; comments are not.

1. In the uploaded project, open the affected FB in the LAD/FBD/STL editor. The interface table at the top of the editor should be fully populated — that is the authoritative local-variable list.
2. Open a second SIMATIC Manager instance pointing to the backup project. Locate the same FB in the backup Blocks container.
3. Drag the FB from the uploaded project onto the backup project's Blocks folder. When prompted, choose Overwrite. Step 7 will keep the backup's project environment (HW Config, symbol table, sources) and refresh the block object with the online-consistent interface.
4. Open the block in the backup project. The local interface table should now match the online project. Symbolic names for global operands used inside the block body (e.g. I 0.0) are resolved from the backup's symbol table.
5. If the block uses a multi-instance or a dedicated instance DB, verify the instance DB by selecting it and choosing Edit > Initialize Instance DB. The DB structure must match the FB interface or online monitoring will fail with "Instance DB inconsistent".

Step-by-Step Recovery Procedure C: Manual Variable Restoration

Use this method when the interface in the offline project is intact but the variable comments are missing (e.g. a stripped STL file was used). The block logic and structure remain; only the documentation layer is rebuilt.

1. Open the affected FB. In the variable declaration table, locate the rows that have a name and data type but no comment. These are the variables for which comments must be re-entered.
2. Cross-reference against the machine builder documentation (functional specification, signal list, or HMI tag list). For each variable, enter the comment in the Comment column of the declaration table.
3. For network-level comments, scroll through each network in the FB body. The Title and Comment fields are right above each network. If those fields are empty, copy them from the source STL/SCL file (when available) or re-author them based on the rung logic.
4. Save the block. Step 7 will recompile and update the block checksum. Download to the CPU if the block was changed in any way that affects the compiled code — in this case (comments only), the downloaded binary is identical and no CPU STOP is required.

Handling the Symbol Table

The symbol table is restored separately from the block objects. The standard recovery path is:

1. In the backup project, locate S7 Program > Symbols. Double-click to open the symbol editor.
2. Select all rows (Ctrl+A), copy (Ctrl+C).
3. Open the uploaded project, open its Symbols editor, and paste (Ctrl+V). Step 7 will merge by absolute address and prompt for conflicts (same absolute address, different symbol) — resolve by keeping the backup's symbol unless there is documented reason to do otherwise.
4. Save the symbol table. The next online monitor will resolve symbolic names throughout the project.

If the symbol table is missing entirely from the backup, the only authoritative source is the machine builder. Do not re-derive symbols from the HMI tag list or signal list — those typically lack the per-bit granularity required by FBs (e.g. Motor_Start at I 0.0 is a different absolute address from Motor_Status at I 0.1, but both share the same byte).

Working with Block Comments, Network Titles, and Source Files

Comments in Step 7 are organized in three layers, and each has a different storage location:

For full comment recovery, recompile from the source STL/SCL file:

1. Open the Sources container in the backup project. Locate <Block name>.AWL (STL) or <Block name>.SCL (SCL).
2. Double-click the source to open the source editor.
3. Select File > Compile (or File > Generate Block). Step 7 parses the source and overwrites the corresponding block in the Blocks container with full comments.
4. Verify by opening the generated block — the interface table, block header, and network titles should all show comments.

When the source is an SCL file, the Generate Block path is identical; the SCL compiler version must match (SCL V5.3 SPx for Step 7 V5.5, etc.). A version mismatch is reported as "Compiler error: incompatible SCL version" in the Compile Log window. The matching SCL package is delivered with Step 7 Professional and is documented in the S7-SCL V5.3 manual.

Verification Steps

After the recovery procedure, validate the project end-to-end before downloading back to the CPU:

1. Block consistency check: select the Blocks container and choose Edit > Check Block Consistency. Step 7 compiles every block, including all called FBs, and reports OK for each or an error list with line numbers for problems.
2. Online/offline comparison: re-run Options > Compare Blocks (Online/Offline). All blocks should appear in green; any red block indicates a remaining difference.
3. Online monitoring test: in the editor, click the Monitor (glasses) icon. Verify that global operands display their symbolic names (e.g. "Motor_Start") and that local operands in called FBs show their interface names with current values.
4. Cross-reference check: open Options > Reference Data > Display and inspect the program structure. The called FBs should appear with their symbolic name and instance DB reference.
5. Compile log review: in the source editor, recompile the source and read the Compile Log window. Any WARN or ERROR line is a candidate for further investigation.

Edge Cases and Field-Proven Caveats

TIA Portal Considerations for S7-300/400 Migration

Engineers maintaining S7-300/400 hardware but using STEP 7 Professional (TIA Portal) V16 or later face an analogous problem in a different shape. The relevant differences are:

• The TIA Portal Project tree > PLC > Program blocks > [FB] view stores the block title, version, author, and interface in a single XML-based file. Uploaded blocks retain the interface and comments because the project file is self-contained.
• Symbolic I/O is stored per PLC under PLC tags > Default tag table (formerly the symbol table) and per device in the Device view. Copying a tag table is done by drag-and-drop between PLCs.
• The Compare > Online/Offline toolbar action in TIA Portal produces a structured diff (added/removed/changed rows in the interface, code changes) and offers one-click Compile > Software (rebuild all) for the affected PLC.
• When migrating a Step 7 V5.x project to TIA Portal, the Migrate Project wizard transfers blocks, symbols, sources, and comments in a single pass. After migration, the comments in called blocks are intact because the migration imports the STL/SCL source if it is present in the V5.x project.

For an S7-300/400 program that is being maintained exclusively in TIA Portal, the Upload device to PG/PC operation preserves the block interface, comments, and the default tag table. The conditions that produce the missing-interface dialog in V5.x do not appear in TIA Portal because the project model does not separate the source from the compiled block — the compiled block is the project representation.

Preventive Measures

To prevent recurrence of the missing-system-parameters symptom in future service events, the following housekeeping is recommended:

1. Always archive the full project, including Sources. Use File > Archive > User-defined archive with the Retrieval option enabled. A typical misuse is to deliver only the Blocks folder — this is enough to run the PLC but not enough to recover comments.
2. Activate know-how protection with a written key register. Store F-block passwords in the same controlled location as the project archive. Without the password, even a perfect archive cannot restore comments to protected FBs.
3. Use the project comparison regularly. Schedule a quarterly online/offline comparison to detect unauthorized changes by maintenance contractors or operators. The Step 7 Compare Blocks (Online/Offline) function is the lowest-cost change-detection tool available.
4. Document the CPU firmware version in the project properties. A V5.x project opened against a CPU with a newer firmware (e.g. 6ES7 315-2EH14-0AB0 / V3.3) can still show interface mismatches if the firmware introduced a new instruction set. The MLFB and firmware version are printed on the CPU front panel; record them in the project notes.
5. Centralize the source archive. STL/SCL sources should be checked into the same version control system (e.g. SVN, Git, or Teamcenter) as the HMI project and the electrical drawings. This is the only way to guarantee a complete rebuild from a known-good baseline.

Frequently Asked Questions