Recovering Deleted SIMATIC CFC Charts from Compiled FC, FB, and DB Blocks

1. Problem Definition and Scope

When the CFC source diagrams in a SIMATIC S7 or PCS 7 project are deleted from the engineering project but the compiled blocks (FCs, FBs, and instance DBs) have already been downloaded to the CPU, the program continues to execute. The PLC still runs, but the engineering view of the original chart topology, the runtime group assignments, the inter-chart signal wiring, and the chart-level task binding are gone. Engineers then ask whether the compiled artefacts on the PLC can be used to reconstruct the original CFC diagrams.

The answer is unambiguous: the compiled MC7 code in the downloaded blocks is a one-way projection of the original chart. It does not preserve the block diagram layout, the chart instance names, the engineering comments, the I&C tag references, or the runtime group / OB task binding. What it does preserve is the algorithm in the form of a list of MC7 instructions that implement the same Boolean, arithmetic, comparator, and timer operations that the chart evaluated in the original cycle.

Three distinct recovery outcomes need to be separated up front:

1. CFC chart recovery (the graphical diagram). Not possible from compiled code alone. There is no Siemens tool, option, or documented third-party converter that accepts MC7 / STL / LAD / FBD and emits a CFC chart.
2. Algorithm recovery in STL / LAD / FBD. Possible by reading the block back into STEP 7 via PLC → Upload Station to PG and viewing it in any of the standard editors. The chart topology will not be present; the algorithm is functionally equivalent.
3. Program semantics recovery from collateral project artefacts (S7 archives, STL sources, version control, I/O lists, loop sheets, P&IDs). Only feasible when at least one of these collateral sources still exists.

This article explains exactly what the CFC compiler emits, why a true CFC restoration from compiled code is not technically feasible, and what recovery paths are available when the original .s7p or PCS 7 project archive is lost. The procedure is also relevant when the chart deletion is partial (single chart removed) and when only a TIA Portal project backup exists.

2. What the SIMATIC CFC Compiler Emits

SIMATIC CFC (Continuous Function Chart) is the graphical configuration tool described in the SIMATIC CFC for S7 manual and is the primary programming environment inside the SIMATIC PCS 7 process control system. The CFC editor places blocks from a type / instance library onto chart sheets, wires their inputs and outputs, and groups the resulting charts into runtime groups that are bound to OB task cycles (OB35, OB36, OB37, OB38, or OB1).

When the user executes Charts → Compile, the CFC compiler walks the chart graph and emits the following block types into the S7 program:

The choice between FB and FC as the chart's compiled container is controlled under Tools → Settings → Compilation / Download in the CFC editor. By default, charts are compiled into FBs with associated instance DBs. The same dialog also controls whether the compiler emits MC7 code, an STL source, or both. According to the Siemens Support entry on compilation settings, the dialog additionally controls whether unused DBs and FCs are reserved for use by CFC, which is relevant when a separate tool (e.g. SCL or STL) is used to maintain code that the CFC compiler must not overwrite.

3. CFC Chart Layout and Runtime Model Internals

A CFC chart is a flat dataflow graph: each node is a block instance, each edge is a signal connection. The compiler linearises the graph according to the signal-dependency order and stores the result as a sequence of MC7 block calls and parameter assignments. The original graph topology — the icon positions, the sheet number, the runtime group membership, the task binding, the phase offset within the OB cycle — is metadata that lives in the CFC project database, not in the compiled block.

Runtime groups are the unit of OB binding. Each runtime group is associated with one OB (typically OB35 at 100 ms for the fast group, OB36 at 200 ms for the standard group, etc.). Within a group, charts are arranged in an execution sequence that the engineer can edit manually. When the compiler runs, it emits the OB code that calls each runtime group in the configured OB and that calls each chart in the configured sequence. The chart instance name is not in this call list; the call site is a numeric FB or FC reference.

The runtime properties of each chart — installation state (installed / not installed), runtime attributes (sequential / cyclic), phase offset, and the chart-level monitoring attributes — are stored in the CFC schedule table. They are not in the compiled block. After deletion, these properties must be re-derived from the process documentation or from the operator station's view of the running CPU.

4. Why Reverse-Engineering the CFC Diagram from MC7 Is Impossible

The MC7 instruction set executed by the S7 CPU is the same MC7 generated for any STL, LAD, or FBD program. It contains bit, word, and floating-point operations, accumulator moves, and block calls. A CFC chart is essentially a flat dataflow graph of function calls whose execution order has been linearised by the compiler according to the chart's signal dependencies and the chart-level execution sequence. Once linearised, the original graph is not recoverable from the linear sequence.

When the compiler translates a chart, it performs the following lossy transformations:

• Layout: block-icon position, I/O pin position, and inter-chart wire routing are stripped. They never enter the MC7 stream.
• Comments and I&C tags: chart-level comments, loop tags, and operator faceplate references live in the project database, not in the block.
• Runtime model: runtime group names, the OB that owns each group, and the cyclic phase offset live in the CFC schedule table.
• Type / instance split: generic block-type references (for example the standard PCS 7 type library members CTRL_PID, MOT_SPEED, and VALVE_ANA) are resolved to absolute FC/FB numbers. Once compiled, the original type / instance pair is not recoverable from the block header alone.
• Signal connections: an output of one chart driving an input of another chart is collapsed to a symbolic or absolute address in the linear MC7 sequence. The original chart-of-origin is not in the instruction stream.

The only information that survives in the compiled block is the runtime data structure and the instruction sequence. Reading the block back into STEP 7 (on-line via PLC → Upload Station to PG) yields a view of the algorithm in STL, LAD, or FBD. This view is functionally equivalent to the chart's behaviour, but it is not a CFC chart and cannot be saved as one.

5. Compiled Block Layout and MC7 Binary Limits

Each compiled chart block contains a standard S7 block header followed by the MC7 instruction sequence. The block header stores:

• Block number (FC nnn / FB nnn / DB nnn)
• Author, family, name, and version fields (set by the compiler; the chart name is not in the block header)
• Code timestamp and interface timestamp (changed on every recompile)
• Interface description (IN, OUT, IN_OUT, STAT, TEMP variables with type and initial value)

The interface description in the block header is the only metadata that survives from the original chart's I/O list. The variable names, types, and absolute or symbolic addresses can be read by any S7 tool. The chart-specific properties (chart number, sheet position, runtime group membership, task binding, runtime properties, S7_m_c attribute, HMI visibility, OS reference) are not stored in the compiled block.

Instance DBs are flat binary containers. The PCS 7 instance DB for a CTRL_PID block, for example, contains the setpoint, process value, manipulated value, alarm limits, and tuning parameters as named members. The variable names and types are in the DB header, so a programmer can read them with the S7 block editor. The original chart name (for example TIC_1001) is not in the DB; the mapping from DB to chart must be re-derived from the project-level documentation.

There is no documented Siemens tool, option, or third-party plug-in that accepts an MC7 stream, an FC/FB source, or a downloaded DB and produces a CFC chart. Siemens' own support policy for this scenario is to restore the project from a backup, not to decompile the running program.

6. Recovery Path A — Restoring from STEP 7 / PCS 7 Project Archives

The first place to look for a lost CFC project is the engineering workstation's archive directory. STEP 7 and PCS 7 projects can be saved as compressed archives in several formats:

Procedure to recover from an S7 archive:

1. Search all known file shares, USB drives, backup tapes, and engineer laptops for any file with a timestamp close to the original download date and a .s7p, .zip, .s7l, .s7pmproj, or .ap1x extension.
2. Copy the candidate archive to a working directory; do not open it in place.
3. In SIMATIC Manager, select File → Retrieve (in German: Datei → Dearchivieren), browse to the archive, and choose a target directory.
4. Open the retrieved project and confirm the CFC charts are present under S7 Program → Charts.
5. Compile the charts (Charts → Compile → All) and compare the generated block numbers against the on-line block list to verify it is the correct project.

7. Recovery Path B — Restoring from Version Control and Source Files

Many engineering teams store the STEP 7 / PCS 7 project in a version control system (SVN, TFS, Git LFS, or a network share with periodic zips). If the project was checked in before the chart deletion, the recovery path is straightforward:

1. Identify the most recent commit or backup prior to the chart deletion event.
2. Check out a clean working copy of the project at that revision.
3. Compile the project and compare the online block list against the working copy to confirm functional equivalence.
4. Use the change history to identify the commit that introduced the deletion, then merge the deletion into the working copy only after the operation team has confirmed a planned maintenance window.

For PCS 7 projects, the CFC source is also commonly stored as STL sources (.awl) generated during Charts → Compile → Source. These sources are textual and can be diffed with normal text tools. They can be re-imported into a fresh project via S7 Program → Sources → Insert.

It is also worth searching the engineering workstation for the auto-save and temporary project files that STEP 7 and PCS 7 create during long edit sessions:

• %APPDATA%\Siemens\Automation\*.s7p and similar temporary folders
• %LOCALAPPDATA%\Temp\ directories used by SIMATIC Manager
• Auto-recovery backups written by CFC when the editor closes abnormally
• Windows volume shadow copies of the project directory

Even a partial STL source (one that misses a few charts) is more useful than no source at all: it confirms the chart inventory, the variable names, and the code timestamp, and the missing charts can be reconstructed from the on-line block list and the STL source files that did survive.

8. Recovery Path C — Re-Engineering from the Online Block List

When no project archive, source file, or version-controlled copy is available, the only path is to re-engineer the program from the on-line CPU and the process documentation. The sequence is:

1. Use PLC → Upload Station to PG in SIMATIC Manager to upload the running S7 program. This creates a project with all online FBs, FCs, DBs, and system data. The CFC source layer is empty.
2. Read each block in STL and document the algorithm: variable names, types, and the sequence of MC7 instructions. Use the block header interface description (IN, OUT, IN_OUT, STAT, TEMP) as the chart I/O list.
3. For each FB, identify the underlying block type. The compiler resolves the original type / instance pair to a single FB. The instance DB stores the static data. The original block-type semantics (e.g. CTRL_PID for closed-loop control, motor and valve block types from the standard PCS 7 library) are not preserved at the binary level; the engineer must re-derive them from the variable names and the structure of the algorithm.
4. Open the I/O list, P&ID, motor list, and loop sheets for the process. Cross-reference each chart's I/O with the physical I/O and the HMI faceplate tags. Use the PCS 7 / CFC type library to re-create the equivalent chart types and re-place them on new chart sheets.
5. Re-wire the charts using the original I/O from the recovered FB interfaces. Re-create runtime groups and OB bindings. Compile and download the re-engineered charts to a standby CPU for testing before the production cutover.

This path is labour-intensive but feasible. The most expensive step is identifying the original block types: the FB code is a flat MC7 sequence and the type / instance split has been lost. Engineers experienced with the PCS 7 type library can usually re-derive 80 to 90 % of the original types by matching the I/O signature against the standard library. The remaining 10 to 20 % is usually custom block types (vendor-specific or plant-specific); these must be re-derived from the STL algorithm and the original type documentation.

Decision tree for the three recovery paths:

9. Compiler Settings That Affect What Survives a Compiled Chart

Even when charts are deleted, certain compiler settings leave traces in the project that aid later recovery. The relevant dialog is Tools → Settings → Compilation / Download in the CFC editor. The same dialog also controls whether FBs and FCs are reserved for use by CFC, whether unused DBs and FCs are left untouched, and whether the compiler emits MC7 code, STL source, or both, as described in the Siemens Support entry on compilation settings.

The strongest recovery-enabling configuration is to enable Generate STL source for every chart and to commit the project to a version-controlled repository on every download. With these two habits in place, even a catastrophic chart deletion can be reverted in minutes.

10. Best Practices to Prevent Future CFC Chart Loss

Once the recovery is complete, the following engineering hygiene rules should be enforced for the project team:

• Mandatory archive on every download. Before any Charts → Compile + Download cycle, archive the project with File → Archive to a versioned directory or to a network share that is itself backed up.
• Generate STL sources for every chart. In Tools → Settings → Compilation / Download, enable the option to emit STL source files. These files survive in the project and can be re-imported into a fresh project.
• Use a version control system with locking. SVN or Git LFS with periodic commits gives both a recovery point and an audit trail of who changed what.
• Maintain an off-line read-only backup. A daily zipped copy of the entire project directory on a separate physical machine, off the engineering network, protects against ransomware and disk failures.
• Restrict chart deletion rights. CFC does not prompt for confirmation when a chart is deleted from the project tree. Restrict the operating-system or SIMATIC Manager user rights so that the engineering directory is write-protected for users who do not need deletion rights.
• Cross-reference with the OS server. In PCS 7, the Operator Station (OS) server holds a parallel project with the faceplate references. Discrepancies between the OS and AS project are usually caught by the OS compile, which can be used as an independent verification that the AS charts are intact.
• Document the chart inventory. Maintain a separate spreadsheet or database that lists every chart, its instance name, its runtime group, and its task binding. This list is independent of the project file and survives any project-level loss.

11. Verification Checklist After a Recovery

After any of the three recovery paths above, the engineer must verify that the restored program is functionally equivalent to the running CPU. The following checks should be performed before the recovered project is downloaded to a running CPU:

1. Block list comparison. Compare the on-line block list (FB, FC, DB, SDB, SFB, SFC counts and numbers) against the compiled offline project. The lists must match exactly.
2. Interface comparison. For each FB, compare the IN / OUT / IN_OUT / STAT / TEMP variable list between the online block and the offline block. A mismatch indicates the wrong project or a partial recovery.
3. OS / AS consistency check. In PCS 7, run OS Project Editor → Compile OS. Any unresolved tag references will be flagged.
4. Cross-reference. Use Options → Reference Data → Display in SIMATIC Manager to verify that every input and output of the recovered chart is reachable from the expected upstream and downstream charts.
5. Runtime group simulation. Set the CPU to STOP, switch to Process Mode in the CFC editor, and watch the chart-level runtime. All charts should report OK with the expected cycle time.
6. Process I/O walk-down. With the operator on the panel, force each chart's inputs and outputs one at a time and confirm that the physical process responds as expected.
7. Code timestamp check. Verify that the timestamp on each recovered FB matches the timestamp on the corresponding online block. A mismatch indicates a stale archive.
8. Checksum check. Use the S7 block consistency check (PLC → Check Block Consistency) to confirm that all on-line blocks are consistent with the offline project.

12. FAQ