Resolving CFC Error 'Invalid Object Type - SCH_OBJECT_TYPE_CHECK' and 'TMS_OBJECT_WRITE' When Copying Blocks in PCS 7 v8.2

In SIMATIC PCS 7 v8.2 (including Update 2), when copying or moving function blocks within the same chart or across different CFC charts triggers 'Invalid object type, System_Error / SCH_OBJECT_TYPE_CHECK' followed by 'Error being passed on, System_Error / TMS_OBJECT_WRITE', the fault is caused by an internal schema mismatch between the local chart container's database and the central Master Data Library, or corrupted relational pointers in the STEP 7 project database. To permanently eliminate these errors: execute 'Options > Block Types > Clean Up' in CFC, update all block types from the Master Data Library across the multiproject, and perform a 'Save As with Reorganization (Slow)' in SIMATIC Manager.

Root Cause of SCH_OBJECT_TYPE_CHECK and TMS_OBJECT_WRITE Errors

When an automation engineer copies or duplicates a block (e.g. MotL, PIDConL, or a custom FB) in the Continuous Function Chart (CFC) editor, the CFC core engine (s7jcfcax.dll) performs two internal database transactions:
1. Schema Object Type Verification (SCH_OBJECT_TYPE_CHECK):
- The engine validates the block's internal type definition, interface structure, and data types (UDTs) against the local project schema table.
- If the block was originally instantiated from an older library version while the chart container has partially adopted a newer library signature, the schema check fails: SCH_OBJECT_TYPE_CHECK.
2. Type Management System Write (TMS_OBJECT_WRITE):
- Following the schema validation failure, the CFC Type Management System (TMS) attempts to write an error exception record into the project database.
- If database indexes are locked, fragmented, or corrupt, the write operation cascades into a fatal database abort:
text Invalid object type, System_Error / SCH_OBJECT_TYPE_CHECK Error being passed on, System_Error / TMS_OBJECT_WRITE
- The copy operation is aborted, and the target block is not created.

Database Relational Inconsistencies in CFC Chart Containers

These errors typically manifest in multiprojects that have undergone incremental software updates (e.g. updating from PCS 7 v8.2 Base to v8.2 Upd 2) or where blocks were imported from external source libraries without full type propagation:
- Divergent Block Interface Timestamps:
* If a block instance in Chart A has a compilation timestamp differing by even one second from the block type residing in the S7 block container, the CFC schema manager detects a discrepancy.
- Dangling Cross-References in Deleted Charts:
* Charts that were deleted without executing a clean-up leave orphaned records in the internal relational database (.dbf / .s7p files) of the chart container.
- Corrupted Block Type Attribute Headers:
* Copying blocks between charts located under different AS stations with differing library versions causes immediate schema validation rejections.

Step-by-Step Resolution and Library Synchronization Workflow

Follow this verified procedure to repair chart database integrity and restore normal block copy/paste functionality:

Clean Up Unused Block Types in CFC:
- In SIMATIC Manager, open any CFC chart.
- In the menu bar, select Options > Block Types.
- In the Block Types window, click Clean Up.
- Select all unused block types and click OK to remove orphaned block headers from the chart container.
Synchronize All Blocks from Master Data Library:
- In SIMATIC Manager, navigate to the Master Data Library of the Multiproject.
- Open the Blocks folder of the Master Data Library.
- Select all blocks, right-click, and select Update Block Types....
- In the wizard, select all target AS projects within the Multiproject.
- Click Finish. This updates block interfaces, UDT signatures, and system attributes across every chart in the entire plant, establishing a unified database baseline.
Execute 'Save As with Reorganization (Slow)':
- Close all open CFC charts, SFC editors, HW Config, and WinCC Explorer.
- In SIMATIC Manager, select File > 'Save As...'.
- Select the target location and check the box With Reorganization (Slow).
- Click OK. SIMATIC Manager rebuilds all relational tables, purging corrupted pointer records and compacting database indexes.
Verify Copy Functionality:
- Open the reorganized project.
- Open a CFC chart and execute a test block copy/paste. The block instantiates immediately with zero errors.

CFC Database Integrity and Error Classification Table

The following table details common CFC internal error codes and their root causes:

Internal Error CodeSubsystem LocationRoot CauseVerified ResolutionSCH_OBJECT_TYPE_CHECKCFC Schema CheckerBlock instance interface mismatches Master Data Library typeUpdate Block Types across all AS stationsTMS_OBJECT_WRITEType Management SystemDatabase index write failure or lock during block duplicationPerform 'Save As with Reorganization (Slow)'CFC_FATAL_ERROR 1739:10OS Compiler / CFCIncremental delta cache references obsolete OCM block handleExecute full OS compile ('Entire OS')BLOCK_NOT_FOUNDChart LoaderBlock FB missing from offline S7 block containerCopy block from Master Data Library into Block folderINTERFACE_MISMATCHRuntime Group ManagerModified pin count or data type on connected blockRe-compile CFC program with 'Complete Program'

Verification

To confirm that the CFC database error is resolved:
1. Open a CFC chart in the reorganized project.
2. Select a complex block (e.g. MotL or PIDConL), press Ctrl + C, and press Ctrl + V.
3. Confirm that the copied block appears immediately with an incremented instance name (e.g. MotL1) without displaying any SCH_OBJECT_TYPE_CHECK dialogs.
4. Copy the block into a completely different CFC chart in another hierarchy folder; verify successful placement.
5. Execute Chart > Compile > Changes Only. Verify compilation completes with 0 errors and 0 warnings.

Limitations and Operational Precautions

When updating block types and reorganizing projects:
1. CFC Program Recompilation: Running 'Update Block Types' updates all instances in the project. If block interface changes occurred (e.g. added pins), CFC will require a 'Complete Compilation' and may block online delta downloads to the PLC.
2. Never Terminate Reorganization Early: Slow reorganization can take 15 to 45 minutes on large multiprojects. Never abort the process via Task Manager; interrupting database restructuring will destroy project files permanently.
3. Backup Before Execution: Always create a full multiproject archive via 'File > Archive' before initiating block type updates or database reorganizations.

Engineer FAQ

Why did this error happen suddenly when copying a block that was already in the chart?

The block in the chart was instantiated prior to a library update or service pack installation. When you copy it, CFC attempts to validate the copied instance against the current database schema, exposing the historical interface mismatch.

Does 'Save As with Reorganization (Slow)' delete any of my logic or connections?

No. Reorganization preserves all charts, block parameters, interconnections, and comments. It only rebuilds database pointers, defragments disk storage, and strips deleted records.

Can I fix this error by simply copying the FB into the block folder?

No. The error resides in the chart container relational schema, not in the S7 block container. 'Update Block Types' and database reorganization are mandatory.