Step 7 Variable Storage: TEMP, STAT, and DB Best Practices

Overview: The Three Storage Classes in Step 7

Siemens SIMATIC S7 controllers expose three fundamentally different storage classes for user data, and confusing them is the single most common source of intermittent machine faults in beginner code. Understanding the lifetime, scope, and retentivity of each class is the foundation of writing reliable S7-300, S7-400, S7-1200, and S7-1500 applications in STEP 7 (TIA Portal).

The most important rule: never use TEMP to carry a value from one scan to the next. Use STAT inside an FB, or a tag in a global DB, or a retentive M bit. The remainder of this article explains the mechanism behind that rule, documents the OB1 anomaly that misleads newcomers, and provides a verification procedure to confirm your block is storing data where you expect.

How the Local (L) Stack Actually Works

Every organization block (OB), function block (FB), and function (FC) has an interface in STEP 7 where you declare IN, OUT, IN_OUT, STAT (FB only), and TEMP variables. The TEMP variables are mapped onto a per-call region of the L stack (local data stack) when the block executes. When the block returns, that region is released back to the L stack pool.

The L stack is a contiguous memory area whose total size is configured under the CPU properties in TIA Portal (Path: CPU > Properties > System and diagnostics > Local data). For an S7-1500 CPU 1515-2 PN, the default maximum L stack per OB priority class is typically 16 KB; for an S7-319, defaults are smaller. The CPU reserves the L stack for each OB priority class at startup based on the worst-case L-stack usage of the blocks in the call tree of that priority.

Because the L stack is one shared pool, two different blocks — or two instances of the same FB called from the same priority — can occupy overlapping L-stack offsets if the call structure is re-organized. Any value left behind in a TEMP variable from a previous call may be silently overwritten by a later call. This is the root mechanism of every "it works in OB1 but breaks in the FC" bug.

TEMP Variables: Lifetime and the OB1 Anomaly

The lifetime of a TEMP variable is exactly one call. When the block is entered, the L-stack region for that call is allocated; when the block is exited, the values are undefined. Reading the value of a TEMP that was never assigned in the current scan returns the last value left in that L-stack byte — which is, by definition, not deterministic.

Why OB1 looks different: OB1 is a special organizational block because it is the only OB the CPU calls every free-cycle scan. The L-stack region reserved for OB1 is allocated once at startup and is not reclaimed between cycles, because no other block ever runs at OB1's priority that would reuse that exact L-stack region. As a result, a TEMP declared in OB1 will appear to retain its value between scans, and a TEMP used as a one-shot bit in OB1 will work — but the moment the same code is moved into an FC or FB, it will fail.

What the Siemens S7-1500 System Manual Says

The SIMATIC S7-1500 system manual, available through the Siemens SiePortal product catalog, lists the following memory areas and their retentive behavior:

One-Shot Bits: The Classic TEMP Misuse

Edge detection (rising edge, falling edge) is a one-shot operation: a boolean that is true for exactly one scan. The standard pattern in ladder logic is:

1. Capture the input bit before the new scan reads it (use a memory of the previous state).
2. Compare the new input to the previous state.
3. Assert the edge for one scan only.

STEP 7's built-in |P| (positive edge) and |N| (negative edge) contact instructions rely on a stored edge bit (formerly called the edge memory bit, in M area or instance data). The fundamental implementation is:

// Ladder excerpt, FB "Mode_Select"
// "Start_PB" is an input tag from the symbol table
// "Start_PB_Edge" is a STATIC BOOL in this FB

      Start_PB    Start_PB_Edge    Start_PB
  --| |----------|/|-------------( S )--
      Start_PB_Edge
  --| |---------------------------( )--    // edge result

      Start_PB
  --| |-------------------------( Start_PB_Edge )--    // save current state

If Start_PB_Edge is declared TEMP instead of STAT, the rising-edge detection will work in OB1 in a small program and will fail the moment:

• The block is moved into an FC and called from two locations, or
• Another FC is added that also uses the same L-stack bytes, or
• The block is called from a cyclic interrupt OB (OB30-OB38) that interleaves with OB1.

Symptoms of a broken one-shot bit: the edge output flickers for one extra scan, the output never sets, or the output stays set permanently. All three failure modes are documented in Siemens FAQ entries for S7-300/400 edge detection.

Static (STAT) Variables: The Persistent Memory of an FB

Static variables are declared in the Static section of an FB's interface. They live in the FB's instance DB (background DB). The instance DB is generated automatically the first time the FB is compiled and downloaded with an instance-DB call site, and it persists across scans, power cycles (if marked retentive), and STOP-to-RUN transitions (subject to retentive tag configuration).

Static variables solve the cross-scan storage problem because they have:

• Unique storage per FB instance — two calls of the same FB each get their own instance DB region.
• Deterministic initialization — values are zeroed at instance-DB creation, then behave per their retentive flag.
• Symbolic access in TIA Portal: "MyFB"."Start_PB_Edge" regardless of the absolute memory address.

Multi-Instance FBs on S7-1500 and S7-300/400

On S7-300/400, FBs can be called as multi-instances inside a parent FB: a single instance DB stores the static data of all child FBs. On S7-1200/1500 with optimized block access (the default in TIA Portal V17+), the same is true, and the storage layout is automatically managed by the compiler. The principle is identical: each FB call site has its own static region, so two instances of the same FB do not collide.

Data Blocks: Global Application Memory

A global DB (DB of type "Global DB" in TIA Portal) is a flat collection of tags accessible from any block in the program. By default, every tag in a global DB is always retentive; the retentive range can be restricted per tag in the DB's properties dialog (DB > Properties > Attributes > Retain).

The crucial property for the use case discussed in the source material: a value written to a global DB tag survives a power cycle of the PLC if the tag's retentive flag is set (and the CPU has a working backup battery or supercapacitor, depending on the model). For an S7-1500 CPU 1511-1 PN, retentive data is held in NVRAM (no battery required) up to the configured limit. For an S7-315-2 PN/DP, the retentive area is held by the backup battery and is configured under CPU > Properties > Retentive memory.

M (Memory / Merker) Area: Configurable Retentivity

The M (Merker) area is a global flag space in the CPU. M0.0, MW10, MD100 — all are bit/word/DWord-addressable global flags. The retentive range of the M area is configured under CPU > Properties > System and diagnostics > Retentive memory > Merker in TIA Portal. The default for an S7-315-2 PN/DP is typically MB0–MB15 (16 bytes of retentive Merker); for an S7-1516, the default is often MB0–MB0 (no M retentivity — the platform prefers DBs).

Configuring Retentive M in TIA Portal V18 / V19 / V20 / V21

1. Open the project in STEP 7 Professional (TIA Portal).
2. Select the CPU device in the project tree.
3. Open Properties > System and diagnostics > Retentive memory.
4. Set the Number of retentive Merker bytes from 0 up to the CPU limit (e.g., 2048 bytes for CPU 1518-4 PN/DP).
5. Compile the hardware configuration and download to the CPU.

Verification: after the download, perform a power cycle of the CPU. Set a Merker bit (e.g., M0.0 = TRUE), cycle power, and confirm M0.0 reads TRUE on the next online connection. If it does not, the retentive range was not set correctly or the CPU is in a no-battery/no-NVRAM state.

FC vs FB: When to Use Each

The selection of FC versus FB is driven by whether the block needs to remember anything between calls.

The classic rule for code organization: if the block has any kind of "state," it must be an FB, not an FC. A motor starter FB will track run-time hours, last command, fault state, and E-stop history — none of which can live in TEMP. A scaling FC that takes a raw input and an engineering-range pair and returns a scaled real needs no memory and is a clean FC.

Migration Notes: Coming from Unity Pro or Cx-Programmer

Engineers transitioning from Schneider Electric's Unity Pro (Modicon M340/M580) or Omron's CX-Programmer (CP/CJ/NJ series) frequently land on two misunderstandings:

1. "Function" semantics differ. In Unity Pro, a "function" (DFB) is roughly equivalent to a Siemens FB — it has instance memory. A "procedure" in Unity Pro is roughly an FC. Mapping Unity Pro DFBs onto S7 FBs and Unity Pro procedures onto S7 FCs is the correct port.
2. Local variables are not free-form. In CX-Programmer, you can declare a local inside a subroutine and have it persist; in S7, that local is TEMP and does not persist. The Cx-Programmer equivalent of STAT is the FB's work area or, more commonly, a global variable in a shared data area. Map to S7 FB with STAT.

The phrase "FB is a function with a memory which is DB" is the most concise way to remember the difference: the FB carries its DB with it, the FC does not.

Best Practices Summary

• Use TEMP only for in-block scratch values that are computed and consumed within the same scan.
• Use STAT in an FB for any cross-scan state, including edge-detection memory.
• Use a global DB for plant-wide state (setpoints, modes, recipes, fault logs).
• Use M flags sparingly and never for state that must survive a power cycle unless the M area is explicitly configured retentive.
• Make every non-trivial state machine a separate FB with its own instance DB.
• Never rely on OB1's L-stack retentivity — treat it as a happy accident and write portable code.
• Avoid two FCs with the same name being called from the same priority unless you have confirmed their L-stack regions do not overlap (TIA Portal's "Local data usage" tab in the CPU properties will report this).

Verification and Commissioning Checklist

1. Open the project in STEP 7 Professional V18 or later (V21 is the current release as of the catalog snapshot on the Siemens SiePortal).
2. Right-click the CPU and choose Compile > Hardware (rebuild all).
3. Open CPU > Properties > System and diagnostics > Local data. Verify the per-priority L-stack size is large enough for your deepest call tree (TIA Portal will warn if not).
4. Open each FB and inspect the Interface tab. Confirm every cross-scan variable is declared STAT, not TEMP.
5. Search the project for direct TEMP accesses in OB1 that act as one-shot bits. Refactor each to a STAT in an FB or a flagged M/DB bit.
6. Download to the CPU, go online, and open the Monitor & Force view of each FB instance. Force a STAT to TRUE, cycle power, and confirm the value is retained (if marked retentive).
7. Force a TEMP variable — observe that its value is undefined at the start of each call.

Troubleshooting Matrix

Frequently Asked Questions