Why PCS 7 Projects Increase in Size After 'Save As With Reorganization (Slow)'

In SIMATIC PCS 7 (including V6.1, V7.x, V8.x), executing 'File -> Save As... With Reorganization (Slow)' on a large project can paradoxically result in a project folder that is larger in disk size than the original. While reorganization purges deleted objects, defragments Sybase tables, and frees deleted records, the database engine creates fresh contiguous transaction logs, standard allocation cluster blocks (4 KB to 64 KB extents), and uncompressed cross-reference indexes (.dbf, .xrf). The actual reduction in project size only becomes evident when the project is compressed into a .zip archive via SIMATIC Manager 'Archive'.

Database Architecture of STEP 7 and SIMATIC PCS 7 Projects

A SIMATIC PCS 7 project is not a single file; it is a complex relational database structure comprising hundreds of folders and thousands of interconnected binary files. Under the hood, STEP 7 Classic utilizes an embedded Sybase / dBASE relational database engine:
* Relational table containers (.dbf, .dbt) storing symbol tables, block interfaces, and hierarchy trees.
* Index files (.cdx, .idx) enabling high-speed searches across process objects.
* Cross-reference databases (XRF / hrs tables) mapping signal connections and block interconnections.
* CFC chart database files (.cft, .clg) maintaining graphical block positions and execution sequences.

During normal engineering activities (deleting blocks, modifying charts, renaming tags), the database engine does not physically shrink disk files. To maximize editing speed, it simply marks deleted records with a 'tombstone' deletion flag while keeping physical file allocations intact. Over months of commissioning, project directories accumulate significant database fragmentation and orphaned records.

The Internal Mechanics of 'Save As With Reorganization'

SIMATIC Manager provides two save modes:
1. Normal Save As: Copies files byte-for-byte to a new folder, preserving all fragmented space, deleted record blocks, and historical file padding.
2. Save As With Reorganization (Slow):
- Initializes a brand-new, empty database structure in the target directory.
- Iterates through every active object in the source project.
- Copies only active, referenced records while completely discarding marked-for-deletion data.
- Rebuilds all cross-reference tables, symbol pointers, and CFC chart connection tables from scratch.
- Re-indexes all internal Sybase relational keys to restore binary database health.

Why Disk Footprint Increases While Logical Data Shrinks

Engineering teams often report alarm when inspecting the file properties in Windows Explorer immediately after a multi-hour reorganization:
* Original fragmented project folder: 1.20 GB
* Newly reorganized project folder: 1.35 GB (An apparent increase of 150 MB!)

This apparent paradox occurs due to filesystem and database allocation behaviors:
1. Database Extent Pre-Allocation: When the Sybase engine recreates index and data tables, it allocates fresh, contiguous database extents in standard chunks (e.g. 64 KB clusters). Empty tables or partially populated tables reserve standard minimum block sizes on the Windows NTFS filesystem.
2. Clean Cross-Reference Index Regeneration: During normal operation, some corrupted or outdated cross-reference indexes may have stopped tracking certain relationships. Reorganization reconstructs full, comprehensive .xrf files, which may contain more complete indexing trees than the damaged source.
3. Uncompressed Database Zero-Padding: Newly initialized database tables contain extensive zero-padded blocks. Windows Explorer reports the uncompressed logical file size.
4. The True Test: Compressed Archive Size: When the original project and the reorganized project are both archived into standard PKZip archives (File -> Archive in SIMATIC Manager), the reorganized project consistently compresses to a drastically smaller .zip footprint (often 30% to 50% smaller) because zero-padded blocks compress almost to zero bytes.

Reorganization Impact Comparison Matrix

The following matrix compares standard projects against reorganized projects across key metrics:

Metric / AttributeFragmented Project (Before)Reorganized Project (After)Post-Archive (.zip)Windows Folder SizeVariable (Fragmented)Often slightly larger (+5% to +15%)N/A (Single archive file)Compressed Archive SizeLarge (Contains junk data)Significantly smaller (-30% to -50%)True measure of data reductionDatabase IntegrityRisk of orphaned pointers100% verified relational integrityOptimal baseline for backupsCFC Compilation SpeedSlower (Scans deleted records)Optimized (Direct sequential reads)N/ADownload ImpactBaselineDoes NOT require full AS STOPSafe for changes-only download

Step-by-Step Best-Practice Procedure for Project Reorganization and Archiving

Follow this standardized procedure to optimize and verify project health:
1. Prepare the Engineering Station:
- Close all open instances of CFC, SFC, HW Config, NetPro, and WinCC Explorer.
- Restart the engineering PC if background STEP 7 processes (s7tgtopx.exe, s7xpcomx.exe) remain lingering in Task Manager.
2. Execute Save As With Reorganization (Slow):
- In SIMATIC Manager, open the target project.
- Select File -> Save As....
- Check the box With Reorganization (Slow).
- Assign a new project name on a local solid-state drive (C:\ or D:\, never a network mapped drive).
- Click OK. Allow the process to complete without interruption (this may take 15 to 90 minutes depending on project size).
3. Verify Logical Compilation Integrity:
- Open the newly reorganized project.
- Open a CFC chart and execute Compile -> Scope: Changes only.
- Confirm that the compiler recognizes the project as identical and does not demand a complete code regeneration or AS stop.
4. Archive the Clean Project:
- In SIMATIC Manager, select File -> Archive.
- Select the reorganized project and choose the target archive location.
- Compare the final .zip archive size against older project archives to confirm true physical data reduction.

Verification

Verify that reorganization restored project health and performance:
1. Open the project in SIMATIC Manager: Navigate through Component View and Plant View, verifying rapid tree expansion without database hesitation.
2. In CFC, open the Block Types dialog (Options -> Block Types): Click Clean Up. Confirm that the operation finishes cleanly with zero database mismatch warnings.
3. Compare compressed archive sizes: Confirm the reorganized .zip archive is significantly smaller than the pre-reorganization archive.
4. Execute an online comparison with the running AS controller (CFC -> Compare): Confirm that CFC charts report 100% online/offline code identity.

Limitations and Operational Precautions

Never execute 'Save As With Reorganization' directly across local area network (LAN) shares, VPN tunnels, or USB flash drives; network packet latency or dropouts will corrupt database table creation.
Do not terminate SIMATIC Manager via Task Manager while reorganization is running; doing so results in a corrupted target database.
Reorganizing a Multiproject should be executed on individual sub-projects first, followed by reorganizing the Multiproject container.

Engineer FAQ

Does 'Save As With Reorganization' force an AS STOP on the next download?

No. Reorganization restructures the offline relational database tables on the Engineering Station. It does NOT modify the compiled machine code checksums, block interfaces, or runtime sequence. S7-400 controllers can continue receiving changes-only downloads in RUN mode.

What is the difference between 'Save As With Reorganization' and 'Reorganize' from the File menu?

'File -> Reorganize' reorganizes the project in-place within its existing folder. 'File -> Save As With Reorganization' creates a brand-new directory structure, ensuring that if anything fails during the process, the original project remains completely untouched. 'Save As' is the strictly recommended method.

Can reorganization fix corrupted Shared Declarations?

Yes. Reorganization purges broken pointers and rebuilds relational lookup tables, frequently resolving 'Shared Declarations not available' or orphaned enumeration errors.