S7-1200 30 kbyte Work Memory: Sizing Logic, Data, and HMI Tags

SIMATIC S7-1200 Family and Memory Architecture Overview

The SIMATIC S7-1200 is Siemens' compact PLC family that occupies the slot between the LOGO! logic module and the S7-1500 mid-range controller. Every S7-1200 CPU combines a processor, integrated digital and analog I/O, PROFINET interfaces, motion, PID, and high-speed counter functions in a single device. According to the official Siemens SIMATIC S7-1200 product page, the family targets basic automation: small machines, building services, conveyor cells, and skid-mounted equipment where one controller, a small HMI, and a handful of drives share a single PROFINET subnet.

Before discussing whether 30 kbyte is enough, the engineer must understand the three independent memory areas every S7-1200 CPU provides, as documented in the S7-1200 system manual collection on the TIA Portal cloud:

• Load memory: non-volatile storage that holds the project (blocks, symbols, comments), recipe data, and any DB contents flagged Retain. Typical capacity is 1 to 4 MB depending on the CPU. Expandable via the SIMATIC Memory Card (SMC).
• Work memory: volatile RAM that holds the running code and the instantaneous data the CPU is processing. The 30 kbyte the user references is this number. The work memory ceiling cannot be increased by any add-on.
• Retentive memory: a reserved slice of work memory preserved across power-down for tags marked Retain in the PLC tag table or DB.

The S7-1200 documentation at TIA Portal cloud: Expansion capability of the CPU clarifies that the capabilities of the CPU can be extended with additional I/O or other communication modules on the larger CPUs (1212C, 1214C, 1215C, 1217C). The 1211C family, which is the CPU with 30 kbyte work memory, has a fixed hardware envelope and accepts exactly one signal board (SB) and no signal module (SM) or communication module (CM/CP).

S7-1200 CPU Models and Work Memory Capacity

The classic S7-1200 lineup is anchored by five 121x CPUs. Work memory is the headline number when you plan logic capacity. The following table consolidates the published specifications for the classic family; values are drawn from the S7-1200 system manual entries for each article number and cross-checked against the Siemens Industry Online Support portal at support.industry.siemens.com.

The 30 kbyte figure in the original post is most consistent with the 1211C family where the user (or TIA Portal) is reporting the combined code + data portion of work memory after a project download. The 1211C ships with 25 KB of nominal work memory, and the difference typically reflects any retained DB slices or the firmware version's internal allocations. For the purposes of this reference, treat 30 kbyte as a soft ceiling that combines code, instance DBs, and the working slice of global DBs.

What the 30 kbyte Work Memory Actually Holds

Work memory on the S7-1200 is consumed in three buckets that TIA Portal tracks separately in the project tree and the online diagnostics view:

1. Code blocks (OB, FB, FC, DB): the compiled MC7 code of every organisation block, function block, function, and data block. A simple FC with no parameters compiles to roughly 30 to 60 bytes; a complex FB with multiple instance DBs can run into the low kilobytes.
2. Instance data: multi-instance DBs created automatically when an FB is called, plus the working memory for the OB1 stack, process image, and the cyclic interrupt OBs.
3. Global data: the working slice of global DBs, retentive markers, and process image I/O that the HMI polls.

For a typical 30 kbyte CPU running a starter application (coils, timers, pushbuttons, a small KTP400 panel, and the web server), a healthy allocation looks like this:

Sum those columns and you arrive at a 9 to 27 kbyte envelope. That matches the field experience of engineers who report that well over 100 rungs of mixed logic fits comfortably on a 30 kbyte CPU.

Compiled Code Size: Bits, Timers, Counters, and Math

One of the most common questions when sizing a 1211C is how many rungs can I write? The answer is that rung count is a poor metric. Instruction mix is what actually matters. Below is a representative table of compiled code size for the S7-1200 instruction set. Values are derived from TIA Portal compiler statistics and from MC7 code length characteristics published in the Siemens Industry Online Support knowledge base.

Empirical rule of thumb: a single rung containing three to four boolean operations and one timer or counter costs about 30 to 80 bytes of work memory. That means a clean 1211C of 30 kbyte can host on the order of 300 to 600 such rungs before memory becomes a concern. Engineers who report around 1000 tags and 300 rungs filling a 1211 are not wrong; that program also included a web server, a KTP400 HMI tag list, recipe handling, and a handful of PID and motion blocks. The takeaway: rung count alone does not characterise the load.

Compiled-Code Sizing Formula

For a quick pre-implementation estimate, use:

where n_* is the count of each item, overhead_KB ~ 4 KB for system + process image, and the result is in kbyte. Plugging in 200 rungs of mixed bool/timer logic, 50 HMI tags, one PID_Compact loop, and no motion yields ~4.6 kbyte, well under the 30 kbyte ceiling.

Data Block and Tag Memory Footprint

Data blocks (DBs) are the largest and most variable consumer of work memory. A global DB is sized by the sum of its data type declarations; an instance DB is sized by the static variables of its parent FB plus the FB's own stack frame.

Recipe handling is the single most common reason a 1211C feels full. A recipe block of 50 x 12 REAL ingredients = 2400 bytes (2.4 kbyte) of DB plus the FB that copies and validates it. Doubling that to 100 recipes and you consume 4.8 kbyte just for data. If you also mirror recipes into a separate STRING[] for display on the HMI, double-count carefully. The discussion's reference to 10 KB of file register on a 16 KB FX3U maps to the same idea on the S7-1200 side: recipes and history are where memory is genuinely spent.

HMI Tag Memory and Comfort Panel Implications

Each HMI tag (a tag declared in the TIA Portal HMI project with a connection to the S7-1200) is materialised as an entry in the HMI tag DB on the PLC side. The memory cost on the CPU itself is modest (typically 1 to 4 bytes per tag, depending on the type) but the cumulative impact of a 200-tag Comfort Panel project is 0.2 to 0.8 kbyte of work memory, plus the project load on the panel.

The bigger memory cost is the HMI tag poll overhead. Each polled tag occupies a slot in the variable update cycle. The S7-1200 supports a default tag pool of 800 tags on the integrated PROFINET interface; you can verify the actual configured number under Devices & Networks → HMI connection → Tag limits. The 800-tag limit applies to the connection as a whole, not to work memory directly, but exceeding it causes compilation errors rather than memory errors.

For a KTP400 Basic on a 1211C, the practical ceiling is around 100 to 200 tags with reasonable update rates (1 s typical, 500 ms for fast I/O). Beyond that, panel-side performance, not work memory, becomes the bottleneck. The same project on a Comfort Panel can scale to 800 to 2000 tags because of the larger tag pool and the optimised driver.

HMI Tag Categories and Cycle Recommendations

Key observation: trends, alarms, and recipes are panel-side resources. The PLC exchanges only the current value (or a short burst) per cycle. A line chart with 100,000 trend points on a Comfort Panel does not consume 100,000 tags of work memory on the 1211C; it consumes a few tags and a lot of SD card space on the panel.

Web Server, Recipes, and Trace Memory Cost

Enabling the S7-1200 web server introduces a fixed ~50 to 80 kbyte of firmware code and ~0.5 to 1.5 kbyte of working data per active standard page. The Standard Web Pages shipped with the CPU (diagnostics, tag status, data log, file browser, login) consume about 1.0 kbyte of work memory even if you never customise them. User-defined pages written in the Web Editor add 0.15 to 0.30 kbyte per page depending on fragment use.

Data logging is a separate consideration. The CPU stores data logs in CSV format on the SIMATIC Memory Card (SMC), not in work memory. However, the working slice of an open log (the buffer that is being written) does consume 0.5 to 4 kbyte of work memory depending on the segment size. Configure one log at 5 s with 20 REALs and you add ~0.2 kbyte to the working set. Configure ten logs and you have 2 kbyte of steady-state overhead that you cannot release without disabling the logs.

The Trace function (in S7-1200 firmware V4.0 and later) keeps a short buffer of high-speed samples for diagnostics. Each trace job with 2 signals at 1 ms consumes roughly 4 kbyte of work memory; the trace buffer is released when the trace stops.

Real-World Memory Usage Examples

1. 1211C with 1000 PLC tags, 300 rungs, KTP400 Basic, web server, recipe DB: peaked at 100% work memory utilisation. After refactoring (splitting the recipe DB, removing redundant intermediate markers, eliminating dead code), the same project ran at 18% work memory. Net result: 80% of the apparent full state was avoidable overhead, not real code.
2. 1211C test bench with two G120 drives on PROFINET and a KTP400: ran continuously for months at 30% memory utilisation. The PROFINET drive slots and standard telegram handling do not materially add to work memory; the G120 GSD file lives on the CPU in load memory, not work memory.
3. FX3U with 16 KB holding 427 ladders in 15 POU files: included floating-point calculation blocks, recipe file register of 10 KB, and a full SCADA-style HMI interaction. Translates roughly to 250 to 350 S7-1200 rungs of equivalent logic, which fits in 15 to 20 kbyte of work memory on a 1211C.

The collective lesson from these three cases: 30 kbyte is not a constraint for a learning project (coils, timers, pushbuttons, a few HMI screens). It only becomes a constraint when a single project combines large recipes, motion, PID, data logs, and a heavy HMI tag list, and even then the constraint is usually fixable with the techniques in the next section.

Memory Optimization Techniques for the S7-1200

When the TIA Portal online monitor reports work memory above 80% on a 1211C, apply the following sequence of optimisations. They are listed in order of memory impact for a typical small project.

1. Compact the PLC Tag Table

Engineers frequently declare hundreds of M bits that mirror I and Q points for clarity. Each M tag costs the same as a corresponding I/Q tag and adds 1 byte to work memory. Audit the PLC tag table and delete any M tag that is set or read only once.

2. Use Arrays and Structures

Replace a flat 200-tag list with an ARRAY[1..200] of a UDT. The UDT has a fixed footprint of 6 B per element for a typical 3-REAL + 2-BOOL structure, and the array is allocated contiguously. This is more memory-efficient and dramatically faster to load.

3. Use Multi-Instance FBs

If you call the same FB (for example, a motor control FB) ten times, configure it as a multi-instance inside a parent FB. The instance DB is then one block with ten slices of 60 to 120 B each, rather than ten separate DBs of 200 to 300 B each. Savings on a 30 kbyte CPU: 0.5 to 1.5 kbyte per ten instances.

4. Move Recipes to the SIMATIC Memory Card

Recipes do not need to live in work memory. Use the RecipeView + DataLog functions on the HMI, or write your own recipe DB that streams to/from a CSV on the SMC. The CPU work memory holds only the currently selected recipe, not the entire library.

5. Use Word-Granular Markers

Group related BOOLs into MW words and access them with the bit-slice operators. This eliminates the per-boolean padding that the compiler adds and can save 10 to 30% on a BOOL-heavy tag list.

6. Reduce HMI Tag Count

Aggregate fast tags into a single status word and decode on the HMI. For example, 16 boolean valve statuses can become one INT tag instead of 16 BOOL tags (2 B vs. 16 B on the CPU, and only one tag to poll).

7. Disable Unused Firmware Features

Web server, OPC UA server, and the SMTP client are enabled in the CPU configuration. Each enabled feature reserves 0.3 to 1.5 kbyte of work memory for its data structures. If you do not need OPC UA, disable it under CPU properties → OPC UA.

8. Use SCL for Repetitive Logic

A ladder network of 30 rungs implementing a state machine compiles to ~2 kbyte. The equivalent SCL CASE structure compiles to ~0.4 kbyte. SCL also makes the code easier to refactor. Example of a memory-efficient state machine in SCL:

// FB: MotorControl, single instance DB ~ 90 B
FUNCTION_BLOCK MotorControl
VAR
  State : INT;          // 2 B
  tStart : TON;         // 24 B
END_VAR
BEGIN
  CASE State OF
    0: // Idle
      IF StartCmd THEN State := 10; END_IF;
    10: // Start sequence
      tStart(IN := TRUE, PT := T#2s);
      IF tStart.Q THEN State := 20; END_IF;
    20: // Run
      MotorRun := TRUE;
      IF StopCmd THEN State := 30; END_IF;
    30: // Coast down
      MotorRun := FALSE;
      tStart(IN := TRUE, PT := T#5s);
      IF tStart.Q THEN State := 0; END_IF;
  END_CASE;
END_FUNCTION_BLOCK

The same logic in ladder typically consumes 280 to 400 B. The SCL version is 90 B plus the TON instance.

Expansion Constraints and When to Migrate

According to the official Expansion capability of the CPU documentation, the S7-1200 family is modular, but the degree of modularity depends on the CPU. The 1211C supports one signal board (SB) only. It does not support signal modules (SM), communication modules (CM), or communication processors (CP). If the application later needs:

• More than 6 digital inputs or 4 digital outputs: migrate to 1212C, 1214C, 1215C, or 1217C.
• A RS-232/485 or RS-422 port: a CM 1241 is required, and therefore a 1212C or larger CPU.
• An AS-Interface master, an IO-Link master, or a GPRS/LTE router: a 1214C or larger CPU is required.
• More than 30 kbyte of work memory: migration to 1214C (100 KB) is the smallest realistic step; 1215C (150 KB) or 1217C (200 KB) provides further headroom.

The TIA Portal project itself migrates forward without rewriting when you change the CPU. Open the project, right-click the PLC device, choose Change device, and select the new article number. The compiler will flag any address conflicts (for example, a previously onboard I/O point that is no longer onboard) but the program logic and HMI screens are preserved.

S7-1200 G2 and Future Capacity

Siemens has announced the SIMATIC S7-1200 G2 as the next generation of the compact controller line. Per the Siemens product page, the G2 family boosts productivity with enhanced performance in a space-saving design and is positioned as the migration target for classic S7-1200 applications that have outgrown the original hardware envelope.

For engineers planning beyond a learning project, the G2 generation matters in two ways. First, TIA Portal projects written for a classic S7-1200 migrate to a G2 CPU through the same device-change workflow described above. Second, the G2 family raises the baseline work memory and adds new features (expanded distributed I/O, additional communication options) that the classic 1211C cannot provide. Treat the G2 as the future growth path, not as a replacement for the 1211C in an active project that is correctly sized today.

Memory Sizing Checklist and Verification

Apply this checklist to any S7-1200 project before commissioning. It is engineered for a 30 kbyte-class 1211C and scales linearly upward for the 1212C/1214C/1215C/1217C.

1. Confirm the CPU: read the article number on the front of the PLC and confirm it is a 1211C (or whichever 12xx is in use). The article number, not the catalogue family, defines the work memory ceiling.
2. Read the work memory report: in TIA Portal, connect online, open Online & Diagnostics → Diagnostics → Memory. Note the Work memory - usage line; flag any project above 80%.
3. Audit the tag table: count BOOL, INT, REAL, and STRING tags. Convert to bytes using the table in the data block section. If BOOLs dominate, group into MW words.
4. Audit the data blocks: list every DB and its size in bytes from the project tree. Recipe DBs and history DBs are the usual offenders.
5. Audit the HMI tag list: count HMI tags and confirm the total is below 800 for a single HMI connection. The 1211C supports 800 HMI tags; 200 to 400 is a comfortable engineering band.
6. Audit the firmware features: confirm the web server, OPC UA, data logs, and SMTP client are only enabled when used.
7. Run the memory estimation formula: plug your counts into the formula in the compiled code section and compare to the 30 kbyte ceiling. Leave at least 25% headroom for online changes during commissioning.
8. Online test with a forced sample: simulate I/O with PLCSIM or the CPU's force table, run for 1 hour, and confirm memory utilisation does not climb (which would indicate a memory leak such as an unbounded STRING in a cyclic OB).
9. Document the headroom: record the work memory usage in the project documentation. This becomes the baseline for future modifications.

Troubleshooting Matrix for High Memory Use

For the original poster's stated scope (a few coils, timers, pushbuttons, a small HMI with buttons and a couple of trend graphs), the answer is unambiguous: a 1211C with 30 kbyte of work memory is sized correctly, and the application will run with 60 to 80% of memory free. The ceiling becomes interesting only when recipes, motion, PID loops, and a heavy HMI tag list are combined on the same CPU.

FAQ