Resolving STEP 7 Multiple Instance FB Timestamp Conflicts

Overview

Symptom: In SIMATIC STEP 7 V5.x (target S7-300 / S7-400 / WinAC), a multi-instance Function Block (FB) repeatedly reports a timestamp conflict when opened online, the offline/online comparison shows different interface timestamps, or Check Block Consistency terminates with errors such as SF:0300 / 33:15402 after a User-Defined Type (UDT) used inside the FB has been modified. The block does not download; the instance DB (DBi) appears incorrect in the cross-reference list, and any caller of the FB that uses the changed UDT as IN, OUT, IN_OUT, STAT, or TEMP variable refuses to compile.

This article documents the exact mechanism behind the fault, the canonical Siemens resolution path (Update Block Call + Check and Update Accesses + Check Block Consistency), and the lesser-known variants required when the FB is a multi-instance block or when the UDT itself was edited through the S7-Program path. All references point to Siemens Industry Online Support and to the original STEP 7 V5.5 manuals. The classic STEP 7 V5.x tool chain is used throughout (not TIA Portal).

Root Cause Analysis

STEP 7 stamps every FB, FB instance DB, and every block that calls an FB with an interface timestamp. The timestamp encodes the structural fingerprint of the block's parameter signature (IN / OUT / IN_OUT / STAT / TEMP) including the names, types, and offsets of every declared element. When the called block's signature changes, the caller's timestamp no longer matches and STEP 7 marks the relationship timestamp-invalid.

The most frequent triggers in a multi-instance FB context are:

1. UDT modification after FB compilation. You opened the UDT, added or removed a member, renamed a member, or changed a member's data type, and saved it. The FB that uses the UDT (as a STAT variable of type UDTxxx) still carries the old UDT fingerprint, as does every instance DB allocated from that FB.
2. FB used as a multi-instance without the multi-instance capability bit being set in the FB properties. When that bit changes, all parent FBs that hold this FB as a static instance become timestamp-invalid.
3. UDT used in the FB's interface (IN / OUT / IN_OUT) rather than only in STAT. Renaming or restructuring the UDT changes the formal parameter signature directly.
4. Library re-import of an FB at a newer version than the version compiled into the active S7 program. The block header is replaced, but caller FBs / OB1 / OB35 retain the old timestamp until updated.

STEP 7 surfaces the conflict through the diagnostic buffer entry "Block inconsistency / time stamp conflict" and through the block icon in SIMATIC Manager — a small yellow triangle indicates interface time stamp differs. The CPU will refuse to download a block whose instance DB has not been regenerated; if you force the download, the instance DB is reset to its initial values, which is normally unacceptable in a running process.

Multi-Instance FBs: When the Symptom Appears

A multi-instance FB is an FB declared as a STAT variable inside another FB. The parent FB owns the instance memory of the child FB; no separate instance DB is generated for the child. This requires the child FB to be marked "Multi-instance capable" (German: Multiinstanz-fähig) in the FB properties dialog (Block → Properties → Attributes).

The multi-instance attribute itself is part of the FB signature. If you change the attribute after the FB has already been used as a multi-instance somewhere in the project, every parent FB is invalidated. Conversely, if you disable the multi-instance attribute after some parent FB has been compiled against it, the parent loses its child instance and the previously-generated instance memory is orphaned.

Symptoms and Diagnostic Buffer Entries

Common diagnostic buffer and STEP 7 message window entries when this fault is present:

Open the diagnostic buffer with PLC → Diagnostic/Setting → Diagnostic Buffer (or in STEP 7 V5.5: PLC → Diagnostics/Settings → Module Information). Read the Event ID, then click Open Block in the event details to jump straight to the offending FB.

Prerequisites for Recovery

Before you start, ensure the following. Skipping any of these typically turns a clean recovery into a corrupted-instance-DB download.

1. Backup the S7 program: File → Save As… the entire S7 project, then File → Archive… the .s7p file. Keep the archive before any recompile operation.
2. Confirm the offline PG/PC source. The STEP 7 project on disk is the only source of truth. If you have parallel projects (office PG, plant PG, engineering station), decide which one is authoritative.
3. Identify the changed UDT. Open SIMATIC Manager → S7 Program → Blocks → System Data → UDTs. Compare member lists against the version in the offline program. Look at the Last modified column or right-click → Object Properties → History if the project has version history enabled.
4. Identify every caller. Use Options → Reference Data → Display and search for the UDT and the affected FB. Cross-references tell you which FBs / OBs / DBs use the UDT or call the FB.
5. Stop the CPU if the affected block controls a live process. Some of the steps below cannot be performed while the CPU is in RUN with active process I/O.

Step-by-Step Resolution

Step 1 - Identify all blocks in the timestamp chain

In SIMATIC Manager, right-click the Blocks folder and choose Check Block Consistency (German: Bausteinkonsistenz prüfen). STEP 7 builds a list of blocks whose timestamps do not match their callers. Note the chain: typically the order is

UDTxxx (modified) → FB410 (uses UDTxxx) → FB400 (calls FB410 as multi-instance) → OB1 / OB35 (calls FB400)

Each link must be recompiled in the order UDT first, then FB410, then FB400, then the OBs. Do not skip links.

Step 2 - Recompile the UDT

1. Open the UDT block (double-click UDTxxx).
2. Confirm the new structure is what you want.
3. Save with File → Save (Ctrl+S). This refreshes the UDT's interface timestamp.

Step 3 - Recompile the FB that uses the UDT

1. Open the FB (e.g. FB410) by double-click.
2. If STEP 7 prompts "The block interface has changed. Update interface?" click Yes. This propagates the new UDT definition into the FB's STAT, IN, OUT, or IN_OUT members.
3. If the prompt does not appear, force a manual refresh: open the declaration table, place the cursor on the UDT-typed variable, press F5 (Update) or right-click → Update Declaration.
4. File → Save, then File → Compile (Ctrl+B). Confirm the compile log shows no errors.

Step 4 - Update Block Call for every caller

For every FB, OB, or other block that calls the affected FB:

1. Open the calling block in LAD/FBD/STL editor.
2. Right-click the call box (or instance DB reference) and choose Update Block Call (German: Bausteinaufruf aktualisieren). STEP 7 updates the formal-parameter view to match the new interface.
3. Repeat for every call site. The cross-reference list from Step 1 gives you the exhaustive list.

If the calling block is a multi-instance parent, also perform Step 4 recursively on the parent.

Step 5 - Run Check and Update Accesses

This is the menu-driven equivalent and often catches call sites you missed by hand.

1. Open the LAD/STL/FBD editor on the calling block.
2. Choose File → Check and Update Accesses (German: Datei → Zugriffe prüfen und aktualisieren).
3. STEP 7 scans every variable access in the block. Variables that no longer exist (because the UDT member was removed or renamed) are reported. Variables whose type has changed are flagged.
4. Confirm each prompt: Yes - All for routine updates, No only when you have a known reason to keep a symbolic access even if its type drifted (rare and dangerous).

Step 6 - Regenerate the instance DB

The instance DB (e.g. DB410) was generated from the previous FB interface. It must be regenerated against the new interface.

1. In SIMATIC Manager, select the instance DB.
2. Right-click → Generate Instance DB (only available for the FB used as single-instance). For multi-instance usage, skip this - the instance memory is part of the parent's instance DB and will be updated when you recompile the parent.
3. For single-instance DBs, STEP 7 offers three regeneration modes in the dialog that follows. Choose based on process risk:

For multi-instance FBs, regeneration happens automatically inside the parent's instance DB when you recompile the parent FB.

Step 7 - Re-run Check Block Consistency until clean

1. Right-click the Blocks folder → Check Block Consistency again.
2. The result must show "No inconsistencies found" for the affected chain. If any block remains red, repeat Steps 3-5 on it.
3. Save the entire S7 program: File → Save (Ctrl+S) on the S7 program node.

Step 8 - Download blocks to the CPU

1. Switch the CPU to STOP if the affected code path is process-critical.
2. In SIMATIC Manager, select the Blocks folder.
3. Choose PLC → Download. Confirm when prompted.
4. If STEP 7 reports "Instance DB must be regenerated", click Yes to accept the regeneration rule from Step 6.
5. Switch back to RUN after the download completes.

Alternative Recovery: Re-importing the FB from a Library

When the project is so tangled that recursive timestamp chasing fails, replace the affected FB from a known-good master copy:

1. Identify the master copy (often in a vendor library or a version-controlled archive).
2. In SIMATIC Manager, right-click the project → Libraries, then Open Library or Create New Library.
3. Drag-and-drop the FB from the library onto the Blocks folder. Choose Overwrite.
4. Run Check Block Consistency on the S7 program and update every caller as in Steps 4-7.

This path loses any in-FB code edits you made locally. Diff the FB in a version-control tool before overwriting if local changes exist.

Verification Procedure

Run all checks below in order. A clean run confirms the recovery.

1. Offline consistency: Blocks → Check Block Consistency → no errors.
2. Online timestamp match: Right-click each affected block → Compare Offline/Online → "Identical" in the dialog. The interface timestamp must match.
3. Diagnostic buffer: PLC → Diagnostics/Settings → Module Information → Diagnostic Buffer. After CPU restart the most recent stop cause should not be 4300 or 3314. If a stop cause remains, clear with Clear/Reset only after confirming with operations.
4. Cross-reference sanity: Options → Reference Data → Display → search for the UDT. Every occurrence must show the new member set.
5. Watch table spot-check: Open Watch Table with the affected instance DB. Toggle a UDT member, then confirm the value updates online (open VAT, insert/force, monitor with Monitor/Modify). This proves the FB reads the new interface at runtime.
6. Force/IO test (if safe): Briefly force an input tied to a new UDT member and confirm the program branch executes as designed. Remove the force afterwards.

Edge Cases and Common Pitfalls

UDT edited, FB recompiled, but parent FB forgotten

Symptom: Check Block Consistency marks the child FB green but the parent FB red. Cause: the parent holds the child as a multi-instance and still references the old FB signature. Fix: recompile the parent and regenerate its instance DB.

UDT used in TEMP of the FB

TEMP variables are re-initialized on each call; changes do not affect instance DBs. However, the FB interface timestamp still drifts, so callers must still be updated.

UDT used in multiple FBs

Step 1's cross-reference may show 20+ callers. Update each one. Consider exporting the Blocks folder with the Export to Text tool (in STEP 7 V5.5: File → Export…) to keep a snapshot before bulk recompile.

Library FB re-import overrides the project FB

When the imported FB is older than the in-project FB, the in-project FB is overwritten downward. Compare version dates with Block → Properties → History before importing.

SFC / SFB uses the UDT

If a System Function Block (e.g. SFB47, SFB52) references the UDT, you cannot recompile it. SFCs/SFBs are firmware-resident. Move the UDT out of the SFB's input scope or change your application logic so the SFB does not depend on the changed UDT members.

S7-PLCSIM vs. real CPU

PLCSIM ignores timestamp mismatches at download time and accepts the block. This hides bugs that the real CPU will reject. Always verify the fix on the target CPU or on PLCSIM with Check Block Consistency turned on.

TIA Portal migration

If the project is migrated to TIA Portal before the timestamp chain is fixed, the migrated project carries the same signature drift. Run Check Block Consistency in the STEP 7 V5.x project first, then migrate.

Parameter Reference

Reference Documentation

The following official Siemens Industry Online Support entries document the topics used in this article:

• STEP 7 V5.5 Programming and Operating Manual — block types, UDTs, and the FBD / LAD / STL editors.
• How do you avoid time stamp conflicts in STEP 7 V5.x? — Siemens FAQ explaining the timestamp mechanism.
• "Check Block Consistency" in STEP 7 V5.x — usage and interpretation of the consistency check.
• S7-300 Programmable Controller, CPU 31xC and CPU 31x: Technical specifications — multi-instance capability per CPU type.
• STEP 7 V5.5 Reference: LAD/FBD/STL editor — Update Block Call, Check and Update Accesses.

FAQ