Restoring S7-300 IDB Variable Names Replaced by STAT## and TEMP## in STEP 7 V5.6

When instance data blocks (IDBs) in a STEP 7 V5.6 SP1 project for the S7-300 family lose their descriptive variable names and show placeholder strings such as STAT_1, STAT_2, TEMP_1, and TEMP_2, the symptom is almost always a mismatch between the offline FB interface and the actual block downloaded to the CPU. This document explains the root cause, the field-proven recovery path, and the engineering practices that prevent recurrence. It also covers migration considerations when porting the recovered project to TIA Portal.

1. Problem Description

After a field engineer or programmer modifies the interface of a function block (FB) — typically by adding, removing, renaming, or retyping a local variable — and downloads the modified FB to the CPU, the associated instance data blocks (IDBs) in the offline project may show:

• All STAT variables replaced with names like STAT_1, STAT_2, STAT_3.
• All TEMP variables replaced with names like TEMP_1, TEMP_2, TEMP_3.

The IN, OUT, and IN_OUT sections usually retain their original names because they map to the parameter area that the CPU preserves across block versions. STAT and TEMP names are stored only in the offline project; the PLC stores the values, not the symbols. The placeholder names indicate that the FB's interface definition in the offline project no longer matches the FB that was downloaded and is now running on the CPU. STEP 7 cannot reconcile the symbol table and reverts to generated names.

2. Root Cause

STEP 7 V5.6 generates an instance data block from the interface declaration of its parent FB. When the FB interface is edited, STEP 7 updates the matching IDB on the next compile or download. If the engineer:

1. Edits the FB interface (adds a STAT variable, changes a name, reorders the list, or changes a data type),
2. Saves the FB locally,
3. Downloads only the FB to the CPU,
4. Does not regenerate or re-download the IDB,

the IDB on the CPU still uses the old interface version. The next time the offline project is opened, STEP 7 cannot match the new interface to the old IDB and substitutes STAT## / TEMP## placeholders. The same happens if the FB on the CPU was hand-edited online or replaced from a different project revision.

A second common trigger is opening a project whose FB is from one software revision while the downloaded CPU block is from another. The Block Consistency check in SIMATIC Manager — accessible via Program > Check Block Consistency — exists precisely to flag this state. The dialog may show an Interface description missing or FB/DB inconsistent status, which is the same defect viewed from a different angle.

3. Affected Products, Firmware, and Software

The S7-300 line reached end of active sales on 1 October 2023 per the official Siemens product announcement, but remains covered by spare-part and repair programs through 2033. STEP 7 V5.6 SP1 is therefore still the correct tool for S7-300 service work. New TIA Portal projects cannot read V5.x databases directly; they require the TIA Portal migration tool described in Section 10.

4. Diagnostic Verification

Before attempting any recovery, confirm the diagnosis with the following sequence. Run all checks against a backup of the offline project, not the live one. The full STEP 7 V5.6 SP1 reference is available in the Siemens Industry Online Support documentation portal.

1. Open the offline project in STEP 7 V5.6 SP1 and navigate to the S7 program. Right-click the Blocks container and select Check Block Consistency. STEP 7 lists the offending FB/IDB pair with the status Interface mismatch or Different time stamps.
2. Cross-view the online and offline FBs. In SIMATIC Manager, select the FB, right-click, and choose Compare Blocks Online/Offline. The Interface tab highlights every changed IN/OUT/STAT/TEMP entry. The data type and position columns are the matching keys; names differ only in the offline project.
3. Read the system data block (SDB) from the CPU. The SDB contains the CPU's view of all block interfaces. Choose PLC > Upload Station to PG to read a fresh offline image. The placeholder names appear only on the side that is out of date.
4. Check the block timestamp in PLC > Module Information > Diagnostic Buffer. The Last download of user program entry confirms when the FB on the CPU was last written. The offline FB shows a different code timestamp in Block Properties > Time Stamps.
5. Inspect the symbol table (Options > Symbol Table). Placeholders appear in red tint. A short filter on STAT_ and TEMP_ lists every affected symbol.

5. Recovery Procedure (Step-by-Step)

The following is the field-proven recovery path for a single S7-300 station with one or more affected IDBs. It assumes the live CPU is the authoritative source of code (the program currently running on the machine) and the older backup project is the authoritative source of symbol names.

Prerequisites

• STEP 7 V5.6 SP1 installed on the programming device.
• MPI/Profibus cable or Ethernet (PN CPU) connection to the CPU.
• Online access to the CPU's user program (password if set).
• An older, name-complete copy of the project (read-only is fine).
• A clean working directory for the merged project.

Procedure

1. Archive both projects. In SIMATIC Manager, use File > Archive on the live project and the older project. Use the No recreation option. Keep the archives on a separate drive.
2. Upload the live program. In the live project, connect to the target CPU. From PLC > Upload Station to PG, read all blocks. This gives you an exact online image with current timestamps.
3. Open the older project containing the original IDB names. Locate the affected FB in its S7 program. The FB's interface holds the user-defined variable names.
4. Export the older FB. Right-click the FB, choose Generate Source (or Export), and save it as a standalone .AWL source file. Repeat for any user-defined types (UDTs) and any FCs the FB calls.
5. Import the FB into the uploaded project. In the uploaded project's Blocks container, use Insert > External Source File, then compile it with Source > Compile. STEP 7 regenerates the FB with the original interface. The compiler warns that the FB's code timestamp differs from the CPU — accept it; you want the interface only.
6. Regenerate the IDB. Right-click the IDB and select Generate Instance DB. The new IDB inherits the corrected interface and replaces the placeholder names with the original symbols. STEP 7 warns that the current IDB will be overwritten — confirm.
7. Repeat for every affected FB/IDB pair. Work one block at a time; do not batch-replace FBs because cross-references in FC calls and DB accesses will break.
8. Re-download the corrected blocks. Select the FBs and the newly generated IDBs, then choose PLC > Download. The CPU accepts only what has changed.
9. Re-run Block Consistency. The check must return No errors before commissioning resumes.

6. Manual Name Reconciliation (When the FB Code Has Diverged)

If the FB code itself has been changed since the older project was archived — for example, logic was added to handle a new sensor — the procedure in Section 5 will overwrite the live logic. In that case, perform a manual name reconciliation instead.

1. Open both FBs side by side. In the live project, open the FB; in the older project, open the same FB. Use Window > Arrange > Tile Vertically.
2. Switch both to the Interface tab.
3. For each placeholder in the live FB (e.g., STAT_5), locate the matching symbol in the older FB. Match by data type and position. The order in the interface must match.
4. Edit the live FB's interface: change STAT_5 back to its original name (e.g., MotorRPM). Save the FB with Ctrl+S.
5. STEP 7 prompts to update dependent blocks. Click Yes. The IDB regenerates with the correct names; the FB's code (logic) is preserved.
6. Recompile the entire S7 program via Program > Compile All. Watch the output window for unresolved references.
7. Download the regenerated IDB and the updated FB. Verify with Check Block Consistency.

7. Cross-Project Merge Strategy

For projects that have diverged for weeks or months, a structured merge is more reliable than per-block transfers. The workflow below scales to multi-station S7-300 fleets and limits the risk of a partial migration. The merge assumes the live CPU code is authoritative for behavior and the older project is authoritative for symbols.

8. Verification and Commissioning

After recovery, verify the result with a multi-layer check. Do not hand the machine back to production on the strength of a single green light.

• Block consistency check. Program > Check Block Consistency must report No errors; the run-time must show 0 warnings.
• Symbol table review. Open the Symbol Editor (Options > Symbol Table) and confirm every STAT and TEMP variable has a non-default name. Placeholders are visible in the symbol table as a red-tinted cell.
• Watch table test. Open the IDB in Monitor/Modify mode (online view). Modify a STAT variable, force a value, and confirm the value updates the running program. If the variable is read-only (e.g., a calculated speed), force a neighbouring input instead and verify the calculation.
• Cross-reference check. Press F11 in the FB and confirm each restored name is referenced from at least one call site. An unreferenced name hints that the merge missed a duplicate.
• Diagnostic buffer sweep. PLC > Module Information > Diagnostic Buffer must be free of OB121 (programming error), OB85 (communication fault), and OB122 (I/O access error) entries after the test cycle.
• Sign-off. Document the merged project name, the archive paths, the engineer, and the date in the project's revision log. The next engineer needs this audit trail.
• Backup. Archive the merged, validated project immediately. The first archive after a recovery is the highest-value backup in the lifecycle of the project.

9. Prevention: Program Change Discipline

The placeholder issue is a symptom of missing change control. The practices below have proven effective in plants with 30+ S7-300 stations.

1. One project, one source of truth. Store the live project in a versioned repository (SVN, Git, or the TIA Portal Project Server for TIA projects). For STEP 7 V5.x, the project backup ZIP is the smallest atomic unit. Archive after every change.
2. Mandatory compile-all after FB edits. A change to an FB's interface must be followed by Program > Compile All. This regenerates the dependent IDBs and the compiler emits a warning that forces a deliberate click on OK. It is the cheapest insurance against placeholders.
3. Never download FBs in isolation. Use PLC > Download on the entire selected block set, including the matching IDBs. STEP 7 will not silently regenerate the IDB unless both are selected.
4. Read-modify-write on the CPU. If the engineer must edit an FB online, follow with an immediate upload of the block, an offline recompile, and a redownload of the IDB. Online edits bypass the offline project and create exactly this placeholder scenario.
5. Interface audit at handover. A standing rule: at the end of every shift, the on-duty engineer runs Check Block Consistency on the live project. A 30-second check that prevents a 30-hour recovery.
6. Block-naming standard. Reserve _B suffix for FBs, _DB for instance DBs, _I for input symbols, _O for outputs. A glance at a call site tells the engineer what kind of block it is.
7. Document interface changes. Maintain a change log that records every interface addition or rename. When a placeholder appears, the log is the first place to look for the previous name.

10. Migration to TIA Portal

For plants planning to retire S7-300 stations, the recovered V5.6 project must be migrated to TIA Portal before TIA can read it. The TIA Portal migration tool ships with every TIA installation. The migration path for a placeholder-fixed project is cleaner than for a project that still shows inconsistencies: the tool checks each FB/IDB pair, and a clean interface migrates without the duplicate-symbol warnings that plague inconsistent projects.

For S7-300 → S7-1500 station upgrades, refer to the SIMATIC S7-1500 / ET 200MP Manual Collection for the target CPU's block interface rules. The TIA Portal compiler detects and reports interface drift the moment the migrated FB is opened, which is a stronger safeguard than the V5.x consistency check.

Target CPU candidates for S7-300 replacement include the S7-1500 CPU 1511-1 PN, CPU 1513-1 PN, CPU 1515-2 PN, and CPU 1518-4 PN/DP. These CPUs support the same FB/IDB semantics and accept migrated block pairs without conversion. Engineering teams should plan the migration during a scheduled shutdown to allow the full block consistency and OB-startup verification cycle.

11. Frequently Asked Questions