Siemens IM151-8 L Memory: Local Stack Allocation in FC/FB

Overview: What L Memory Is on the IM151-8 CPU

The IM151-8 PN/DP CPU is the integrated PLC of the ET 200S distributed I/O system. It executes a STEP 7 / S7-300 instruction set and is architecturally related to the S7-300 CPU 314 family. The CPU exposes three classes of operands inside the user program:

• I / Q / PI / PQ – process image and direct peripheral I/O
• M – global bit, byte, word, and double-word memory (retainable in parts)
• L – local, temporary data that belongs to a single execution context (the currently active OB and the FC/FB called from it)

L memory is not a globally addressable area. It is a slice of the CPU's local data stack (L-Stack / Lokaldaten-Stack) that is allocated dynamically every time an OB is entered, and it is released when the OB completes. The CPU maintains one physical stack in RAM; the OS simply hands out L addresses from it according to the call hierarchy that is active at the moment a bit/byte/word/double-word is accessed inside the block.

Because the stack is reused, the absolute address you see in the editor (for example LW 22) is meaningful only while that particular code block is executing. The same number will refer to a completely different variable the next time the block is called from a different context, or even the next time it is called from the same OB if other blocks were invoked in between.

L Stack vs. M Memory: The Engineering Difference

Engineers migrating from a relay-ladder background frequently assume that any operand the editor allows must be visible everywhere. On the IM151-8 that is only true for M, DB, inputs, and outputs. L memory has three properties that M memory does not:

The practical consequence: writing to L0.0 inside FC1 and writing to L0.0 inside FC2 is not a conflict in the source sense, because the L-stack is re-allocated per call. It is, however, a conflict in the maintenance sense – two developers will read the same absolute address and assume they are talking about the same bit. That is why Siemens documentation and the STEP 7 style guide forbid direct L addressing from outside the block where the TEMP variable is declared.

OB Priority Classes and How the L-Stack Is Partitioned

The IM151-8 organises execution by priority class. Every OB has a fixed priority (OB1 = 1, OB10 = 2, OB35 = 12, OB40–OB47 hardware interrupts, OB80–OB87 error OBs, OB100 = 27, OB121/OB122 = priority of the OB that caused the error). Up to 26 priority classes can be active concurrently in the worst case.

For each priority class the operating system reserves a separate slice of the L-Stack. The size of that slice is configured in HW Config (STEP 7) or in the device properties (TIA Portal) under CPU Properties > Local Data / Prioritätsklassen. The default for the IM151-8 family is:

Within one priority class, the OS builds the local data frame by concatenating the local data of every block that is currently on the call stack, starting at byte 0. The frame looks like this when OB1 calls FC1, which in turn calls FC2:

Byte  Offset  Source
0..19         OB1  TEMP area (20 bytes declared)
20..23        FC1  TEMP area  (4 bytes declared)
24..27        FC2  TEMP area  (4 bytes declared)
28..          (would belong to FC3 if FC2 called it)

Notice that the offset of FC1's TEMP depends on how many bytes OB1 declared, and the offset of FC2 depends on how many bytes FC1 declared. Change the TEMP footprint of any block in the call chain and every block below it shifts. This is the single most common source of "it worked yesterday" L-stack faults.

Verifying the Allocation: A Walk-Through

Suppose a project contains the following declarations:

• OB1 – declares 20 bytes of TEMP (for example tOB1_State : BYTE, tOB1_Step : WORD, tOB1_Tmr : TIMER)
• FC1 – declares 4 bytes of TEMP (tFC1_RetVal : WORD, tFC1_Flags : BYTE)
• FC2 – declares 4 bytes of TEMP (tFC2_Index : WORD, tFC2_Sum : INT)

When OB1 runs and calls FC1 which calls FC2, the L addresses are:

If a maintenance engineer types L LW 22 in FC2 expecting "the index from FC1", they will actually read FC2's own tFC2_Index. That is the hazard of absolute L access. Always use the symbolic TEMP name the compiler created in the block's interface.

Local Data Sizing for the IM151-8 Variants

The IM151-8 family is shipped in several firmware versions. The amount of maximum local data per priority class differs:

The total local data budget is the sum of the slices allocated to every priority class. If you set every priority class to 32 KB, the total exceeds the budget and the CPU will refuse to start – it logs SF / BF with diagnostic buffer entry "Local data stack overflow". The recommended practice is to leave the 256-byte default and grow a specific class only if you have a real, profiled reason (deep FC nesting in a cyclic interrupt, for example).

To size correctly, add up the TEMP footprint of every block that can be on the call stack from the worst-case OB. For an OB1 scan that may call FC1 → FC2 → FC3, the worst case is OB1 + FC1 + FC2 + FC3, not just the deepest level.

Why Direct L Access from Outside the Block Is a Code Smell

STEP 7 and TIA Portal both allow you to type L MW 20 from any block, including OBs. For M memory this is fine; for L memory it is not. Reasons:

1. No cross-reference integrity. The cross-reference list shows the absolute address, not the block that owns it. You cannot search who wrote to L24.0 because every block that has a TEMP in that byte is a candidate.
2. Call-stack fragility. Adding a TEMP variable to a block higher in the call chain silently shifts every address below it. A field device that was supposed to read L24.0 will now read a different bit without a single compile error.
3. Re-entrancy surprises. The same FC can be re-entered from two different OBs (e.g. OB1 and OB35). If FC1 writes to L0.0 absolutely, the second caller overwrites the first caller's data because they share the slice.
4. Compiler optimisation. STEP 7 may re-pack TEMP variables to save bytes. The mapping you assumed in the source is not guaranteed after a rebuild.

The only supported way to exchange data into or out of a block is the formal interface: IN, OUT, IN_OUT parameters, and for FBs the STAT (instance-DB) area. The TEMP area exists for intermediate results inside the block only.

Configuration Procedure in STEP 7 (Classic)

1. Open HW Config and double-click the IM151-8 station.
2. Open CPU Properties > Local Data (German: Lokaldaten).
3. For each priority class, enter the local data size in bytes. 256 is a safe default.
4. Click OK, save and compile, and download to the CPU.
5. After the next STOP-to-RUN transition, verify in CPU > Module Information > Performance Data that the new sizes are active.

Configuration Procedure in TIA Portal

1. In the project tree, select the IM151-8 device.
2. Open Properties > System and diagnostic events > Local data (or the dedicated Local data tab in V17+).
3. For each OB priority class, set the size. TIA Portal warns if the sum exceeds the device total.
4. Compile the project (Hardware and software (rebuild all)) and download.
5. Watch the online diagnostics for SF with diagnostic buffer text containing "Lokaldaten" / "Local data" – this means the sum is still too high.

Diagnostics: Common L-Stack Faults on IM151-8

The STEP 7 diagnostic buffer gives the exact byte that overflowed. In TIA Portal, open Online & Diagnostics > Diagnostics buffer and double-click the entry – the CPU reports "exceeded XX bytes". The number is the requirement, not the configured size; you must set the configured size to at least that number.

Best Practices for Local Data Usage

• Always use the symbolic name the compiler creates for each TEMP. Never type L + address by hand inside the same block either – let the editor resolve the address from the interface declaration.
• Use IN/OUT/IN_OUT for every value that crosses a block boundary. Reserve TEMP for scratch calculations only.
• Pre-declare the entire scratch footprint in the interface, even if some bytes are unused. This freezes the size and prevents accidental re-packing from changing call-stack offsets in other blocks.
• Profile real programs. The default 256 B per class is enough for most ET 200S applications. Raise it only after a real overflow diagnostic.
• Avoid deep FC nesting in cyclic interrupts (OB35). Each level adds its own TEMP frame, and cyclic interrupts can be pre-empted by hardware interrupts, doubling the requirement.
• Document the call chain in the OB header comment so that the next engineer can reproduce the offsets you used during commissioning.

Migrating from a CPU 314 to IM151-8: L-Stack Pitfalls

The IM151-8 is the drop-in replacement for an S7-300 CPU 314 inside an ET 200S station. The local data layout is identical, but the default per-class size is 256 B on both, so most programs transfer without change. Watch for these exceptions:

• Programs that grew the CPU 314's local data to 8 KB per class will not run on the IM151-8 – the total budget is 64 KB, identical to the CPU 314, so the absolute size is fine, but the per-class maximum on the IM151-8 firmware ≤ 2.0 was lower in early releases. Confirm with the firmware release notes for the specific MLFB.
• Programs that access L memory from a different block (a frequent legacy pattern in retrofits) will compile and run, but will produce cross-reference errors after the next compiler re-pack. Fix the project before commissioning.
• Programs that use a shared DB as "global L memory" because they ran out of L space are a clear sign that the function should be split into an FB with STAT instead.

FAQ