Resolving CFC Download Error Block DB Already Exists in CPU - Block Was Not Downloaded
The error 'Block DB[x] already exists in the CPU! Block was not downloaded' occurs during SIMATIC PCS 7 CFC delta downloads when the offline CFC database attempts to allocate an instance data block number that is already occupied in the S7-400 CPU work memory. This inconsistency is typically caused by an interrupted or aborted previous download, by downloading blocks directly from the SIMATIC Manager block folder or SCL editor rather than through the CFC Editor, or by manual DB insertion. To resolve this without stopping the plant, open the CFC Online View or Accessible Nodes, locate and delete the unlinked orphan DB from online CPU memory, recompile CFC with module drivers, and execute a delta download.
Table of Contents
- Root Causes of CFC Instance DB Allocation Conflicts
- CFC Chart Database vs Online CPU Block Allocation Rules
- Comparison of Download Procedures and Integrity Impacts
- Step-by-Step Procedure to Clear Zombie DBs and Restore Delta Download
- Verification
- Limitations and Operational Precautions
- Engineer FAQ
- Technical References
- Related Articles
- Related Tags
Root Causes of CFC Instance DB Allocation Conflicts
In SIMATIC PCS 7, the Continuous Function Chart (CFC) compiler dynamically manages memory allocation for all technological blocks, module drivers, and communication instances. When CFC compiles charts, it generates instance Data Blocks (DBs) within a managed numeric range (typically starting above DB60 and extending up to DB999 or DB4095 depending on CPU architecture). These DB numbers are tracked exclusively inside the offline chart folder database (charts/).
When an engineer initiates a delta download from the CFC editor (PLC -> Download -> Changes only), the CFC download engine compares the compiled block list against its offline record of what was previously downloaded. If an instance DB (e.g., DB714 generated for an analog input driver Pcs7AnIn or interlock Intlk04) already exists in physical CPU RAM but the offline CFC bookkeeping believes the number is vacant or new, the S7-400 operating system rejects the block overwrite with: Der Baustein DB714 existiert schon in der CPU! Baustein wurde nicht geladen.
Three distinct engineering actions induce this failure:
1. Aborted Download Session: A previous delta download was terminated abnormally due to an Ethernet cable disconnection, communication timeout, power dip, or clicking 'Cancel' midway through block transmission. The CPU committed DB714 to RAM, but the engineering station rolled back its local transaction log before updating offline flags.
2. Non-PCS 7 Compliant Download via SIMATIC Manager: An engineer selected the S7 Program 'Blocks' folder in SIMATIC Manager Component View and clicked the toolbar 'Download' icon. In classic S7-400 CPUs (such as CPU 416-3 PN/DP, 6ES7416-3ES07-0AB0), this forces a raw STEP 7 block download, bypassing the CFC transaction manager entirely. The CFC editor is never informed that DB714 was loaded.
3. Manual DB Number Collisions: User-created shared or instance DBs created in STEP 7 were manually assigned numbers directly within the reserved dynamic range configured under CFC Options -> Customize -> Compile/Download.
CFC Chart Database vs Online CPU Block Allocation Rules
Understanding the architectural boundary between SIMATIC Manager and the CFC Editor is critical for maintaining AS integrity. While classic STEP 7 treats blocks as independent executable units, PCS 7 enforces strict hierarchical encapsulation where the AS program must be treated as a single monolithic database governed by the Chart Folder.
On standard modular S7-400 CPUs (CPU 414, CPU 416, CPU 417), the operating system allows raw S7 downloads from SCL, LAD, and SIMATIC Manager. However, modern SIMATIC PCS 7 CPU 410-5H controllers (6ES7410-5HX08-0AB0) actively police these operations at the firmware level. A CPU 410-5H running firmware V8.2 rejects raw block downloads from the block folder or SCL compiler, enforcing download execution solely via the CFC compilation engine to guarantee database synchronization.
Comparison of Download Procedures and Integrity Impacts
The following table details the differences between download mechanisms and their potential to cause DB collisions in S7-400 CPUs:
PLC -> Download -> ChangesPLC -> Download -> Entire programTarget system -> Charts -> Delete...Step-by-Step Procedure to Clear Zombie DBs and Restore Delta Download
Follow this rigorous engineering procedure to remove the conflicting block online and restore normal CFC delta download capabilities without halting production:
-
Identify the Conflicting Block:
- Note the exact block number reported in the CFC error log (e.g.,DB714).
- In the CFC Editor, selectOptions -> Customize -> Compile/Downloadand check the reserved DB range (e.g., DB1 to DB60 reserved for user, DB61 to DB999 for CFC). -
Verify That the Online DB Is Truly an Orphan:
- In SIMATIC Manager, selectPLC -> Display Accessible Nodesor open the online view of the S7 Program Blocks folder (View -> Online).
- LocateDB714. Right-click and selectObject Properties. Inspect the author and timestamp.
- Check cross-references (Tools -> Reference Data -> Display -> Cross References) to ensure no active cyclic OB or SFC is calling this specific DB. -
Delete the Zombie DB from CPU Memory:
- In the CFC Editor, selectTarget system -> Charts -> Delete...to view blocks currently online from a CFC perspective.
- Alternatively, in the online Blocks window of SIMATIC Manager, selectDB714and pressDelete. Confirm the safety prompt. The CPU removes the block from work memory immediately. -
Recompile Charts and Generate Module Drivers:
- In the CFC Editor, clickChart -> Compile -> Changes only. Ensure the checkbox Generate module drivers is checked.
- Check the compile log to verify zero errors and confirm which instance DB numbers were dynamically assigned. -
Execute Delta Download:
- SelectPLC -> Download -> Changes only.
- Verify that the delta download proceeds to completion without errors and that CPU RUN status is maintained throughout.
Verification
Confirm resolution through the following verifiable steps:
1. Open the CFC Editor and trigger a delta compile (Chart -> Compile -> Changes only). Confirm that the compile log reports 0 Errors and 0 Warnings.
2. Initiate PLC -> Download -> Changes only. Confirm the download progress bar advances through system data and blocks without generating error dialogs.
3. In the CPU Diagnostic Buffer (PLC -> Diagnostic/Setting -> Module Information -> Diagnostic Buffer), verify that event Event ID 16# 4304 or block loading acknowledgments occur with no subsequent 'Block loading rejected' entries.
4. Open the online CFC chart containing the associated driver or technological block and verify that dynamic signal values update in real time with green interconnection lines.
Limitations and Operational Precautions
- Never Delete Active Instance DBs of Cyclic Tasks: Deleting a DB that is currently being accessed by an active FB executed in OB35 (e.g. 100ms cyclic interrupt) will immediately trigger an area length error or DB read error (
OB121), causing an S7-400 CPU shutdown if OB121 is missing. - Avoid Raw Blocks Folder Downloads: Operating personnel and commissioning engineers must never use the SIMATIC Manager 'Download' icon while highlighting the 'Blocks' folder in a PCS 7 project.
- CPU 410-5H Protection: While classic S7-400 CPUs allow non-PCS 7 compliant downloads that cause these corruptions, CPU 410-5H firmware enforces strict download consistency and prevents raw SCL or manager downloads.
- Full Download Requirement: If multiple DB numbers are severely fragmented or corrupted due to repeated aborted downloads, an online delta fix may not be possible. A full compile (
Entire program) and full download (Download entire program) in CPU STOP mode must be planned during a maintenance turnaround.
Engineer FAQ
Why did the CFC compiler assign DB714 if it was already in the CPU?
The CFC compiler assigns instance DB numbers based solely on its local offline project database (charts folder). It does not query the CPU online RAM during compilation. If a prior download was aborted or blocks were downloaded via raw SIMATIC Manager tools, the offline compiler has no awareness of online residual blocks.
Can I just change the DB number reservation in CFC options to bypass the conflict?
Yes, you can temporarily increase the lower limit of the CFC dynamic DB range under Options -> Customize -> Compile/Download (e.g. from DB60 to DB800). However, this leaves zombie blocks consuming CPU RAM and does not resolve the root cause of project inconsistency.
Does deleting an unlinked DB in the CPU online window cause the controller to stop?
No, deleting an unlinked orphan DB does not cause a CPU stop, provided the block is not actively referenced by any running function block. However, if an active FB attempts to read or write to a deleted DB, the CPU calls OB121 (Programming Error). If OB121 is not loaded in the CPU, the CPU enters STOP mode immediately.
Technical References
- SIMATIC Process Control System PCS 7 Compendium Part A - Configuration Guidelines (A5E45063013-AA)
- SIMATIC PCS 7 CFC for S7 / S7-HiGraph / PCS 7 Manual (A5E41356136-AB)
- Siemens Industry Online Support FAQ: Resolving Block Conflicts During CFC Download (Entry ID 24249116)
- SIMATIC S7-400 Automation System CPU 410-5H Process Automation Manual (A5E32631667-AC)
Related Articles
- Resolving CPU Programming Error 58 on FC2936 After Splitting CFC Runtime Groups
- Methods and Limitations for Synchronizing Offline CFC Charts with Online S7-400 Controllers
- Diagnosing S7-400 CPU External Fault (EXTF) and I-O Access Errors (OB122) in PCS 7
- Optimizing Module Driver Generation and Communication Job Limits in PCS 7 CFC
Related Tags
- CFC Delta Download
- DB Already Exists
- S7-400 Memory Management
- Module Drivers
- CPU 416-3 PN/DP
- CPU 410-5H