Resolving STEP 7 CFC Download Changes Error with Phantom DB

Overview

The "Download Changes Only" workflow in Siemens SIMATIC Manager (STEP 7 V5.x) and the higher-level PCS 7 engineering toolset is engineered to push incremental program modifications from the offline engineering station (ES) to the target automation station (AS) CPU without re-transferring the entire runtime image. When the AS program includes code generated by the CFC (Continuous Function Chart) editor, the compiler automatically creates a set of FC blocks plus their associated instance DBs that the runtime requires for cyclic execution. If the offline/online block image drifts — for example after a deleted chart, an aborted CFC compile, a corrupted S7 program folder, or a manual block deletion from SIMATIC Manager — the incremental download path rejects the operation and reports a non-existent DB block number (most commonly DB80, DB83, or DB100) that is not visible in the offline S7 Program / Blocks tree and is not present in the online block list of the CPU.

This reference documents the field-confirmed resolution path: delete all FCs that the CFC compiler auto-generated, run a full AS recompile, and re-attempt the download. The procedure was originally verified on a Siemens S7-417H / PCS 7 V7.1 SP3 system running STEP 7 V5.5 SP2 with CFC V7.1 SP3, and applies to any CFC-based S7-300 or S7-400 project in which the incremental download path is broken by a phantom DB reference. The condition is not project-specific to the DB number reported; any DB instance that the CFC compiler reserved for a function block inside a removed or orphaned chart will trigger the same failure mode. The DB number is a function of the chart instance count and the FB numbering rules enforced by the CFC runtime, so the same root cause can manifest as DB80 on one CPU and DB250 on another. Authoritative background on the S7 program model is available in the Siemens Industry Online Support portal under the SIMATIC STEP 7 V5.5 documentation set.

Problem Symptoms

The following diagnostic indicators confirm the condition observed in the source field report:

• The operator selects SIMATIC Manager → Options → "Compile and Download Objects" with the "Download changes to target system" option enabled, or right-clicks the AS and chooses "PLC → Download → to Target System" with the "Changes" radio button selected.
• STEP 7 returns a download dialog that lists one or more DB numbers — frequently DB83 — and refuses to continue with the message: "Block DBxxx does not exist on the target system and is not available offline."
• The reported DB number is not present in the offline S7 Program / Blocks container (right-click S7 Program → Object Properties → Blocks tab) and is not listed in the online CPU block inventory (Online → Accessible Nodes → CPU → Blocks).
• Performing a full program download via "Download User Program to Memory Card" or by selecting the "Entire program" radio button in the "Download to Target System" dialog is also rejected, even after a "Reorganize" action on the offline project (Options → Reorganize → Project-wide).
• No source file (.awl) for the phantom DB is found under S7 Program / Sources. The "Generate Source from Blocks" function does not produce a source stub for the missing DB.
• The component view shows the AS in a "modified since last online build" state, but "Check Block Consistency" returns the same missing-DB error rather than a fixable conflict.
• The CPU diagnostic buffer (CPU → Diagnostic Buffer in the online view) records entries of type "STOP due to download error" or "Download aborted — inconsistent block list" with timestamps matching the failed download attempt.

Root Cause Analysis

The phantom DB reference originates from a divergence between the offline CFC chart folder and the S7 program block container. In a healthy CFC project, the relationship is one-to-one: every CFC chart is compiled into exactly one FC, and every instance of an FB inside that chart is materialised as one DB. The mapping is stored in the chart-level system DBs (typically DB200..DB210) and in the SZL (System State List) of the CPU during runtime.

When a chart is deleted, copied, or moved in the plant view, the CFC editor updates the chart inventory and re-issues the FC list at the next compile. However, if the previous compile output (the FCs and their supporting DBs) was already loaded to the CPU and the new compile has not been propagated, the CPU retains a reference to a DB that the new offline image no longer contains. The "Download Changes Only" path performs a difference analysis between the offline S7 program and the online S7 program and detects the inconsistency at the DB level rather than at the chart level. Because the CFC-generated FCs are typically numbered in the FC60..FC250 range, the supporting DBs are numbered in the same range plus a fixed offset defined by the CFC chart instance model — which is why the error frequently references DB83, DB80, or DB100.

Three failure modes are responsible for the drift in field conditions:

1. Aborted CFC compile. A "Compile" or "Compile + Download" operation on a single chart was interrupted (power loss to the ES, STEP 7 crash, or manual cancellation). The chart folder metadata was updated but the block-level regeneration did not complete. The subsequent "Download Changes" attempt sees an FC reference that resolves to a DB that was never emitted by the partial compile.
2. Chart deletion without S7 program resync. A CFC chart was removed from the plant view, but the S7 program was never recompiled. The offline Blocks folder still contains the FCs and DBs of the deleted chart, but the CFC chart folder no longer tracks them. The downloader walks the offline Blocks folder, finds the orphan DB, and reports it as "not on the target system".
3. Manual block manipulation outside the CFC editor. An engineer renamed, copied, or deleted an FC or DB directly in SIMATIC Manager (for example to renumber a block or remove a duplicate instance) without re-running the CFC compiler. The compiler state cache becomes inconsistent with the Blocks container and the next incremental download will fail at the first DB that no longer has a corresponding chart.

The "Reorganize" function in SIMATIC Manager (Options → Reorganize → Project-wide) rewrites the project file structure to eliminate duplicates and orphaned references at the project level, but it does not touch the CFC chart folder metadata. It will therefore resolve chart-deletion drift caused by orphaned S7 objects, but will not resolve drift caused by an aborted CFC compile — which is the case observed in the source field report. The behaviour of the Reorganize function is documented in the STEP 7 V5.5 help system, accessible from SIMATIC Manager → Help → Contents.

Diagnostic Procedure

Before applying the deletion + recompile fix, run the following diagnostic sequence to confirm the cause and to capture a restorable state:

1. Capture a backup of the offline S7 program. In SIMATIC Manager, right-click the affected S7 Program under the AS station and select "Save As..." to export the S7 program to a backup folder. This export contains every FC, FB, DB, OB, SDB, and SFC referenced by the program and is the canonical recovery artefact for the procedure below.
2. Inspect the CFC chart folder. Open the CFC editor for the affected S7 program (right-click the S7 Program → Open Object → CFC charts). Note the list of charts present in the chart folder. Cross-reference each chart against the FC list in the S7 Program / Blocks container. The FC count should equal the chart count. If the FC count exceeds the chart count, the difference is the orphan FC set that needs to be deleted before the recompile.
3. Read the CPU diagnostic buffer. Connect online to the CPU (Online → Accessible Nodes → select the CPU). Open the "Diagnostic Buffer" and locate the most recent "Download error" entry. The buffer lists the exact block number and the SZL index that the CPU expected to receive. Record this for the verification step.
4. Compare the online and offline block lists. Open the online Blocks view (Online → Accessible Nodes → CPU → Blocks) and the offline Blocks view side by side. The online list reflects the last successfully loaded program; the offline list reflects the current engineering state. The phantom DB will appear in the online list only if the CPU still holds the previous program image. A direct block compare is available via "PLC → Compare..." in the online view.
5. Check the CFC compilation log. Open the CFC editor → Options → Logs → Compile Log. Look for entries marked "Error" or "Warning" with timestamps corresponding to the last chart modification. A typical error is "Chart xxx: FB yyy has no instance DB; cannot resolve call" — this is the originating condition.
6. Identify the CFC-generated FCs. The CFC compiler places its output in the FC range starting at the first free FC number. By convention, the FCs are contiguous and the block comments contain the prefix "CFC_". Filter the Blocks view by right-clicking the column header → Properties → enable "Block Comment" and search for the prefix. Record the FC numbers in the set to be deleted.

Resolution: Full CFC Recompile Procedure

The resolution consists of seven steps. Perform them in sequence; do not skip the verification at the end of each step.

1. Stop the CPU if in RUN. Open the online view of the CPU and switch it to STOP. Confirm the operating-mode LED transitions to STOP and that the diagnostic buffer records the mode change. A download to a CPU in RUN-P is permitted for individual blocks but not for the full S7 program required by this procedure. The S7-300/400 CPU operating-mode rules are documented in the Siemens Industry Online Support portal under the S7-300 / S7-400 CPU device manuals.
2. Open the CFC editor for the affected S7 program. In SIMATIC Manager, right-click the S7 Program under the AS station and select "Open Object" → "CFC". The CFC editor launches with the chart folder loaded. If multiple chart folders exist (one per S7 program), repeat the procedure for each.
3. Delete the CFC-generated FCs from the offline Blocks folder. In the SIMATIC Manager Blocks view (right-click S7 Program → Blocks), select every FC that was generated by the CFC compiler — typically the contiguous range beginning at FC60 or at the first free FC number after the system FCs (SFC0..SFC249). Use Shift+click to select the range, then right-click and choose "Delete". Confirm the deletion when prompted. The FCs to remove are exactly the ones with block comments starting with the prefix "CFC_".
4. Verify the deletion. After the deletion, the Blocks view should show no FCs above the system FCs. The CFC chart folder in the plant view is unaffected by this step — only the compiled output has been removed. The chart folder remains the source of truth for the next compile.
5. Run a full AS compile. Return to the CFC editor. Select the S7 Program node in the chart tree and choose "Chart → Compile" → "Full Compile" (not incremental). The full compile regenerates every FC and every supporting DB from the chart folder. Compile duration is proportional to the chart count; a 200-chart project typically takes 2–5 minutes on a modern ES. Watch the progress bar and the compile log for errors.
6. Verify the compile output. Open the Blocks view after the compile completes. The FC range should be repopulated, and the DB range should now contain a DB for every chart instance. The previously phantom DB (DB83 in the source report) should now be present in the offline Blocks folder. If it is not, the compile did not complete — check the compile log for "Error" entries and re-run the full compile.
7. Download the full program to the CPU. In SIMATIC Manager, right-click the AS station and select "PLC → Download". In the "Download to Target System" dialog, select the "Entire program" radio button. STEP 7 warns that the CPU will be stopped and the existing program overwritten. Confirm. The download transfers the freshly compiled FCs and DBs. The CPU remains in STOP after the download; restart it to RUN-P via the "Operating Mode" dialog or by a CPU operator-panel command.

Alternative Resolution Paths

If the CFC FC deletion + full recompile procedure does not resolve the issue, the following alternative paths have been validated in field conditions:

Alternative 1 — Project Reorganize + Selective Block Delete

If the chart folder is intact but the Blocks folder contains duplicates, the "Reorganize" function may be sufficient:

1. SIMATIC Manager → Options → Reorganize → select the project root → OK.
2. Open the S7 Program / Blocks view and identify any block flagged with a red "duplicate" icon.
3. Delete the duplicates (right-click → Delete).
4. Run a full AS compile (not incremental) and re-attempt the download.

Alternative 2 — Block Consistency Check

The "Check Block Consistency" function in SIMATIC Manager can be used to identify and resolve the cross-references at the FC/DB level:

1. Right-click the S7 Program / Blocks → Check Block Consistency.
2. STEP 7 lists every block with an inconsistency. For each entry marked "DBxxx referenced by FCxxx but does not exist", STEP 7 offers to delete the reference or to create an empty stub.
3. Choose "Delete reference" for the FCs that have no chart backing, then recompile and download.

Alternative 3 — AS Station Delete and Re-Add

If the chart folder itself is corrupted, the only recovery is to remove the AS station from the project and re-import it from the S7 program backup captured in the diagnostic step:

1. Right-click the AS station in the component view → Delete. Confirm the deletion.
2. Insert a new AS station (Insert → Station → SIMATIC 400 Station or SIMATIC 300 Station).
3. Right-click the new AS → Object Properties → set the CPU model and firmware version to match the original.
4. Import the S7 program from the backup: right-click the new AS → Insert S7 Program → From File → select the .s7p or unpacked S7 program folder.
5. Run a full compile and download.

Alternative 4 — Restore from S7 Program Backup

If the offline S7 program is intact and the issue is only in the online CPU image, restoring the offline backup to the CPU without touching the engineering project is the cleanest path:

1. In SIMATIC Manager → File → Retrieve → select the .s7p backup file.
2. Open the retrieved project, connect online to the CPU, and perform a full download (entire program).
3. Verify the CPU enters RUN and the diagnostic buffer no longer reports the missing DB.

Verification

After the resolution, the following checks confirm that the system has returned to a consistent state:

Preventive Measures

The following engineering practices minimise the likelihood of recurrence:

1. Always perform a full compile after chart deletion or restructuring. The CFC "Incremental Compile" option only emits the deltas; it does not reclaim the FC numbers of deleted charts. A full compile is the only way to renumber the chart-to-FC mapping cleanly. Set the CFC editor default to "Full Compile" via Options → Settings → Compile/Download → check "Always perform full compile".
2. Never delete or rename FCs/DBs outside the CFC editor. SIMATIC Manager block manipulation bypasses the chart-to-block mapping maintained by the CFC compiler. If a block number must be reserved or freed, use the CFC "Options → Chart Compile" settings or the PCS 7 "Master Data Library" to renumber consistently.
3. Use a source-controlled S7 program. The S7 Program / Sources folder (STL sources) provides a version-controlled view of the program that can be diffed between revisions. Enable the "Generate source from blocks" function as a pre-download hook to capture the compiled state alongside the chart folder.
4. Schedule a periodic full download of the AS. Some PCS 7 installations perform a full download of the AS once per quarter to reconcile any drift accumulated by incremental downloads. This is also a useful regression test for the OS tag list.
5. Enable the "Check before download" option in SIMATIC Manager. Options → Settings → Download → check "Always perform consistency check before download". This adds a few seconds to the download but catches the "phantom DB" condition at the engineering station before it reaches the CPU.
6. Maintain a documented chart lifecycle. Use the PCS 7 "Chart In/Out" process for chart modifications: Export the chart, modify, test, import the chart. The export/import step regenerates the chart-to-block mapping and forces a full compile at the chart level.
7. Maintain an S7 program backup policy. Capture an S7 program export (right-click S7 Program → Save As → .s7p) before every major chart restructuring. The export is the canonical recovery artefact for the "delete AS and re-add" procedure described in Alternative 3.

Related Error Scenarios

The phantom-DB condition is one of several incremental-download failure modes that affect CFC projects. The table below maps the field-observed error patterns to their root causes and to the recommended resolution path.

PCS 7 and AS-OS Engineering Considerations

In a PCS 7 V7/V8/V9 installation, the AS (Automation Station) and the OS (Operator Station) share a common project database. The S7 program compiled by the CFC editor on the AS side is mirrored to the OS tag list by the "OS Compile" step. The following points are specific to the PCS 7 environment and affect the resolution of the phantom-DB condition:

• AS-OS connection. The "AS-OS Connection" table in the component view (under the OS station) maps AS tags to OS faceplate instances. The mapping is keyed on the DB number of the chart instance. When the full AS compile regenerates the DBs, the DB numbers may change (if the chart-to-FC mapping was renumbered). The OS compile is required to update the AS-OS connection table; otherwise the operator faceplates display "Bad quality" for the affected tags.
• OS server redundancy. For redundant OS servers (OS Server 1 / OS Server 2), the OS compile must be run on each server independently. The AS-OS connection table is project-global, but the tag list is server-specific. Use WinCC Explorer → OS Project Editor → Compile OS on each server.
• Chart-level versus program-level compile. The CFC editor supports both chart-level incremental compile and S7-program-level full compile. The full AS compile is required to resolve the phantom-DB condition because the chart-level incremental compile will skip the orphan FCs and leave the block numbering unchanged. Set the CFC editor default to "Full Compile" before applying the fix.
• Version compatibility. The CFC version must match the STEP 7 version. Mismatched versions produce compile errors that are logged in the CFC compile log with the "Error" severity and that will not be resolved by a retry. Verify the version in CFC editor → Help → About against the STEP 7 version displayed in SIMATIC Manager → Help → About.
• PCS 7 APL (Advanced Process Library) blocks. Charts that use the PCS 7 APL block library generate additional instance DBs for the APL state machine. These DBs are not visible in the standard Blocks view; they are managed by the APL block and the CFC chart folder. A full AS compile is required to regenerate them after a chart modification.

CPU and Firmware Constraints

The full-download procedure has specific constraints on the CPU model and firmware version. The table below summarises the relevant constraints for the S7-300 and S7-400 CPU families commonly deployed with CFC projects.

For the S7-1500 family, CFC is not supported — the equivalent function is provided by the TIA Portal "Program Flow" and "LAD/FBD" editors plus the SCL compiler. Incremental download on the S7-1500 follows a different mechanism and does not exhibit the phantom-DB condition described in this article. If migrating a CFC-based S7-400 project to an S7-1500, refer to the TIA Portal migration documentation for the equivalent translation of the chart logic.

FAQ