Understanding Block Version Numbering, Interface Signatures, and Type Updates in PCS 7
In SIMATIC PCS 7 and STEP 7, block version numbering (e.g., '9.7' on FB1869) uses a 'Major.Minor' format defined in the block's SCL or STL source attribute 'VERSION : 'x.y''. Minor version increments represent internal algorithmic improvements, bug fixes, or performance optimizations with unchanged interface signatures, allowing online delta downloads in RUN. Major version increments typically indicate modified block interfaces (added, deleted, or reordered input/output/static variables), which alter the block's interface checksum (GUID) and require type updates across the multiproject and CPU STOP downloads unless managed via TCiR (Type Change in RUN).
Table of Contents
- Executive Summary
- Architectural and System Mechanics
- Step-by-Step Engineering and Implementation Procedure
- Verification
- Limitations and Operational Precautions
- Engineer FAQ
- Technical References
- Related Articles
- Related Tags
Executive Summary
Maintaining block libraries across evolving versions of SIMATIC PCS 7 requires a thorough understanding of how STEP 7 tracks block versions and interface consistency. Engineers frequently observe blocks such as FB1869 carrying version identifiers like 9.7 and question how these numbers correspond to overall PCS 7 software releases. In STEP 7, block version numbers are internal developmental attributes declared in source code headers. More critically, the controller evaluates block interface timestamps and checksums rather than text version numbers to safeguard data consistency. This guide explains block version numbering mechanics, interface signature generation, the rules governing delta downloads in RUN, and type update procedures.
Architectural and System Mechanics
The architecture of block versioning and interface management in STEP 7:
- Source Code Version Header: Declared in SCL via
VERSION : '9.7'. It is a string identifier compiled into the block header attributes (viewable in block properties -> 'Version'). - Interface Signature (Interface Time Stamp / GUID):
- Whenever a Function Block's inputs, outputs, or static
VARdeclarations are modified, the compiler generates a new interface signature. - Because instance data blocks (DBs) allocate memory matching the FB's static variable structure, changing the FB interface invalidates existing instance DB memory offsets.
- Embedded Version Structures in PCS 7 V9.1:
- In PCS 7 V9.1 and newer APL libraries, blocks contain internal visible structure parameters containing block number, library version, and build timestamp for runtime asset tracking.
- Type Change in RUN (TCiR):
- CPU 410-5H controllers support TCiR, allowing engineers to update block types with altered interfaces in RUN mode under strict memory guidelines.
Step-by-Step Engineering and Implementation Procedure
Step 1: Inspect Block Version and Attributes in SIMATIC Manager
- In SIMATIC Manager, navigate to the block folder of the master data library or AS project.
- Right-click the block (e.g.,
FB1869) and select 'Object Properties'. - Inspect the 'Version' field (e.g.,
9.7), 'Author', and 'Family' (e.g.,APL). - Switch to the 'Attributes' tab to view internal OCM and system attributes.
Step 2: Compare Block Interfaces Prior to Type Update
- Before updating an existing block across a production multiproject, open the block in the library.
- Use 'Options' -> 'Compare Blocks' in SIMATIC Manager to compare the library block with the AS project block folder.
- Verify whether differences are restricted to code logic or include interface modifications.
Step 3: Execute Block Type Update in CFC
- Open any CFC chart in the project.
- Select 'Options' -> 'Block Types...'.
- Select the target block in the chart folder and click 'Update...'.
- The wizard displays the old version and new version, identifying affected CFC instances.
- If the interface changed, the wizard warns that instance DBs will be regenerated.
Step 4: Evaluate Download Capabilities (Delta in RUN vs STOP)
- If only internal logic changed (same interface): Compile charts delta; perform 'Download Changes in RUN'.
- If interface changed on S7-400 (non-CPU 410): Download requires placing CPU in STOP mode.
- If interface changed on CPU 410-5H: Use TCiR workflow to download interface changes without stopping the CPU.
Verification
To verify block version alignment:
1. In CFC, hover over any placed instance of the block; confirm that the tooltip reflects the new version string.
2. Execute a Delta Compilation in CFC; ensure no compilation errors or interface mismatch warnings occur.
3. Execute a Delta Download to the target controller.
4. Confirm that running process logic continues uninterrupted and block outputs remain valid.
Limitations and Operational Precautions
Operational precautions:
- Never modify standard library block interfaces directly in user projects; if customized functionality is required, create a user block with a distinct FB number in the user range (FB1 to FB1000 or custom ranges).
- Recompiling a block with altered static variables erases current runtime values stored in instance DBs upon reload unless values are initialized properly.
- TCiR on CPU 410-5H requires sufficient reserve work memory; verify memory margins in Module Information before initiating type changes in RUN.
Engineer FAQ
Q: Does block version 9.7 mean it is for PCS 7 V9.7?
A: No. Block versions are internal library development version numbers and do not correlate directly with PCS 7 release numbers.
Q: Why does modifying an internal comment change the block timestamp?
A: Modifying comments does not alter the interface signature, but updates the block code timestamp in STEP 7.
Q: What happens if I download a block whose interface changed without updating instance DBs?
A: The CPU will reject the download or call OB121 (programming error). If OB121 is absent, the CPU enters STOP mode immediately.
Q: Where can I see block version information in CFC?
A: In PCS 7 V9.1, unhide the block's internal identification structure pin or inspect block object properties in CFC.
Q: What is TCiR in PCS 7?
A: Type Change in RUN (TCiR) is a feature of CPU 410-5H firmware that allows updating block types with changed interfaces without stopping the controller.
Technical References
- SIMATIC S7-400 Automation System STEP 7 V5.6 Manual
- SIMATIC Process Control System PCS 7 CFC for S7
- PCS 7 V9.0 SP3 Licenses and Configuration Limits
Related Articles
- Sourcing Superseded CFC Updates and Resolving SFC Compilation Error 1739-20 in SIMATIC PCS 7
- Resolving CFC Error 4297-15613 CPU Test Registration and S7 Connection Failures in SIMATIC PCS 7
- Coordinating APL Motor Interlocks and Sequential Control Using SFC and LogicMatrix in PCS 7
Related Tags
Block Version, Type Update, Interface Signature, TCiR, CFC Engineering