Troubleshooting Siemens TDC CFC Compilation Errors on T400 Memory

1. Problem Overview

Engineers maintaining a SIMATIC TDC station with FM 458 function modules and a T400 technology module frequently encounter a non-recoverable compile error after the controller has been in continuous service for several years. The error appears in the CFC editor (part of the D7-SYS option package on STEP 7) immediately after a code change and before any download is attempted.

The characteristic symptom reported in the field is:

• The CFC program opens online without issue; the controller is still running the last downloaded configuration.
• Any modification in the CFC editor (insert, delete, parameter change, sheet add/remove) triggers a dialog reading "The change memory of the memory module / T400 is defective."
• A full offline compile (menu Chart → Compile or the toolbar button) aborts at roughly 28 % progress with the same error message and the chart remains in a non-consistent state.
• Erasing the change memory (right-click chart → Chart → Compile / Download → Reset change memory) does not clear the fault; the next compile still fails.

When this condition occurs, no further code change can be downloaded to the TDC rack until the root cause is corrected. The fault is software-side, not a hardware failure of the T400 or its memory submodule (despite the wording of the dialog).

2. Root Cause Analysis

The "change memory defective" message is raised by the D7-SYS code generator when it cannot reconcile the imported block-type library set with the version of the runtime firmware currently configured for the TDC station. The two conditions that most commonly produce the failure on a long-running TDC station are:

1. Library version drift. The CFC was originally compiled against an earlier release of the D7-SYS block library (FB-, FC-, DB-type blocks delivered with the option package). After STEP 7 / D7-SYS service packs or hot fixes were applied on the engineering station, the compiled runtime information in the project's archive directory (S7Proj\<Project>\Global) no longer matches the system blocks in the installation directory (S7CFC). The code generator therefore writes a "defective change memory" marker to prevent a partial compile from being downloaded.
2. Wrong library search path. The compiler can be pointed either at the installation directory (system data) or at the project archive (consistency with what is already on the rack). If the path does not match the actual project layout, blocks are resolved against an inconsistent type catalog and the change-memory area becomes unreachable.

3. Confirming the Fault Path

Before changing anything in the project, capture the current configuration so the original state can be restored if the recovery does not succeed.

Compare the two lists. A version column shows the release of each block (for example, FB 1860 v2.0.3 for FM 458 function blocks). If even a single block version differs between the two panes, the compile path is inconsistent and the code generator will refuse to write the change log.

4. Library Path Configuration

The library path tells the CFC compiler where to resolve the system data blocks (SDB), function blocks (FB/FC), and data blocks (DB) used inside the charts. There are exactly two valid settings:

5. Library Update Procedure

The library update is a controlled operation that overwrites the project archive copy of each block with the version installed on the engineering station. It is the standard recovery for a project whose import copies have fallen behind the system installation.

1. Close all open CFC/SFC charts in the project.
2. Open Options → Block Types. The dialog opens with the Block types in the S7 program list on the right and the Block types on the programming device / PC list on the left.
3. In the right-hand list, select the first block whose version on the left is higher. For TDC stations running FM 458 firmware v2.0.3 this is typically the FM458 family of FBs.
4. Click New Version. The right-hand entry is updated to match the left-hand version, and a small red marker indicates the imported block has been refreshed.
5. Repeat for every block that shows a version mismatch. Hold the <Shift> key to select a contiguous range, or <Ctrl> for individual blocks.
6. When all blocks are aligned, click OK to commit. The dialog will display a summary of the updated blocks; record this list for the maintenance log.

6. Cross-Reference: D7-SYS Service Pack Levels

Library mismatch is most often introduced by installing a service pack on top of the original D7-SYS release. The version strings that appear in the Block Types dialog give away the service pack level. The following table documents the levels commonly seen in plant-floor archives:

When the engineering station is patched up to hotfix 4 and the project archive still contains the original V6.0 base blocks, the change-memory area reserved in the T400 is smaller than the area the new code generator needs, hence the "defective" message at 28 % compile progress (the point at which the change log is finalised).

7. Resolving the 28 % Compile Stall

Once the libraries are aligned, the 28 % stall resolves on the next compile. If the compile still aborts, perform the following sequence in order, testing after each step:

1. Switch the Options → Customize → Compile/Download library path from From Installation to From archive (or vice versa) and recompile.
2. Run Chart → Check chart consistency on every chart in the project. Empty or orphaned block instances (blocks with no inputs wired and no outputs connected) can stall the code generator. Remove any such blocks, save the chart, and recompile.
3. Confirm the run-group assignments under Chart → Run group → Edit. A run group with no assigned charts, or two run groups with overlapping cycle times on a T400, produces a code-generation error before the change log is finalised.
4. Verify that no chart contains an instance of a block type that has been removed from the D7-SYS installation. Use Options → Block Types → Where used to locate the reference.
5. Re-import the system data: in the SIMATIC Manager, right-click the TDC station → PLC → Compile and Download Objects. Re-run the CFC compile only after the system data compile completes without warnings.

8. Recovery Procedure After Library Corruption

If the project archive itself has been damaged (for example, by an interrupted save or by deletion of an sdblock), the CFC compile will report a missing-system-data-block error even when all imported blocks are present. Recovery steps:

1. Close the project in the SIMATIC Manager.
2. Open Windows Explorer and navigate to C:\Program Files\Siemens\Step 7\S7Proj\<Project>\Global.
3. Compare the *.sd? block count with the number of system data blocks listed in the SIMATIC Manager System Data container. Missing SDBs can be regenerated by selecting the SDB container and pressing F5, then accepting the "generate system data blocks" prompt.
4. Re-open the project and repeat the library alignment procedure in Section 5.

9. Hardware Verification: When the T400 Is Actually Faulty

The T400 reports its own hardware state through diagnostic blocks (DB 2 / DB 3 in the T400 system data). If the library alignment and compile recovery above do not clear the "change memory defective" dialog, the T400 module itself should be examined before being replaced.

Only after all four diagnostics pass should the conclusion be reached that the dialog text is misleading and the project archive is the only fault source.

10. Verifying the Fix

After completing the library update and the compile, perform the following acceptance checks before downloading the new code to the live TDC station:

1. Open the chart that previously failed. The status bar should show No errors.
2. Trigger a full offline compile (Chart → Compile → Charts as program). The progress bar should reach 100 % and the log should end with Compile completed without errors.
3. Open Options → Customize → Compile/Download and confirm the library path setting was preserved.
4. In the SIMATIC Manager, open the S7 program and run PLC → Check Block Consistency. No blocks should be flagged with time-stamp conflicts.
5. Download the change to the T400 (Chart → Download → To Target System). The T400 should accept the change without re-entering the "defective memory" state.

Once the change is downloaded, the CFC can be modified again at any time. The "defective change memory" message will not return as long as the D7-SYS installation and the project archive stay aligned. Apply a project-version-control rule: every D7-SYS service pack applied to the engineering station must trigger a corresponding New Version pass on every active TDC project.

11. Preventive Maintenance Recommendations

• Pin the D7-SYS version. Use a dedicated engineering station image for each TDC project archive; do not share the image between projects with different service-pack levels.
• Archive after every change. Use STEP 7's Archive function (not a simple file copy) so the Global subdirectory is frozen together with the S7 program.
• Log every hotfix. Maintain a change log that records which D7-SYS hotfix was installed and which project was recompiled. This is the single most useful artefact when the next "change memory defective" dialog appears three years later.
• Test compile on a clone. Before applying a D7-SYS service pack to a production engineering station, duplicate the project to a sandbox and run the library update there. Only after a clean compile should the same update be performed on the production station.

12. Frequently Asked Questions