Resolving PCS 7 Library Module Copy Errors in SIMATIC Manager

Problem Overview

Engineers maintaining a Siemens SIMATIC PCS 7 V8.1 multiproject frequently rely on a Master Data Library (MDL) to host Control Module Types (CMT) built from CFC charts, SFC charts, and shared Function Block (FB) instances sourced from the Advanced Process Library V8.1 (AdvLib81) and the Advanced Engineering System (AdvES) catalog. When a Control Module Type is instantiated into a target S7 program and the resulting chart is opened in the CFC editor, three correlated symptoms appear simultaneously:

1. Function blocks inside the copied CMT instance are missing or display as a blank sheet in the CFC editor. The MDL master chart still contains the FBs and the project block container still owns the block types, yet the chart-internal block references (instance references) are gone.
2. Clicking the "Technological I/Os" tab of the copied CMT triggers the dialog Project library doesn't exist. The path resolution to the shared technological interface descriptors fails because the link to the source CMT has been severed.
3. The component view of the same multiproject shows duplicate entries of the CMT that were not created manually. The duplicates carry a suffix such as (1) and have a created-date timestamp matching the failed copy operation. The plant view does not show the duplicates, confirming that the corruption is contained to the component view XML wrapper of the library/master data.

A fourth collateral symptom is the library compile error "Missing instance declaration" raised by the SFC chart contained in the MDL. The CMT compile in the destination project can still succeed and the program downloads to the AS 410 station, but the CFC chart visualization is unusable until the block references are restored.

Root Cause Analysis

PCS 7 stores a CMT in two cooperating layers: the chart body inside the CFC/SFC editor (sheet layout, FB positions, signal wiring, technological I/O descriptors) and the block container in the S7 program (FB/FC/DB source, instance DBs, block icons). When a CMT is dragged from the MDL into a project, SIMATIC Manager performs a logical copy, not a binary copy. The copy operation must update the chart's internal reference table to point at the instance DBs that the destination S7 program will own.

Three conditions cause the chart references to desynchronize from the block container:

1. Stale AdvES export cross-reference. The AdvES catalog stores its own pointer from the CMT name to the FBs that populate the type. If the export from AdvES to the MDL was performed while a previous CMT with the same name was open in the CFC editor, the cross-reference can be written against a phantom block record. The MDL still parses, but the instance reference table in the destination chart resolves to DBNIL.
2. SFC chart in the MDL with broken instance declarations. An SFC chart stored inside the MDL needs its own instance DB declared under the target program. If the instance declaration is dropped during an AdvES round-trip, the MDL compile fails with "Missing instance declaration", and the failure propagates upward, marking the CMT records as inconsistent.
3. Component view wrapper duplication. Each CMT is represented twice in the project: once in the plant view (logical, hierarchy-driven) and once in the component view (physical, document-driven). The component view record is the XML that links the CMT to the technological I/O descriptors. When the AdvES export rewrites the CMT without cleaning the previous component view entry, a duplicate record is created in the component view while the plant view remains untouched.

The CMT instances can still compile and download because the S7 program block container holds the FB types and the CFC compiler resolves FB types from the program-level block container, not from the chart-level reference table. The chart-level reference table is what drives the visual layout in the CFC editor, which is why the chart appears blank while the code still runs on the AS.

Affected Software and Components

Diagnostic Procedure

Before rebuilding a single CMT, capture the following evidence so that the failure can be confirmed and the rebuild can be prioritized.

1. Open the CFC compiler log. In the CFC editor, choose Options → Compiler → Display Log on the affected chart. The log lists each block that the compiler could not resolve against the chart reference table. A pattern of Block reference lost: FBxxxx, instance in chart sheet X entries confirms the desynchronization.
2. Check the SFC instance declaration. Open the SFC chart stored inside the MDL. Select Options → Chart Check. If the chart references an instance DB that does not exist in any S7 program of the multiproject, the missing declaration is the root of the library compile error.
3. Compare plant view and component view. In SIMATIC Manager, switch the same project between the plant view and the component view. CMTs that exist twice in the component view but once in the plant view are the corrupted records. Note the created-date timestamp; records created at the same time as a failed copy are the duplicates to delete.
4. Validate the technological I/O link. Right-click the CMT instance in the destination program and open Technological I/Os. The Project library doesn't exist dialog confirms that the XML pointer from the CMT to the project-level technological I/O descriptor has been severed.
5. Inspect the AdvES export log. If AdvES was used to generate the CMT, the export log records the catalog name and the destination MDL path. A failed export that did not roll back fully leaves a partial CMT record that passes the SIMATIC Manager parser but fails the CFC chart reference resolution.

Step-by-Step Resolution

The recovery procedure preserves the existing S7 programs and their instance DBs, rebuilds the MDL CMTs from the catalog, and restores the chart-level block references without requiring a full project re-import.

Step 1 - Stabilize the multiproject

1. Close every SIMATIC Manager, CFC, SFC, and AdvES session across the engineering network.
2. Take a filesystem backup of the entire multiproject folder, the MDL folder, and any shared block library folder referenced by the project.
3. Confirm that no engineer has the MDL checked out or open in a remote session before proceeding.

Step 2 - Remove component view duplicates

1. Open the multiproject in SIMATIC Manager and switch to the component view.
2. Sort the CMT entries by Created timestamp. The duplicates created during the failed copy operation will share a timestamp.
3. Delete the duplicate whose name carries the (1) suffix. Use the right-click context menu and confirm the deletion. Do not delete the original; the plant view already references the original.
4. Switch back to the plant view and confirm that the CMT list is unchanged.

Step 3 - Fix the SFC instance declaration

1. Open the MDL in SIMATIC Manager.
2. Double-click the SFC chart that triggered the "Missing instance declaration" error.
3. Select Options → SFC → Instance Declaration. The dialog lists the SFC chart and its target instance DB.
4. For each entry marked Missing, either point the declaration at an existing instance DB in the destination S7 program or create a new instance DB by selecting New Instance.
5. Compile the SFC chart. The "Missing instance declaration" error should clear.

Step 4 - Recreate the corrupted CMTs

CMTs whose chart-level block references are lost cannot be repaired in place. Recreate each one in the MDL using the AdvES catalog, then re-instance the new type into the destination project.

1. Open AdvES and connect to the same MDL used by the multiproject.
2. Create a new Control Module Type with the same name and the same technological I/O interface as the corrupted CMT. Use the AdvLib81 catalog to insert the same FB set (CTRL_PID, MOT_SPEED, VALVE_ANA, OP_D, etc.) that the original CMT used.
3. Export the new CMT from AdvES into the MDL. Wait for the export to complete and verify that no warnings appear in the AdvES log.
4. Open the MDL in SIMATIC Manager, locate the new CMT, and confirm that the CFC chart now contains the FBs in the chart reference table.
5. Copy the new CMT from the MDL into the destination S7 program using drag-and-drop or Copy / Paste.
6. Open the resulting chart in the CFC editor. The function blocks must render, and the Technological I/Os tab must open without the Project library doesn't exist dialog.

Step 5 - Repoint existing instances at the new CMT

Existing CMT instances in the destination programs keep their instance DBs, but their chart-level references now point at the old (corrupted) CMT. Update each instance to point at the new CMT without touching the instance DBs.

1. Right-click the CMT instance in the S7 program and select CMT → Change Type.
2. Select the newly created CMT from the MDL.
3. Confirm the change. The chart re-resolves its block references against the new CMT, and the existing instance DBs are reused.
4. Recompile the S7 program and download to the AS 410 station. The downloaded code is identical to the pre-failure state because the FB types and instance DB contents are unchanged.

Step 6 - Verify the multiproject

1. Compile the entire multiproject. No "Missing instance declaration" errors should remain.
2. Open each recreated CMT instance in the CFC editor and confirm that every FB renders.
3. Open the Technological I/Os tab of each instance and confirm that the dialog opens without error.
4. Switch between the plant view and the component view and confirm that the CMT list is identical in both views.
5. Download the affected S7 programs to the AS 410 station and verify that the process values on the OS server match the pre-failure state.

Verification Checklist

Preventive Measures

Apply the following practices to the engineering workflow to prevent recurrence across the next PCS 7 maintenance cycle.

1. Single-owner rule for the MDL. Allow only one engineer at a time to edit the MDL. The CMT cross-reference table is not designed for concurrent edits; SIMATIC Manager will not warn about a conflicting edit on the same CMT.
2. Avoid compiling the MDL. The MDL stores type definitions, not executable code. A library compile triggers a cross-resolution pass against every S7 program in the multiproject and can corrupt the CMT reference table if any program is in an inconsistent state. The official SIMATIC Process Control System PCS 7 Compendium Part A - Configuration Guidelines (V8.1) recommends keeping the MDL in a type-only role.
3. Validate AdvES export before closing the catalog. After every AdvES export, open one of the affected CMTs in the CFC editor of the MDL and confirm that the chart reference table resolves every FB. A failed export is far easier to roll back before the catalog is closed.
4. Version the MDL with the project. Store the MDL inside the multiproject folder rather than on a shared network drive. Tie MDL revisions to project milestones using a version control system that can compare two MDL XML trees. This makes a roll-back to a known-good CMT a single restore operation.
5. Do not delete and recreate CMTs with the same name in the same SIMATIC Manager session. SIMATIC Manager caches the previous CMT record in the component view during the session. Recreating a CMT with a name that was just deleted in the same session is the most reliable way to trigger the component view duplicate.

Edge Cases and Field-Proven Caveats

The procedure above covers the canonical failure. The following edge cases appear in the field and require the noted adjustments.

1. CMT instance is part of a sequential recipe. If the CMT instance is referenced by an SFC chart in a destination program, the SFC transition conditions point at CMT tag names. The Change Type operation in Step 5 preserves the tag names, but verify the SFC compile log after the change to confirm that the SFC transitions still resolve.
2. CMT uses a custom FB that is not in AdvLib81. User-defined FBs are stored in the S7 program block container of the program that owns the CMT instance. The block reference loss in the chart layer does not delete the FB type. The Change Type operation in Step 5 will resolve the FB type from the program block container automatically.
3. Multiple engineers with separate AdvES installations. If the MDL was edited by two engineers using different AdvES patch levels, the CMT cross-reference table can carry pointers that are valid only for the older patch. Force a uniform AdvES patch level across the engineering team before the next MDL edit cycle.
4. CMT is used in both the OS server project and the AS program. PCS 7 replicates the CMT chart into the OS server project for faceplate generation. After Step 5, recompile the OS server project and confirm that the WinCC faceplates regenerate without warnings.
5. Library compile error persists after Step 3. If the "Missing instance declaration" error remains after fixing the SFC instance declaration, the issue is a CFC chart in the MDL, not the SFC chart. Open the CFC compiler log and locate the chart that lists missing block references. Recreate that chart following Step 4.

Troubleshooting Matrix

Reference Documentation

Engineers applying this procedure should consult the following official Siemens documents. The PCS 7 Compendium Part A explicitly recommends keeping the Master Data Library in a type-only role and warns against compiling the library.

• Siemens Industry Online Support - PCS 7 V8.1 documentation portal, firmware downloads, and Knowledge Base entries.
• SIMATIC Process Control System PCS 7 Compendium Part A - Configuration Guidelines (V8.1) - CMT workflow and Master Data Library management (see section on Control Module Types and Master Data Library).
• SIMATIC PCS 7 Advanced Process Library V8.1 (AdvLib81) manual - FB block descriptions, I/O interface definitions, and technological I/O mapping.
• SIMATIC PCS 7 Advanced Engineering System V8.1 (AdvES) manual - CMT generation, catalog management, and MDL export procedures.

FAQ