TIA Portal Check Block Consistency: Resolving Interface Errors

1. Overview

The Check Block Consistency function in Siemens STEP 7 (SIMATIC Manager) and TIA Portal is a maintenance operation that scans the offline program for time stamp conflicts and interface/pointer mismatches introduced by edits to function blocks (FBs), functions (FCs), data blocks (DBs), user-defined data types (UDTs), and the block interfaces they expose. It is a corrective tool, not a syntax compiler: it does not check grammar of ladder or STL code, it does not validate symbols against the global symbol table, and it does not download anything to the PLC. It rebuilds the internal cross-references and instance-DB offsets so that offline code matches the actual layout of the data it references.

The function is documented in the Siemens support knowledge base as a way to scan for inconsistencies caused by changes to interfaces and to rectify them, and it is described in the TIA Portal online help as a symbol-triggered action in the dependency structure that marks blocks found to be inconsistent with a status icon. See the official Siemens support article How do you perform a block-consistency check following changes in the STEP 7 program? and the TIA Portal V21 documentation page Checking block consistency in the dependency structure for the canonical procedure.

2. The Underlying Problem: Time Stamps and Interface Shifts

STEP 7 attaches two time stamps to every block in the offline program: a code time stamp (last edit to the block body or interface) and an interface time stamp (last edit to the FB/FC parameter table or to the UDT/DB layout it depends on). When block A calls block B, the interface time stamp of B at the time of A's last edit is stored inside A. At compile/download, STEP 7 compares the stored interface time stamp of B with the current interface time stamp of B. A mismatch is logged as a time stamp conflict and the affected call sites are flagged.

The same time stamp mechanism controls how multi-instance DBs and instance DBs reference the layout of their parent FB. If you add a new STATIC variable to FB100 between existing variables, every instance DB of FB100 has to be re-laid-out so the new variable gets a real memory slot. The block call sites that pass an instance-DB pointer have to know about the new layout. Without that re-layout, the offline view of dbMotor.Auto can point to DB40.dbx12.0 while the in-memory DB after the next download actually stores Auto at DB40.dbx14.0 because a new Speed was inserted above it. The source code still looks correct, the syntax highlighter does not show any red squiggles, but the program executes against the wrong addresses until a consistency pass rewrites the cross-references.

3. What Check Block Consistency Actually Does

The operation performs three classes of work in a single sweep:

1. Interface pointer regeneration. For every block A that calls block B (FC/FB call, instance-DB reference, UDT instantiation, access to a DB of user-defined type), the editor rewrites A's stored description of B's parameter signature and storage offsets using B's current interface.
2. Instance DB re-layout. For every instance DB belonging to an FB whose interface has changed, the variable image inside the DB is rebuilt so that STATIC offsets match the FB's current declaration order. Initial values defined in the FB are pushed into matching positions in the instance DB unless the user has overridden them locally.
3. Cross-reference reconciliation. The program structure cache (the dependency tree shown in the project tree and in the Program Information view) is rebuilt from the actual block contents. Inconsistent blocks are marked with a red status icon, and for blocks the routine can fix automatically, the cross-reference table is refreshed without prompting.

Where the routine cannot resolve a mismatch automatically (for example, an FC call that now has a parameter the caller has not supplied, or a symbolic name that was renamed and the call site still uses the old name), the editor drops the cursor at the offending call site so the programmer can make the manual decision.

4. What It Does NOT Do

Field engineers frequently confuse the consistency check with a compiler pass. The following are explicitly outside its scope:

5. When the Check Is Required

Run a consistency pass any time the offline program and the underlying data layout drift apart. Typical trigger events:

• A STATIC, INPUT, OUTPUT, IN_OUT, TEMP, or RETURN parameter was inserted, deleted, reordered, or had its data type changed in an FB or FC.
• A UDT component was added, removed, reordered, or retyped, and the UDT is used as a TEMP, STATIC, INPUT, OUTPUT, IN_OUT, or as the basis of a DB.
• Variables were added to, removed from, or reordered inside a shared/global DB, and the DB is accessed symbolically (or by absolute address with a comment) elsewhere in the program.
• An FB was re-instantiated and its multi-instance slot order changed.
• Blocks were copied from another project, or a library block was updated to a newer version, and the calling blocks predate the change.
• A mass operation (multi-instance DB restructuring, project-wide rename, mass declaration update) was performed by a tool such as the SCL source editor or by an external scripting tool.

6. Step-by-Step Procedure in Classic STEP 7 (SIMATIC Manager)

6.1 Prerequisites

• SIMATIC STEP 7 V5.x (V5.5 SP2 or later recommended) with the project open offline.
• Exclusive write access to the S7 program (no concurrent editor open on the same blocks).
• All FBs, FCs, DBs, UDTs and the symbol table accessible in the project tree.

6.2 Procedure

1. In SIMATIC Manager, select the S7 program or the Blocks folder that contains the changed blocks.
2. Right-click and choose Check Block Consistency from the context menu. Alternatively use menu Edit > Check Block Consistency.
3. The editor starts at the first block it cannot repair automatically and opens the block body at the offending statement. The status bar reports the reason for the conflict.
4. Correct the call site manually. Typical corrections:
   • Supply a missing parameter (EN, IN, OUT, IN_OUT) that the new interface requires.
   • Remove a parameter that the new interface no longer accepts.
   • Update an absolute address (e.g. DB40.dbx12.0) to the new symbolic reference, or rebind it to the new offset.
5. Close the block with File > Save and choose Yes when prompted to update the interface time stamp.
6. Repeat until the routine finishes without opening any editor. The final pass reports No inconsistencies found.

6.3 Verification

After the routine completes, perform the following checks before any download:

• Re-open each modified instance DB and confirm the variable layout matches the FB declaration.
• Open Options > Reference Data > Display and verify that the cross-reference list shows the updated symbol/address pairs.
• Compile the program (Edit > Compile or Program > Compile All) and confirm no errors are reported in the output window.

7. Step-by-Step Procedure in TIA Portal (V16 / V17 / V18 / V19 / V20 / V21)

7.1 Prerequisites

• TIA Portal with the project open offline; the PLC must be in No connection or the engineer must be working without a live online partner.
• Access to the Program blocks folder of the target PLC device.
• The optional S7-PLCSIM or actual S7-1200/S7-1500 target does not need to be online during the check.

7.2 Procedure (Dependency Structure View)

1. In the project tree, expand the target PLC and double-click Program blocks.
2. Click the Dependency structure tab in the work area. The dependency tree shows the call hierarchy of OB → FB/FC → DB/UDT.
3. Click the Consistency check symbol in the task bar of the dependency structure view (the icon with the red and green check marks). The TIA Portal documentation describes this action as: The block consistency is checked. Blocks found to be inconsistent are marked accordingly by a symbol.
4. If the routine finds no automatic fix, it opens each offending block in its editor at the problematic statement. The status bar shows the conflict reason (for example Interface time stamp of called block is newer than the calling block's).
5. Apply the manual correction, save the block with Ctrl+S, and confirm any prompt to update the interface time stamp.
6. Repeat until the consistency check finishes without flagging any block.

7.3 Procedure (Program Editor Right-Click)

1. Right-click the Program blocks folder in the project tree.
2. Select Compile > Software (rebuild all blocks) to perform a full rebuild, or use the targeted Check consistency action where available.
3. Open the Inspector > Info pane and review the Compile tab for any errors or warnings related to interface or time stamp mismatches.

8. Working with the Dependency Structure

The dependency structure is the single best diagnostic surface for consistency work because it shows the exact call paths that are out of date. Each block is drawn as a node; arrows point from caller to callee. After a check, the following node icons appear:

Right-click a red node and choose Go to fault to jump straight to the offending statement inside the block editor. This is the fastest way to clear large inconsistency lists.

9. Common Inconsistency Types and Field-Proven Fixes

10. Automatic vs Manual Correction

The Siemens documentation describes the operation as one that removes a large part of all time stamp conflicts and block inconsistencies but in the case of objects whose block inconsistencies could not be eliminated automatically, the function places you at the position to be changed in the corresponding editor, where you can carry out the required changes. Empirically the auto-fix rate is high for purely structural changes (added/reordered STATICs, widened data types) and low for semantic changes (renamed symbols, removed parameters, changed data type of a variable that requires manual initial-value conversion).

When you reach a manual fix prompt, follow this decision tree:

1. Missing parameter: read the new interface description in the Inspector > Properties > Interface tab and supply a literal, tag, or empty string.
2. Surplus parameter: confirm the parameter is no longer used, then delete it from the call site.
3. Type change: convert or cast the supplied value to the new data type. For BOOL → INT or INT → REAL conversions, use explicit conversion functions in SCL/STL.
4. Renamed symbol: open the cross-reference on the old name, jump to each call site, and replace the old name with the new one. Do not rely on the consistency check to do this for you.

11. Multi-User / TIA Portal Multiuser Server Considerations

In a TIA Portal Multiuser Server setup, the consistency check should be performed on a local session copy after all pending check-ins. Running the check against the server session while other engineers have locks on related blocks can produce transient "block cannot be opened" errors. The recommended workflow is:

1. Sync the local session with the server.
2. Resolve all open check-in/check-out conflicts.
3. Run Check Block Consistency on the local session.
4. Run a full compile of the program.
5. Check in the changes with a descriptive comment naming the FB/UDT that triggered the sweep.

For projects that use a version control system (TortoiseSVN, Git via the TIA Portal VCS provider), the consistency check should be part of the pre-commit hook so that a broken offline state cannot be checked into the trunk.

12. Verification and Best Practices

1. After every interface change, perform Check Block Consistency before doing any other work in the project.
2. Prefer symbolic over absolute DB addressing; it is the only way to get the editor to track offsets for you.
3. Use UDTs as the single source of truth for recurring data structures (motor records, recipe records, axis records). A UDT change propagates through every DB of that type in one consistency pass.
4. When upgrading a library FB, copy the new version into the project, open every instance DB once, run the consistency check, and verify that the Initial Value column still reflects what the field requires.
5. Document the manual fixes you apply. A consistency prompt that says supply a value for parameter X is a hint that the calling block did not know about X at the time of its last edit; the surrounding context (alarm handling, mode handling, safety gating) determines the correct value.
6. Before downloading to the PLC, always follow the consistency check with a full compile and a review of the Inspector > Info > Compile tab.

13. Troubleshooting Matrix