Clean Up Unused CFC Block Types Before Assessing S7-414 Data Memory

Use CFC's documented block-type cleanup to identify unused engineering objects, but do not assume it will release the required CPU data work memory. The second cleanup list can include blocks called indirectly by other blocks, so absence from a CFC chart is not proof that a block is dispensable. For the reported S7-414 shortage of about 500 kB, measure the relevant memory before and after a justified change and distinguish engineering cleanup from online memory reclamation.

Identify the Memory Shortage

The reported requirement is to release approximately 500 kB of data work memory without changing the S7-414 CPU. The exact CPU order number, firmware, PCS 7 release and CFC version are not supplied.

Record the actual memory category and available capacity for that CPU, plus the engineering and online program state. A request about data memory should not be answered with a presumed reduction in code or disk-project size.

The procedure below is documented in CFC for SIMATIC S7 V9.0 SP1, section 10.5.7; match it to the installed component before applying it.

Documented Block-Type Cleanup

Work in a recoverable engineering copy and review dependencies before confirming deletion.

Open Options > Block Types... in the CFC editor.
Select Clean up to review the two consecutive cleanup dialogs.
In Clean up blocks in CFC, review types present in CFC data management but unused in the charts; no chart instances exist for those types.
In Clean up blocks in block folder, assess types outside the CFC chart folder separately.
Preserve any type used by another block, even if it appears in the second list. Delete only the reviewed dispensable selection with OK.

The manual explicitly warns about indirect calls and illustrates a remaining helper block called by another block. See the documented procedure.

Assess the Effect on CPU Memory

Cleanup and memory reduction are separate outcomes. After the reviewed offline change, check the appropriate compilation results and memory information before deciding whether a CPU change is necessary.

Prepare any online deployment using the applicable download procedure and outage/rollback plan. Do not delete online blocks simply to make the used-memory number fall. Record which objects changed and which memory category changed.

If the result does not meet the 500 kB data-memory requirement, the remaining solution needs a program and data-storage assessment. No particular block, data structure or saving is identified from the available information.

Verification

First confirm that only the intended engineering types were removed and that needed dependencies remain. Then compile under the applicable process and inspect errors and memory usage for the exact target.

After an approved download, compare online data-work-memory capacity with the original baseline and test the affected functionality. A shorter offline block list does not prove that data work memory increased.

Limitations and Operational Precautions

Neither the actual memory consumers nor a validated saving are supplied. The documented cleanup is useful, but its ability to free approximately 500 kB of data work memory remains unestablished.

Maintain a recoverable backup and dependency record. A block absent from charts can still be called from another block; deleting it can make the program incomplete. Confirm CPU download and availability requirements rather than assuming that an engineering cleanup is operationally neutral.

No fixed memory-saving amount, safe-to-delete block list or laboratory validation is claimed.

Engineer FAQ

Can every block in the second list be deleted? No. Check indirect dependencies.

Does a type with no CFC instances prove the entire application does not use it? That conclusion cannot be drawn for the offline block-folder list.

Is 500 kB recoverable by this procedure? The available information does not establish that.