Resolving STEP 7 Interface Change Error When Saving FC Blocks

1. Problem Overview: The "Interface Change" Warning in STEP 7

When a programmer working in SIMATIC STEP 7 (Classic V5.x) or STEP 7 (TIA Portal) creates a new FC (Function) or FB (Function Block), declares variables in its interface, and then attempts to save the block, the compiler/editor may surface a dialog box titled "Interface change" (German: Schnittstellenänderung). The dialog typically lists the parameters whose declaration has shifted and asks the engineer to confirm the update.

For engineers migrating from a DCS such as DeltaV, where function blocks are bound to a more rigid, versioned, and database-backed consistency model, the STEP 7 behaviour is sometimes interpreted as a hard error. In practice it is a consistency reminder: STEP 7 is warning that the block's interface signature has been altered and that any calling network, instance DB, or referenced type may now be out of date.

The warning also appears for FCs that have never been called, which surprises new users. Understanding why requires a closer look at how STEP 7 stores and compares block interfaces.

2. Root Cause: How STEP 7 Tracks Block Interfaces

Every FC and FB in a STEP 7 project carries an interface description that is stored both offline (in the S7 program on the engineering station) and online (in the CPU's load memory). The interface description contains:

• The parameter list (Name, Type, Initial Value, Comment)
• The section in which each parameter lives (INPUT, OUTPUT, IN_OUT, STATIC, TEMP)
• An interface time stamp (German: Schnittstellenzeitstempel) that STEP 7 uses to detect drift between the block source and any reference to it

When the block is saved, the offline interface is recompiled. The compiler compares the new time stamp against the time stamps of:

1. Every block call (the rectangle on the LAD/FBD/STL network that invokes the FC/FB)
2. Every instance DB associated with an FB
3. Every UDT (User-Defined Data Type) that the block's parameters are based on
4. Every type FB / master copy in the master data library, if the block was derived from one

If any of these references has a stale time stamp, the Interface change dialog is raised so the programmer can choose to update them all in a single pass. This is documented in the STEP 7 online help under "Working with blocks > Block interface time stamp" and in the SIMATIC S7-300/400 programming manual (see the STEP 7 V5.x documentation index).

3. Anatomy of a Block Interface

The interface of an FC/FB is split into five sections. Recognising which section was modified is the fastest way to decide whether the warning is dangerous or cosmetic.

Note that VAR_TEMP changes never trigger the prompt because TEMP variables are local to a single invocation and are not visible to callers or instance DBs. The STEP 7 manual explicitly states that "changes in the temporary variable area do not affect the block call."

4. Why the Warning Appears Even on a Brand-New FC

If a newly created FC has never been called, why does STEP 7 still raise the prompt? The answer is one of three reasons:

1. UDT or system data type binding. The FC's parameters were declared from a UDT (User-Defined Data Type) or from an SDT (System Data Type such as DATE_AND_TIME or BOOL array). Renaming the UDT, adding an element, or changing the SDT version invalidates the FC's interface signature.
2. Library / master copy link. The block was inserted from the Master Data Library and is still linked to the library type FB. Editing the local copy while the master copy exists creates a time-stamp conflict the editor reports as "interface change."
3. Watch / force table / cross-reference. STEP 7 keeps cross-references that point at the block's symbols. Adding a parameter whose symbol collides with an existing tag, or whose name matches a forced variable, can also re-trigger the consistency check.

If none of these conditions apply, the warning on a never-called FC is genuinely benign and can be acknowledged with OK. The block will save and download without side effects.

5. Decision Matrix: Ignore or Update?

6. Step-by-Step Resolution Procedure (STEP 7 V5.x)

Use the following procedure when an existing FC or FB has been modified and the Interface change dialog appears.

1. Save and close the changed block. Acknowledge the prompt. Do not press Cancel — cancelling discards the new interface.
2. Open SIMATIC Manager and select the program folder that contains the block callers. For an S7-300 the path is Project > S7 Program > Blocks; for S7-400 the same path applies inside the relevant CPU.
3. Select the menu path Edit > Check Block Consistency (German: Bearbeiten > Bausteinkonsistenz prüfen). All callers with a stale interface are marked.
4. Right-click the first red call rectangle on a LAD/FBD network and choose Update Block Call (German: Bausteinaufruf aktualisieren). This re-maps the new parameter list onto the existing call.
5. For STL networks, the update regenerates the call instruction. Verify that any literal values you had hard-coded (e.g. L 100 feeding an IN parameter) were preserved.
6. Repeat step 4 for every red call in every calling block. The check-block-consistency tool lists them, so you can navigate directly.
7. For FBs with instance DBs, right-click the instance DB and choose Update Instance (or use Generate Instance DB to rebuild it). Existing actual values for retained tags survive; new tags receive their initial values.
8. Save and compile the calling blocks (File > Save > Compile or Ctrl+F7).
9. Download to the target CPU. If a download error SF appears, the CPU is signalling that the runtime interface no longer matches the offline program. Re-run Check Block Consistency and re-download.

7. Resolution Procedure in TIA Portal (S7-1200 / S7-1500)

The same concept exists in STEP 7 (TIA Portal), but the menu paths and the underlying consistency mechanism differ.

1. Open the project in TIA Portal and expand Program blocks in the project tree.
2. Right-click the Program blocks folder and choose Compile > Software (rebuild all blocks). The portal performs an interface consistency pass.
3. If a block has an interface mismatch, the editor highlights the block in red in the project tree. Open the block and the calling block; the missing or extra pins are shown with a red exclamation mark.
4. On the calling block's network, right-click the call and choose Update interface. The portal re-maps the parameters automatically.
5. For multi-instance DBs, the portal updates them when the parent FB is recompiled. If the call is single-instance (an IEC-style FB with its own instance DB), the instance DB retains its values; only new variables are initialised.
6. Re-compile (Project > Compile all > Software and hardware) and download.

For S7-1500 CPUs, the additional Block interface version feature (introduced in TIA Portal V15) lets you add new parameters without invalidating existing callers. If you intend to extend a published FB over time, set the block's "Block interface: Version-compatible" property to True before declaring the new parameters. The portal then places new pins at the end of the interface and does not shift existing parameters. This is documented in the TIA Portal help under "Creating blocks and types".

8. Special Case: Multi-Instance and Type FBs

Two situations frequently trip up engineers new to STEP 7:

8.1 Multi-instance FBs

When an FB is called as a multi-instance inside another FB (parent FB), the parent's VAR section contains an instance-DB-like static structure for the child. If the child FB's interface changes, the parent's static layout must be regenerated. STEP 7 does this automatically when you compile the parent; the child call shows a red exclamation mark until you re-save the parent.

8.2 Type FBs in the Master Data Library

A Type FB (German: Typ-FB) in the Master Data Library acts as a versioning anchor. When you instantiate the type FB in your program, you receive a copy with its own instance DB. If you later edit the type FB in the library, every instance in every program that references it is flagged with an interface change. The official fix is:

1. Edit the type FB in the library.
2. Switch back to the S7 program and select Options > Master Data Library > Update Instance.
3. STEP 7 propagates the new interface to all instances and forces an instance-DB update on download.

9. UDT (User-Defined Data Type) Impact

When a block parameter is declared with TYPE UDTxxx, the block carries a dependency on that UDT. If a colleague renames a UDT element or changes its data type in another part of the project, the next compile of the FC/FB will surface the interface change dialog. The compile log lists the affected blocks. The fix path is:

1. Locate the offending UDT (use Options > Reference Data > Display and filter by the UDT number).
2. Decide whether the UDT change is intentional. If yes, recompile all blocks that reference the UDT.
3. If the change was accidental, restore the UDT from a backup or from the previous archive.

10. Common Error Codes and Diagnostics

The interface change dialog itself is dialog box 0x8000xxxx in the STEP 7 internal coding, but the more useful field codes are the CPU diagnostics emitted when an interface mismatch reaches the runtime:

For S7-1500 CPUs (firmware V2.5 and later, in combination with TIA Portal V15+), the diagnostic buffer records the mismatch as a "Block inconsistency" event. The CPU continues running the old code, but the OB122 / OB121 is raised on each scan that hits a missing pin. Resolve by updating the block call and downloading.

11. Firmware and Software Compatibility Notes

• STEP 7 V5.5 SP4 / SP5 (and the later V5.6 release) implements the interface time stamp in a way that is fully forward-compatible with TIA Portal-generated blocks, provided the export/import uses SCL with the same Block interface version disabled.
• TIA Portal V13 / V14 handle interface changes identically to V15+ except that the Version-compatible interface property is absent. V15 introduced it; V16 added cross-project consistency check support.
• S7-1500 CPU firmware V2.0+ supports online interface snapshotting, which lets you back-port interface changes from the CPU to the project (right-click the block, Snapshot interface).
• PLCSIM V15+ enforces the same consistency rules as a real CPU, so simulating the save/download flow is a reliable check.

12. Verification Checklist After Resolving

1. Re-run Edit > Check Block Consistency in SIMATIC Manager (or Compile > Software (rebuild all blocks) in TIA Portal). The output list must be empty.
2. Open the call sites in the LAD/FBD/STL editor; no red exclamation marks should remain on the call rectangle.
3. Cross-reference check: Options > Reference Data > Display > Programmed blocks should list the block under the new parameter names.
4. Perform a download to the target CPU (or to PLCSIM). The diagnostic buffer should not contain a "Block interface error" entry after the next scan.
5. Force / watch the new parameter (or an existing one) to confirm online visibility.

13. Prevention: Designing Interfaces to Be Future-Proof

• Always place new parameters at the end of the interface. STEP 7 does not guarantee pin position stability when parameters are inserted in the middle.
• For FBs, prefer Version-compatible interfaces (TIA Portal V15+). For STEP 7 V5.x, simulate the same idea by adding parameters at the bottom of the section.
• Avoid renaming parameters that are already wired in the field. If a name change is unavoidable, perform a global search/replace after recompile.
• Centralise reusable structures in UDTs. A UDT parameter is easier to migrate than a long list of elementary tags.
• For libraries, document the interface as part of the release notes and bump the type-FB version number in the symbol.

14. Frequently Asked Questions