S7-1200 Memory Access Speed: M-Markers vs Data Blocks Compared

Overview

On the SIMATIC S7-1200 family (CPU 1211C through 1217C, plus the compact SIPLUS variants), the question of whether to store process variables in the flag/marker area (M, MB, MW, MD) or in a Data Block (DB) is one of the most frequently raised topics in TIA Portal programming. The short answer is: non-optimized M-bit access is the fastest raw access path, optimized DB access is the recommended path, and the absolute difference is on the order of single-digit microseconds—a margin that almost never dominates cycle time in a real application. This reference consolidates Siemens-published timing data, the firmware versions in which those numbers were first disclosed, and the engineering guidance that drives the DB-first recommendation.

S7-1200 Memory Areas: M, DB, I, Q, L, and Temp

The S7-1200 CPU exposes several addressable memory regions, each with a distinct role in the STEP 7 / TIA Portal execution model:

Only the M-area is by default a non-optimized access path. A DB can be created in either non-optimized (legacy S7-300/400 layout with fixed addresses) or optimized (symbolic-only, TIA Portal default) format. Optimized blocks strip the absolute address space and let the compiler arrange symbols for fastest symbolic read/write through the operand 2 cache.

M-Memory vs Data Block Access Speed: What Siemens Publishes

Starting with the S7-1200 system manual revision corresponding to firmware 4.4 (published June 2015), Siemens began publishing explicit instruction timing tables that distinguish between memory-bit (M) and data-block (DB) operand access. Prior to FW 4.4, the manual listed execution times without separating these operand classes, which made it impossible to answer the M-vs-DB speed question from official documentation alone.

Two Siemens support entries are the canonical references for this subject:

• S7-1200 Programmable Controller – System Manual (entry ID 81318674) — contains the instruction execution time tables in the "CPU technical specifications" appendix.
• Memory concept and programming style for S7-1200/S7-1500 (entry ID 90885040) — describes the optimized vs non-optimized block access model and the rationale for using symbolic DB tags.

The access path that consistently wins the raw micro-benchmark is non-optimized access to the M-area. M-memory on the S7-1200 is implemented as a flat, address-mapped bit/byte/word/dword array without symbolic lookup overhead, and the firmware resolves an %M operand directly to a fixed offset in the flag area.

Access Time Numbers From the S7-1200 Manual

Indicative access-time magnitudes (extracted from the FW 4.4+ system manual tables for a representative bit-logic operand such as A %M0.0 vs A "MyDB".MyBool on a CPU 1215C DC/DC/DC):

Optimized vs Non-Optimized Block Access

The "optimized" attribute in TIA Portal is more than a checkbox. It controls the runtime data layout of the block in the load and work memory of the CPU. Key trade-offs:

For new S7-1200 development, Siemens explicitly recommends optimized blocks. The only justified use of non-optimized access in a new project is when an external consumer (legacy HMI, OPC DA server, or pre-existing S7-300/400 routing partner) requires absolute DB addressing.

Why M-Memory Still Exists on the S7-1200

The M-area on the S7-1200 is deliberately emulated for backward compatibility with the S7-300/400 memory model, not designed from first principles for the S7-1200 instruction set. This implementation choice has two practical consequences:

1. Because the M-area is a compatibility layer, the firmware must guarantee fixed offsets that older programming tools and recipes can still read. This rules out the layout freedom that optimized DBs use to gain speed.
2. On some firmware versions and CPU variants, M-area access can actually be slower than optimized DB access for certain operand types, because the firmware's M-area resolution path includes the compatibility adapter on top of the symbolic lookup. Siemens has not committed to a uniform "M is always faster" guarantee across all CPUs and firmware versions.

The memory concept application document (entry 90885040) walks through the compiled-code differences and is the recommended reading for any engineer who has to defend a memory-area choice in a code review.

Cycle Time Impact in Real Programs

Cycle time on the S7-1200 is dominated by:

• Process image update of configured I/O
• OB1 execution time (sum of all called blocks)
• Communication load (PROFINET, OPC UA, Web server, S7 communication)
• Self-diagnostics and interrupt servicing

M-vs-DB operand choice affects only OB1 execution. For a typical program with a few hundred bit operations, the difference between using M-memory and a structured DB is dominated by the rest of the cycle, not by the operand access path. If the application is cycle-bound, the engineering response is to:

1. Profile OB1 with the S7-1200 online diagnostics (right-click the CPU → Online & diagnostics → Cycle time).
2. Check whether the process image is larger than necessary (configured but unused I/O).
3. Review the interrupt OB density (OB35, OB82, etc.) and consolidate where possible.
4. Only then consider operand access patterns as a last-step optimization.

Siemens Programming Style Recommendations

The published Siemens guidance for S7-1200/1500 programming style is to avoid M-memory for application data and to organize all data into well-named, typed Data Blocks. The rationale is not raw access speed—it is maintainability, reusability, and the cost of accidental coupling between blocks that read and write the same global M-flag.

A reference architecture that follows the Siemens guidance looks like this:

// In TIA Portal, project tree
//  PLC_1 [CPU 1215C DC/DC/DC]
//   ├── Program blocks
//   │   ├── OB_Main              (cyclic OB1)
//   │   ├── FB_Motor             (function block with instance DB)
//   │   ├── FC_Recipe            (function with TEMP/IN/OUT only)
//   │   └── DB_IoMap             (global I/O mirror)
//   └── PLC tags                 (limited to I/O symbols, no M-tags)

Key rules of thumb when following this style:

• Use FB instance DBs for everything that is a real-world object (valve, motor, axis). Each instance gets its own DB with retainable state.
• Use FCs with TEMP only for stateless calculations. Pass inputs and outputs via the block interface, never through shared M-flags.
• Use a single global DB (often called DB_IoMap or DB_ProcessData) for cross-coupling between FBs where the alternative is long parameter chains.
• Avoid global M-tags in new code. If a legacy program still has them, keep them isolated in a clearly named "legacy glue" DB and plan to migrate them.
• Set retain on FB instance DBs symbolically, not by address range, so retain storage is exactly what the engineer marked.

M-Memory Emulation: A Practical Risk

Because M-memory is a compatibility layer rather than a native type, it carries implementation risks that a properly designed DB does not. A few that surface in field service:

• Recipe import / export: Older tools that produce recipes for S7-300/400 may emit M-flag recipes. Importing these into an S7-1200 program that uses optimized DBs is a known source of data corruption if the M-area is treated as authoritative.
• HMI polling: Some legacy HMI panels poll absolute M-flag addresses faster than the cycle time. On S7-1200, this can be visible because the M-area is updated at the end of OB1, not asynchronously.
• Cross-CPU communication via PUT/GET on the S7-1200 must be enabled explicitly in the connection properties. Targets that expect M-flag payloads need to be redirected to DBs.
• Retain behavior: M-area retainability is configured at the DB/area level, not per symbol, which means a partial power-loss scenario can leave the M-area in an inconsistent state across reboot.

Each of these is solvable with a properly designed DB layer; none of them is solvable by trying to make M-memory "be faster".

Benchmarking Memory Access on the S7-1200

When the application genuinely is cycle-bound, measure before you optimize. The S7-1200 has built-in diagnostics that show OB1 worst-case, average, and current execution time without external tooling. Procedure:

1. Connect the engineering station to the CPU over PROFINET and go online.
2. Open Online & diagnostics → Diagnostics → Cycle time.
3. Note the Current, Average, and Worst values. Record the before values.
4. Make a single targeted change (e.g., convert the global M-flag usage in OB_Main to an optimized DB). Rebuild and download.
5. Run the same program stimulus and record the after values.
6. Repeat across a representative operating cycle (cold start, steady state, fault recovery).

For sub-microsecond granularity, use the S7-1200 RUNTIME instruction in a tight test loop to measure a known workload, then switch the operand class. A representative benchmark block looks like this (in Structured Text for clarity, but the same pattern works in ladder):

// ST benchmark: 10,000 bit reads against M vs optimized DB
// Result is the elapsed microseconds; print to HMI or watch table

FUNCTION_BLOCK FB_BenchMemAccess
VAR
  iCount : DINT;
  bM : BOOL;
  bDB : BOOL;
  tStart : TIME;
  tElapsed : TIME;
  tResult : DINT;
END_VAR

// Measure M-area access
tStart := T_MEAS_TIME();
FOR iCount := 0 TO 9999 DO
  bM := M_FlagBank[iCount MOD 8];
END_FOR;
tElapsed := T_MEAS_TIME() - tStart;

// Measure optimized DB access
tStart := T_MEAS_TIME();
FOR iCount := 0 TO 9999 DO
  bDB := DB_AppData.aFlags[iCount MOD 8];
END_FOR;
// Compare tElapsed values

The expected outcome on a CPU 1215C with FW 4.4 or later is that the two loops differ by low single-digit microseconds per 10,000 iterations—i.e., a per-iteration delta that is invisible to cycle time unless the program is doing nothing but memory reads in a tight loop.

Firmware History of the Published Numbers

The M-vs-DB timing split in the manual first appeared in the S7-1200 system manual revision that corresponded to firmware 4.4 (June 2015). Engineers working with older manuals (the 2012 print run, for example) will not find this distinction. Update paths:

• FW 4.2 and earlier: timings listed by instruction class, not by operand class. The M-vs-DB distinction was not separately quantified.
• FW 4.4 (June 2015): first manual to publish the M-area timing table separately from the DB-area timing table.
• FW 4.5 / 4.6: numbers updated for the refreshed CPU 1215C and the SIPLUS variants. Access windows are within the same order of magnitude as FW 4.4.

If you are maintaining a long-lived program, keep the manual download pointed at the latest revision for your CPU's firmware. The instruction tables in the S7-1200 system manual (81318674) are the authoritative source.

Related Siemens Documentation

• S7-1200 Programmable Controller System Manual (entry 81318674)
• Memory concept and programming style for S7-1200/S7-1500 (entry 90885040)
• S7-1200/1500 programming and operator control manual index (chapter 5343008)

Notes on Related Memory-Bandwidth Concepts

Outside the PLC context, memory access time is a first-class design parameter. DDR memory in a desktop-class system is characterized by bandwidth (MB/s) and latency (ns), with mainstream DRAM modules running at 1333 MHz through 2133 MHz and beyond. Solid-state storage moves the picture further: SSDs deliver access times in the 25–100 µs range versus 5–10 ms for rotating disks, while DRAM still underpins the register-level operand fetch. The reason these numbers matter less in a PLC than in a PC is that the S7-1200 executes a small, deterministic instruction set against a tightly bounded memory area—there is no demand-paging, no cache miss to a backing store, and no virtual-memory translation. The operand fetch path is the only "memory speed" that influences cycle time, which is exactly what the manual tables quantify.

FAQ