Tracing Origin of Instantiated Function Blocks (FB/FC) in SIMATIC PCS 7: Master Data Library Reconciliation and Block Comparison

In SIMATIC PCS 7, instantiated Function Blocks (FBs) and Functions (FCs) in an AS program do not store persistent metadata pointing to their source library subfolder. When multiple library folders contain blocks with identical names but differing logic, the only reliable way to determine block origin is using the STEP 7 'Compare Blocks' utility. Right-click the AS block folder, select 'Compare Blocks...', and compare it against each library program folder. To resolve this architectural defect across 10 AS stations, consolidate the authoritative block versions into a single Master Data Library (Stammdatenbibliothek) and execute 'Options -> Charts -> Update Block Types' to align all controllers safely.

Block Instance Architecture in STEP 7 and SIMATIC PCS 7

In SIMATIC PCS 7 engineering, Continuous Function Charts (CFC) instantiate Function Blocks (FBs) and Functions (FCs) to execute process control algorithms. When an engineer drags an FB from a library into a CFC chart, STEP 7 automatically copies the compiled block binary into the offline blocks container of that specific Automation Station (AS). Furthermore, if that FB internally calls subordinate functions (e.g. FB1 calls FC10), STEP 7 automatically imports FC10 into the AS block folder as well.

A severe architectural flaw arises when custom libraries are organized into multiple program folders containing duplicate block numbers with divergent internal code. In a plant with 10 Automation Stations, engineers who instantiated blocks from various subfolders over years face massive uncertainty when attempting to modernize or standardize the codebase.

Why STEP 7 Does Not Retain Library Subfolder Provenance

A fundamental limitation of the legacy S7 program database is that block headers store only compilation timestamps, interface checksums, author names, and version numbers (Version: 1.0). STEP 7 does NOT store the file path or library subfolder name from which a block was originally copied.

Once an FB or FC resides inside the AS block container, it exists as an independent entity. Therefore, an engineer cannot simply open the properties of FB100 in AS 4 and read which library subfolder it originated from; block provenance must be reverse-engineered by comparing binary checksums and code logic against library templates.

Tracing Block Origin Using the STEP 7 Compare Blocks Tool

To determine which library folder an instantiated AS block originated from:

In SIMATIC Manager, navigate to the target AS and select the Blocks folder.
Right-click the Blocks folder and select Compare Blocks....
In the comparison dialog, set the comparison target to User Library / Open Project and browse to the specific program folder in the custom library.
Select the specific FB or FC and click Compare.
Review the comparison result:
- Identical: Code, interface, and attributes match 100%, confirming that the AS block is identical to this library folder's version.
- Different: Timestamps, code logic, or interface parameters diverge.
Repeat this comparison across the remaining library folders to pinpoint the exact match.

Consolidating Custom Blocks into a Central Master Data Library

Maintaining multiple program folders with conflicting block versions violates Siemens PCS 7 system architecture. The definitive solution requires establishing a single, authoritative Master Data Library (Stammdatenbibliothek):

In SIMATIC Manager, create a new library inside the multiproject folder (File -> New -> Library).
Right-click the library and select Multiproject -> Define as Master Data Library (the library icon turns blue).
In the Master Data Library, create one single Blocks folder.
For every disputed block, review the competing versions, select the authoritative standard version, and copy it into the Master Data Library.
Note: Deleting obsolete folders in a user library does not delete or impact blocks running in the AS controllers.

Auditing Multi-AS Block Differences via Update Block Types

Comparing 10 AS stations manually against multiple library folders would require up to 100 individual comparison steps. The Update Block Types utility automates this entire audit across all 10 controllers simultaneously:

In SIMATIC Manager, select the multiproject root.
Select Options -> Charts -> Update Block Types.
In the wizard, select the Master Data Library as the source.
The wizard parses all 10 AS projects and displays a comprehensive cross-reference table showing:
- Blocks that are identical across all AS stations.
- Blocks with differing interface timestamps or version numbers.
- Blocks present in the AS but absent from the library.
Audit Without Updating: You can cancel the wizard after reviewing the report, using the output as an instant gap-analysis audit.

Comparative Workflow Matrix: Manual Block Comparison vs Type Update

The following table compares the two diagnostic and reconciliation methods:

| Engineering Dimension | Compare Blocks Tool | Update Block Types Wizard |
|---|---|---|---|
| Scope | Single AS block folder vs single library folder | All 10 AS projects vs Master Data Library simultaneously |
| Granularity | Instruction-by-instruction ladder/AWL diff | Interface version, timestamp, and attribute comparison |
| Execution Risk | Read-only; zero risk to running controller | Can update block types; requires caution before downloading |
| Analysis Output | Detailed side-by-side graphical diff | Tabular list of divergent blocks across the multiproject |
| CPU STOP Risk | None | Yes, if interface alterations invalidate delta download |
| Best Used For | Pinpointing exact logic differences in 1 block | Global plant-wide standardization and gap analysis |

Verification

Verify block standardization across the multiproject through the following steps:

After consolidating blocks in the Master Data Library, re-run Options -> Charts -> Update Block Types.
Verify that all target AS stations report 'No differing block versions found'.
In CFC, execute a test compile (Charts -> Compile -> Changes Only). Confirm that the compiler reports 0 errors.
If block interfaces were identical, perform a delta download to the running AS; verify that process control continues uninterrupted.

Limitations and Operational Precautions

Adhere to the following operational precautions:

Beware of CPU STOP Downloads: If updating block types changes the structural interface (adding inputs, changing data types, modifying instance DB layouts), PCS 7 cannot execute a delta download. A full download in CPU STOP will be enforced.
Subordinate Block Calls: When copying an FB into the Master Data Library, always ensure that all functions (FCs) called by that FB are copied into the same block container.
Never Store Libraries Outside the Multiproject: Store the Master Data Library directly within the multiproject file structure, not in the global STEP 7 installation directory (S7LIBS).

Engineer FAQ

Why did the original programmer place identical blocks in multiple library folders?

Often, an FB (e.g. FB1) calls a subordinate FC (e.g. FC10). To allow different engineers to import FB1 or FB2 independently without missing FC10, the developer copied FC10 into multiple folders.

How do I avoid having to run 100 manual block comparisons across 10 AS stations?

Use 'Options -> Charts -> Update Block Types' from the multiproject root. The wizard compares all 10 AS stations against the Master Data Library in a single overview table.

What is the danger of executing an Update Block Types on a running plant?

If the update modifies block interface parameters (adding, removing, or re-ordering pins), delta download capability is lost, requiring a full download with the CPU in STOP.