Investigating STRUCT POOL DB Allocations and CPU Work Memory Shortages in SIMATIC PCS 7

A STRUCT POOL data block (such as DB85 occupying up to 65,400 bytes) is an internal system data block automatically generated by the SIMATIC PCS 7 Continuous Function Chart (CFC) compiler to marshal structured variables across charts and execution groups. Because SIMATIC S7-400 CPUs impose a strict maximum data block limit of 64 KB (65,534 bytes), a bloated STRUCT POOL DB consumes valuable CPU data work memory. To alleviate memory pressure, engineers must identify and prune wide structure interconnections in CFC, compress work memory via Module Information, clean up unused block types, and if necessary evaluate an automation station upgrade.

Executive Summary

During continuous commissioning or substantial program expansion of a SIMATIC PCS 7 project, automation engineers may encounter critical work memory utilization warnings exceeding 95% in the automation station (AS). Inspection of the offline or online SIMATIC Manager Block folder often reveals large data blocks—most notably DB85 or high-numbered DBs spanning up to 65,400 bytes—labeled as STRUCT POOL DB. Because S7-400 CPUs allocate work memory dynamically into separate code and data partitions, uncontrolled expansion of internal compiler pool DBs risks download aborts, memory compression stalls, and unrecoverable download stop conditions during online delta compilation. This technical article details the internal mechanics of STRUCT POOL DBs, explains how the CFC compiler allocates them, and provides actionable remediation workflows.

Root Cause Analysis: Why Does the CFC Compiler Generate STRUCT POOL DBs?

In SIMATIC PCS 7, the Continuous Function Chart (CFC) engineering tool abstracts complex low-level Step 7 code into graphical block interconnections. When an engineer connects technological function blocks (such as Advanced Process Library MotL, VlvL, or custom user blocks) using structured variables (STRUCT data types containing multiple sub-elements or arrays) across different charts or runtime groups, the compiler cannot pass these structures directly through CPU accumulation registers.

Instead, the CFC compiler implements an automated marshaling mechanism:

Pool Generation: The compiler reserves specific DB ranges (typically configured under Chart Reference Data or Compiler Options) and creates a centralized buffer called the STRUCT POOL DB.
Address Mapping: Each structure interconnection is assigned a specific byte offset within the STRUCT POOL DB.
Runtime Copy Routines: System helper FCs or runtime routines copy data from source block output structures into the pool DB, and subsequently unpack them into target block input structures during the same cyclic execution sequence.
Size Boundaries: Because the classic S7-400 architecture limits any single data block to 65,534 bytes (64 KB minus system header overhead), an engineering project with thousands of structured interconnections quickly pushes a single STRUCT POOL DB to its absolute architectural boundary (~65,400 bytes), while consuming nearly 16% to 25% of the total data work memory in smaller CPUs.

STRUCT POOL DB Architectural Characteristics

The STRUCT POOL DB exhibits distinct operational characteristics compared to standard instance data blocks:

System Ownership: Unlike instance DBs tied to a single FB, the STRUCT POOL DB is fully owned and managed by the CFC compiler. Engineers must never modify, renumber, or manually edit the contents of this DB in the STEP 7 LAD/FBD/STL editor.
Dynamic Recompilation: When charts are compiled, the CFC compiler evaluates all active structure interconnections. If charts or interconnections are deleted, the compiler reorganizes and shrinks the STRUCT POOL DB upon an Entire Program compilation.
SFC 22 Creation vs Compiler Generation: While dynamic DBs can be generated programmatically via system function SFC 22 (CREAT_DB), standard PCS 7 STRUCT POOL DBs (such as DB85) are compiled offline and downloaded as part of the AS program image.

Diagnostic Procedure: Tracing and Reducing Work Memory Consumption

To diagnose and resolve work memory exhaustion related to STRUCT POOL DB allocations, follow this rigorous engineering workflow:

Analyze Chart Reference Data:
* In SIMATIC Manager, select the CFC Chart folder.
* Navigate to Options -> Reference Data -> Display.
* Select Block Types and Structure Interconnections to identify all global structures shared across charts.
Identify Overly Wide Interconnections:
* Search for large technological structures passed between blocks when only one or two scalar variables (e.g., a single boolean permissive or real feedback value) are actually utilized by the receiving block.
* De-interconnect wide technological structures and replace them with direct scalar interconnections (e.g., connect MotL.P_Rdy instead of passing an entire technological status structure).
Clean Up Unused Block Types:
* Open any CFC chart and navigate to Options -> Block Types.
* Review the chart folder blocks list and click Clean Up.
* This purges all orphaned block types and unreferenced system structures from the AS block container.

Defragmenting and Compressing CPU Work Memory

Online delta downloads leave obsolete blocks in the S7-400 CPU work memory marked as deleted, which fragments memory:

Open SIMATIC Manager and establish an online connection to the AS controller.
Select the CPU and press Ctrl + D to open the Module Information dialog.
Navigate to the Memory tab. Inspect the exact distribution between Code Work Memory and Data Work Memory.
If fragmented memory exists, click the Compress button.
The operating system shifts active memory objects into a contiguous block, eliminating dead storage gaps left by prior delta downloads.

[!IMPORTANT]
The Compress function only reorganizes fragmented memory gaps. It cannot reduce the physical size of active blocks or the STRUCT POOL DB.

Verification

After de-interconnecting redundant structures and cleaning up the block container, perform complete offline and online verification:

In SIMATIC Manager, select the Chart container and click Chart -> Compile -> Charts as Program.
Select Entire program with Generate module drivers checked.
Confirm that compilation completes with zero errors.
Check the size of DB85 in the offline block folder. The byte size should reflect the reduced number of structure interconnections.
Open Module Information (Ctrl + D) online and verify that Data Work Memory utilization drops below 80%, providing adequate headroom for future delta changes.

Work Memory Diagnostic and Mitigation Matrix

The following engineering matrix outlines diagnostic symptoms, underlying root causes, and verified mitigation actions:

Memory SymptomRoot CauseVerification MethodCorrective Engineering ActionData Work Memory > 95%Bloated STRUCT POOL DB (e.g., DB85)Check DB85 byte size in Blocks folderReplace wide structure interconnections with scalar signals in CFCCode Work Memory > 95%High count of technological blocks / FBsModule Information -> Memory tabClean up unused blocks, migrate logic to higher-tier CPUDownload blocked: 'Not enough memory'Memory fragmentation after frequent delta downloadsInspect free memory gaps in CPU diagnostic bufferExecute 'Compress' via Module Information onlineDelta compile fails with 'Area full'CFC reserved DB range exhaustedCheck Customize -> Compilation DB rangeExpand reserved DB pool or execute Entire Program compileSTRUCT POOL DB reaches 65,400 bytesHard architectural limit of S7-400 data blockInspect DB properties in STEP 7 editorPartition large charts across multiple runtime groups or AS controllers

Preventive Engineering Best Practices for Large PCS 7 Programs

To maintain predictable work memory overhead across the lifecycle of a PCS 7 installation:

Avoid Passing Raw Structures Across Hierarchy Folders: Pass specific primitive variables (REAL, BOOL, DWORD) unless an APL faceplate specifically requires a technological interconnection.
Schedule Periodic Full Compilations: Periodically schedule maintenance windows to execute an Entire Program compilation and full download in STOP mode (during planned turnaround) to completely eliminate legacy compiler fragments.
Hardware Sizing: When designing control systems with extensive APL deployments and batch control, specify CPUs with generous integrated work memory (such as SIMATIC S7 CPU 416-3 or CPU 410-5H) rather than entry-level process controllers.

Limitations and Operational Precautions

Never attempt to delete DB85 or any system-generated data block manually from the STEP 7 block folder while CFC charts are loaded. Deleting compiler data blocks desynchronizes the CFC database from the STEP 7 block container, which forces a mandatory full compile and full download in STOP mode.

When sizing hardware replacements or expanding plant capacity, all hardware models, memory capacities, and software requirements must be validated against official Siemens catalogs and confirmed through an authorized Siemens distributor quotation.

Engineer FAQ

Can an external Memory Card expand S7-400 Work Memory?

No. An external pluggable Memory Card (RAM or Flash EPROM) expands Load Memory only. Work Memory is integrated on-board CPU hardware and cannot be expanded with a card.

What happens if a STRUCT POOL DB exceeds 65,534 bytes?

The CFC compiler aborts compilation with an error stating that the data block maximum capacity has been exceeded. The program cannot be compiled or downloaded until interconnections are reduced.

Does the Compress button disrupt process execution?

No. Compressing memory in the S7-400 CPU reorganizes memory allocation in the background during cyclic execution without stopping the controller.

Can I disable the STRUCT POOL DB mechanism?

No. It is an internal architectural requirement of the CFC compiler for marshaling structured variables across separate charts.

Investigating STRUCT POOL DB Allocations and CPU Work Memory Shortages in SIMATIC PCS 7