TIA Portal V19 Project Library: Fixing FB Type Version Conflicts

Problem Description

Engineers working with TIA Portal V19 frequently structure reusable code as library types (master copies) inside the project library. When a higher-level Function Block (FB) such as CARICO_VERT_TRAV references other library-typed FBs (FB_SM and G120C in the reported case), TIA Portal must resolve each dependent type connection to keep the master copy consistent with the instances in use.

The reported failure mode is reproducible:

1. An FB is promoted to a project library type (master copy) and released at version 3.0.0 (in this case FB_SM and G120C).
2. A wrapper FB (CARICO_VERT_TRAV) is created that internally calls those typed FBs and is also released as a project library type.
3. Dragging the wrapper FB from the project library back into the same or another program tree triggers a TIA Portal error during the type update.
4. The error dialog blocks the operation and prevents re-insertion of the FB without modifying the dependent types.

A temporary workaround of disconnecting the dependent type connection lets the drop succeed, but TIA Portal immediately creates a new type at version 0.0.1 for both dependent FBs - exactly the result the engineer was trying to avoid because it pollutes the library namespace with duplicate, freshly-versioned types.

Affected Environment

Root Cause Analysis

TIA Portal project library types maintain a hidden type-instance relationship. When a type is updated, TIA traces every instance and the internal block-to-block call graph. The drag-and-drop action in the project library does more than copy bytes - it runs the type connection resolution routine, which has three sub-tasks:

1. Validate dependent types exist in the active project context with compatible major versions.
2. Reconcile interface signatures between master copy and any in-use instance.
3. Preserve or refuse the version stamp based on whether the type itself is being re-released.

If step 1 or 2 fails, TIA Portal refuses the drop. The most common triggers in S7-1500-only projects are:

• Stale type fingerprint: The block content hash referenced by the project library entry has drifted from the actual program block in the project (typically because the block was edited without re-promoting it to the type).
• Type connection table corruption: The XML sidecar that tracks <TypeConnection> nodes in the project file lists a dependent that was renamed, removed, or whose type-identifier changed.
• Cross-master copy conflict: Two library master copies of the same dependent FB exist with different fingerprints (e.g., FB_SM v3.0.0 in one master, v3.0.1 in another, both visible in the project library pane).
• Grouping / folder duplication: The same dependent type exists in multiple folders of the project library with conflicting version numbers.
• PLC family mismatch (rare on S7-1500-only projects): A dependent released for S7-1200 inside an S7-1500 project, or vice versa. TIA enforces a PLC-family binding on library types - the same reason Siemens engineers recommend releasing dependent libraries on the same target family.

Diagnostic Procedure

Before applying any fix, capture the project state. The following ordered checks isolate the fault in 5-10 minutes without modifying the project.

Step 1 - Confirm PLC family consistency

1. Right-click the project → Properties → note the device family for every CPU in the project tree.
2. Open the project library, select each dependent type (FB_SM, G120C) → right-click → Edit Type → Properties → confirm the Compatible CPUs list.
3. Verify every entry is in the S7-1500 family. If any entry lists S7-1200, the family binding is the root cause.

Step 2 - Inspect the type connection table

1. Close all editors.
2. Open the project folder on disk and back up the entire .ap19 archive.
3. Open the project file (or extract from the archive) and search for <TypeConnection>. Each entry contains attributes TypeName, Version, Fingerprint, and InstancePath.
4. Compare the Fingerprint of FB_SM and G120C against the SHA stored in the master copy. Mismatches indicate that the project block was edited after the type was released.

Step 3 - Inspect library pane for duplicates

1. In the project library pane, expand Master copies → Types.
2. Use the filter/search box to find every occurrence of FB_SM and G120C.
3. If duplicates appear with different version numbers, right-click → Show Dependencies to identify which instance points to which version.

Step 4 - Capture the error message

The dialog that TIA Portal displays contains an error code in the format "Object [name] is in an inconsistent state" or a numbered 16#80xxxx internal code. Record the exact text - it is required when searching the Siemens Industry Online Support knowledge base for known defects against TIA V19.

Resolution: Re-establish Type Connections Without Forking Versions

The goal is to make the drag-and-drop succeed without deleting type connections or generating a new 0.0.1 dependent. Follow this sequence.

Method A - Refresh dependent types and re-release

1. Open the dependent type's program block (e.g., FB_SM) in the project. Do not edit it.
2. Open the project library pane, right-click FB_SM v3.0.0 → Update Type → Update instances only (do not select Re-release type).
3. Repeat for G120C v3.0.0.
4. Open CARICO_VERT_TRAV in the program editor. The block call to FB_SM should now display a green check next to the type icon, indicating the connection is intact.
5. Right-click the wrapper FB → Update Type → Update instances only.
6. Attempt the drag-and-drop again. In most cases the error is resolved at this point because the stale fingerprint has been overwritten.

Method B - Re-release dependent types at the same major version

If Method A still fails, the dependent type content has genuinely drifted. The fix is to re-release the dependent at the same major version number so callers do not see a breaking change.

1. Open FB_SM in the program editor.
2. Right-click in the project library → Edit type → make a no-op change (e.g., add and immediately remove a space in the comment) to force a new compile.
3. Right-click the type → Release type version. In the dialog, manually set the version to 3.0.1 (or any minor increment - it is non-breaking per TIA's library rules).
4. Compile the project. TIA will offer to update instances; accept.
5. Repeat for G120C.
6. Open CARICO_VERT_TRAV and perform the same re-release at the same major version it was on (e.g., 3.0.0 → 3.0.1).
7. Retry the drag-and-drop. TIA Portal should now reconcile all three types cleanly.

Method C - Repair the type connection table directly (advanced)

Use this only when the project library pane is corrupted and Methods A and B fail. Always work on a backup copy.

1. Close TIA Portal completely.
2. Make a backup of the .ap19 archive.
3. Extract the project. Locate the ProjectLibrary folder under \IM\ or \Project\ in the unpacked tree.
4. Open the master copy XML for CARICO_VERT_TRAV and inspect the <DependentTypes> block.
5. For each entry, ensure RefTypeName matches exactly (case-sensitive) the <Name> in the dependent's master XML, and that RefVersion matches the active version stamped on that dependent.
6. Save, repack the project, and reopen in TIA Portal. The library pane will re-index.

Workaround (Emergency Only)

If the project is blocking a delivery and the above cannot be applied, the delete-type-connection workaround described in the original report is functional but produces a forked library. To minimize damage:

1. Before deleting the connection, document the current TypeName, Version, and Fingerprint of every dependent.
2. After the workaround succeeds and the new 0.0.1 dependents are generated, immediately delete the new 0.0.1 master copies from the project library.
3. Re-create the type connections manually: open CARICO_VERT_TRAV, delete the local instance calls, and re-insert them by dragging the original 3.0.0 dependents from the library into the call sites.
4. Compile and re-release CARICO_VERT_TRAV at a new minor version.

This sequence prevents the duplicate 0.0.1 types from being committed to source control and forces the project back to the intended library topology.

Verification

After applying the fix, run these verification checks before considering the issue closed.

Prevention and Best Practices

Adopt these rules on every project that uses project library types, especially in multi-engineer environments where blocks are modified concurrently.

• Promote consistently: Any change to a typed block must be followed by a re-release of that type at the same major version (or a deliberate major bump). Editing a block without re-promotion is the leading cause of fingerprint drift.
• Release on the same CPU family: Always release dependent types on the same family of PLCs that will use them. Mixing S7-1200 and S7-1500 dependents inside one wrapper is permitted but adds a binding-resolution step that frequently fails.
• Use one folder per type: Avoid placing the same dependent in multiple project library folders. The pane shows the first hit and silently masks the second, which produces phantom version mismatches.
• Source-control the .ap19 archive, not the unpacked XML: The internal type-connection table and the master copy XML are interdependent. Diffing unpacked XML is unreliable.
• Document the version policy in the project README: State the rule (e.g., "major bump only on interface change, otherwise minor") so all team members follow the same convention.
• Clean the library pane before large refactors: Use Library → Cleanup (where available) to remove orphaned master copies that no longer have instances.

When the Issue Persists

If all three methods fail and the error recurs on multiple machines, the project file is likely in an unrecoverable state for the library pane. Escalate with the following evidence attached to a Siemens Support Request (SR):

• Exact TIA Portal V19 build number (Help → About).
• CPU part numbers and firmware versions of every controller in the project.
• Full text of the error dialog and any 16#80xxxx code.
• Exported project library archive (Library → Export) so support can reproduce the type-connection table in isolation.
• A minimal reproducer project that contains only the wrapper FB and its dependents.

Open the SR through the Siemens Industry Online Support portal under the SIMATIC TIA Portal product tree. Reference the related entries in the S7-1500 system manual and the TIA Portal help topic "Library basics" for additional context when communicating with support.

Related Field Notes

• PLCSIM V19 fully simulates the type update and can be used to verify the fix before downloading to real hardware. Use it whenever a physical CPU is not available.
• Multi-project consistency: When the same library is consumed by several TIA projects, the type-version stamp is project-local. Synchronize versions across projects manually or use a global library master copy to enforce a single source of truth.
• UDT dependencies: The same drag-and-drop failure mode applies to User-Defined Types (UDTs) that contain other typed UDTs. The resolution methods above are identical.
• Watchdog during compile: On very large libraries (50+ master copies) the type-resolution step can take several minutes. Let TIA finish before assuming it has hung.