TIA Portal V17 Library Types Preventing Cascading Version Changes

1. Problem Overview

When a Siemens S7-1200/S7-1500 project contains nested library types, an edit-and-release cycle on the parent type can unintentionally bump the version numbers of every dependent child type and UDT. The symptom is observable in TIA Portal V17 where a change applied only to fbParent causes fbChild and typeStructure to increment their internal version identifiers as well. The expected behaviour, and the documented baseline behaviour of TIA Portal V16, is that only the type whose interface or code actually changes should be republished at a new version.

This document describes the architectural reason for the cascade, the differences between TIA V16 and V17, the diagnostic procedure to confirm the cascade in a given project, and a clean rebuild workflow that has been verified to restore single-type version isolation.

2. Library Architecture: Master Copies vs Types

TIA Portal exposes two fundamentally different library containers. Misunderstanding the boundary between them is the root cause of most version-cascade complaints.

Types are the only library objects that carry a version number. The version is incremented when a type is "released" via the library context menu. Master copies are version-less by design - if a master copy is dragged into a program and edited, the original master copy is not affected.

3. Type Versioning Mechanics

Every library type carries a type-of-type header that records:

• Type name (e.g. fbParent)
• Version ID (e.g. 2.3)
• Fingerprint hash of the compiled interface (IN/OUT/IN_OUT/STAT/TEMP signature)
• Hash of the contained code body
• List of referenced child type UUIDs and their required minimum versions
• List of referenced UDT type UUIDs

When you edit the code body of a parent type without touching the interface, only the code-body hash changes; the version can be bumped as a minor (e.g. 1.0 -> 1.1). When the interface changes, a major bump is recommended (1.x -> 2.0) so that consumers are forced to perform an "Update instances" review.

The fingerprint hash is what TIA uses during compilation to determine whether the referenced child type still satisfies the parent's declared dependency. If the parent advertises "I require fbChild >= 2.0" and the project's library currently holds fbChild 1.5, TIA either auto-promotes the child or raises a consistency warning depending on project settings.

4. Parent-Child Dependency Behaviour

The library model treats fbParent containing a call to fbChild as a hard reference. The parent's type descriptor literally stores the child type's UUID and minimum-acceptable-version field. A UDT used in the parent's VAR_TEMP or STAT section is treated identically - the parent's type carries the UDT UUID.

The cascade happens during the "Release type" workflow:

1. Engineer edits the source of fbParent in the project library editor.
2. Engineer clicks "Release type" and confirms the version bump dialog.
3. TIA Portal recompiles fbParent.
4. During recompile, the dependency resolver inspects every referenced child type and UDT.
5. If the resolver decides that any referenced unit's stored fingerprint no longer matches what the parent expects (because the parent itself has a new fingerprint), the resolver may write a new version of the child into the library as a side-effect.

Step 5 is the cascade. Whether step 5 fires depends on the project-library state, the product edition (Basic vs Professional) and the TIA Portal service pack level. The behaviour is identical across S7-1200 and S7-1500 targets.

5. TIA V16 vs V17 - Documented Difference

The behavioural shift was introduced as part of the V17 dependency-graph rewrite that, among other things, attempts to auto-heal missing child types by searching the global library at compile time. The auto-heal feature is useful when starting from scratch but produces the cascade when upgrading an existing V16 project that carries a V16-vintage library whose internal UUID mapping predates the rewrite.

6. Diagnostic Procedure

Use this checklist to confirm that the cascade is occurring in your project and to isolate the offending library.

1. Reproduce in a clean project. Create a new TIA V17 project, add two empty FBs (fbParent, fbChild) and one UDT (typeStructure). Promote each to a project-library type at version 1.0. Have fbParent call fbChild and declare a STAT of typeStructure. Edit only fbParent code body, release as 1.1. Verify whether fbChild and typeStructure stayed at 1.0.
2. Inspect the library version table. Right-click the project library -> "Manage types" -> observe the version column for each affected type before and after each release.
3. Read the compile log. Compile the program blocks (not the entire project). The information pane lists every type UUID that was touched during the compile. Any type whose UUID appears that you did not edit is being cascade-updated.
4. Compare project-library fingerprints. Export the library before and after the release (.xml or .zip) and diff the contained *.db files. A type whose internal timestamp moved even though you did not edit it confirms the cascade.
5. Audit the dependency tree. In the library editor, open fbParent -> Properties -> Dependencies tab. Confirm that fbChild and typeStructure are listed with the expected minimum-version fields.
6. Check for legacy V16 imports. If the library was originally created in V16 and dragged into a V17 project, open each type's Properties -> "Origin". A "Migrated from V16" flag indicates the dependency metadata may have been carried over verbatim and is now triggering the auto-heal resolver.

7. Clean Rebuild Workaround

The following workflow has been demonstrated to eliminate the cascade when the project carries an upgraded V16 library.

1. Inventory the V16 library. In the original V16 project, list every type, master copy, UDT, tag table and PLC data type that belongs to the library. Export each as a standalone source file (.scl, .udt) where possible.
2. Create an intermediate "do nothing" V16 project. Use a fresh V16 project on the same PLC platform (S7-1500 or S7-1200) that the production target uses. Insert the exported blocks and UDTs. Do not promote anything to a library type yet.
3. Upgrade the intermediate project to V17. Open the V16 intermediate project in TIA V17 and run the standard upgrade wizard. Confirm that all blocks compile cleanly with no warnings.
4. Create a fresh V17 project library. In the upgraded intermediate project, right-click the project library and create a new library container. Drag each block and UDT from the program into the new library. Promote each to a type. Assign explicit initial versions (e.g. all start at 1.0).
5. Establish dependencies deliberately. Open fbParent in the new library. From the "Dependencies" tab, manually add the references to fbChild and typeStructure with the desired minimum version (1.0).
6. Test single-type release. Edit the code body of fbParent, release as 1.1. Confirm that fbChild and typeStructure remain at 1.0. If they remain at 1.0, the rebuilt library is clean.
7. Migrate the clean library into the production project. In the production V17 project, replace the legacy library with the newly-built library. Re-drag each type instance into the program blocks. Perform "Update instances" once to absorb the new fingerprints.

8. Working with Types Across CPUs

The dominant use case for project library types is synchronising shared data structures and function blocks between two or more CPUs inside one TIA project - for example an S7-1500 controller paired with an ET 200SP CPU, or two S7-1500 stations exchanging data via PUT/GET or S7 communication.

Recommended pattern:

• Keep the shared UDT in a single type. Define the wire format once as a project library type. Both CPUs reference it. Bumping the UDT version on one side automatically invalidates the partner side, forcing a paired update - this is the intended safety behaviour.
• Keep per-CPU customisations as master copies, not types. Drag a master copy of the shared FB into each CPU's program blocks, then localise it. The shared type remains untouched.
• Use types only where interface stability matters. If a block's interface is volatile during development, keep it as a master copy until the interface stabilises, then promote it to a type.

9. V16 to V17 Migration Checklist

10. Best-Practice Rules

1. One container per logical layer. Maintain separate libraries for field-equipment FBs, communication UDTs and safety blocks. Avoid mixing volatile development code with stable production types.
2. Never edit a type instance directly. Always edit the type in the library editor. Editing an instance creates a "drift" between the type fingerprint and the instance, and the next "Update instances" pass will silently overwrite your local edits.
3. Use master copies for prototypes, types for production. Promote to a type only when the interface is frozen and the block will be reused across two or more call sites.
4. Avoid nesting types inside types. If a parent type must call a child type, prefer placing the child type in the same library but as a sibling. The dependency resolver handles siblings more predictably than nested containers.
5. Lock released versions. After a type is released and consumed by the production CPU, treat the version as immutable for that project. Further development of that block happens in a new branch library, then is merged deliberately.
6. Use multiselection for bulk moves. When moving multiple objects between library folders or between project and global libraries, hold Shift or Ctrl to multi-select. Single-object moves are error-prone and lose dependency metadata. See the official Siemens KB 109476840 - Working efficiently with libraries in STEP 7 (TIA Portal) for the full multiselect workflow.

11. Cross-Product Compatibility Caveats

TIA Portal ships in multiple editions - STEP 7 Basic, STEP 7 Professional, and various add-on packages. Not every library object is editable across editions. According to the TIA Portal V21 documentation - Using libraries in different TIA products:

• STL program blocks cannot be opened or edited in STEP 7 Basic even if they originate from a Professional project. The block icon in the library shows an unsupported-product overlay.
• Master copies and types inherit the same restriction - if a version of a type was created in Professional and is later opened in Basic, the type is read-only.
• Master copies from older TIA versions (V13, V14) can be carried forward into V16, V17, V18, V19, V20, V21 projects, but the internal dependency metadata is rewritten silently during the migration. This silent rewrite is one of the most common sources of phantom cascade behaviour after a version jump.

12. Known Limitations

• TIA Portal does not implement OOP polymorphism in the CodeSys or B&R Automation sense. There is no method overloading, no interface implementation, no abstract base class. If a feature in your application requires true polymorphism, you must implement it manually using wrapper FBs and conditional calls. This is a documented platform limitation, not a defect.
• The library view does not display the source code of a released type's previous versions - only the latest released version is fully readable. If you need historical code, export the library after every release and archive the export.
• The auto-heal resolver introduced in V17 only searches the currently attached global library, not the entire global library pool. If the required child type is in an unattached global library, the auto-heal will fail and the compile will raise "child type missing" instead of promoting the child.

13. FAQ