Optimized vs. Standard Data Blocks in S7-1500: What Every Migrator Must Know

When you migrate a STEP 7 Classic project to TIA Portal, all data blocks arrive as "standard" (non-optimized) for compatibility. TIA Portal's default for new projects is "optimized." These are not just different settings — they represent a fundamental change in how the S7-1500 stores and accesses data. Understanding the difference is essential for every migration project.

The Core Difference#

Standard Data Blocks (Legacy Mode)#

In a standard DB, every variable has a fixed byte address. You can access it by name ("DB1".Temperature) or by absolute address (DB1.DBW0). The memory layout is sequential — variables are stored in the order you declare them, with fixed offsets.

// Standard DB layout:
// Offset 0:   Temperature  (REAL, 4 bytes)  → DBD0
// Offset 4:   Pressure     (REAL, 4 bytes)  → DBD4
// Offset 8:   Status       (BOOL, 1 bit)    → DBX8.0
// Offset 8.1: Alarm        (BOOL, 1 bit)    → DBX8.1
// Offset 10:  Counter      (INT, 2 bytes)   → DBW10

The problem: If you insert a new REAL variable between Temperature and Pressure, everything below shifts by 4 bytes. Pressure moves from DBD4 to DBD8. Every reference to DBD4 in the entire program — and in every HMI, SCADA, and OPC connection — is now wrong. This was the single most frustrating aspect of STEP 7 Classic programming.

Optimized Data Blocks (Modern Mode)#

In an optimized DB, variables have no fixed byte address. They are accessed exclusively by symbolic name. The CPU compiler arranges them internally for optimal access speed and memory efficiency. The programmer never sees or controls the physical layout.

// Optimized DB: no addresses visible
// "DB1".Temperature   → REAL  (stored somewhere optimal)
// "DB1".Pressure      → REAL  (stored somewhere optimal)
// "DB1".Status        → BOOL  (stored somewhere optimal)
// "DB1".Alarm         → BOOL  (stored somewhere optimal)
// "DB1".Counter       → INT   (stored somewhere optimal)

The benefit: Insert a variable, remove a variable, reorder declarations — nothing else changes. No address shifts. No broken references. No HMI updates. The symbolic name is the identity, not the byte offset.

Detailed Comparison#

What Happens During Migration#

When you migrate a STEP 7 Classic project to TIA Portal:

1. All DBs are set to "Standard" — TIA Portal preserves the absolute addresses so the migrated code compiles without changes
2. All FBs and FCs are set to non-optimized — same reason
3. The program works identically — this is the correct initial state

Do NOT immediately switch all DBs to optimized. This would break every absolute reference in the program and every external connection.

The Right Migration Path#

Phase 1: Migrate and verify — Keep everything standard. Verify the program works identically to the original.

Phase 2: Convert block by block — Pick one FB/FC/DB at a time. Switch to optimized. Replace all absolute references with symbolic. Test. Repeat.

Phase 3: Update external connections — Convert PUT/GET communication to OPC UA or TSEND/TRCV. Update HMI connections to use symbolic addressing.

This phased approach can take weeks for a large project. But each converted block delivers the benefits of optimized access immediately.

When to Keep Standard (Non-Optimized) DBs#

There are legitimate reasons to keep specific DBs in standard mode:

1. PUT/GET communication with other S7 PLCs. PUT/GET transfers data by absolute byte address. If two PLCs exchange data via PUT/GET and you optimize the DB on one side, the other side sends data to the wrong location. Both sides must agree on the byte layout.

Workaround: Create a dedicated "communication DB" in standard mode for PUT/GET data exchange. Keep all other DBs optimized.

2. OPC DA (classic) connections. OPC DA clients access data by absolute address (DB1.DBW0). Optimized DBs do not expose absolute addresses.

Workaround: Switch to OPC UA, which uses symbolic names. S7-1500 has a built-in OPC UA server.

3. Third-party systems with fixed byte-offset access. Some older HMI systems, SCADA servers, or MES interfaces read DB data by fixed byte offset. These break when DBs are optimized.

Workaround: Create a standard "interface DB" for the external system. Copy data from optimized DBs to the interface DB in the PLC program.

4. Block-level data access with PEEK/POKE. Some advanced code uses PEEK/POKE or BLKMOV with absolute addressing. These require standard DBs.

When to Always Use Optimized DBs#

• All new development on S7-1200/1500
• Instance DBs for FBs (optimized multi-instance is significantly faster)
• Large data containers (>768 KB requires optimized DB)
• Any DB where variables are added/removed frequently
• Any DB accessed via OPC UA

Practical Example: The Retain Difference#

In a standard DB, the retain setting applies to the entire block. Either all variables survive a power cycle, or none do.

In an optimized DB, each variable can be individually set to retain or non-retain:

// Optimized DB — individual retain control
DATA_BLOCK "DB_Machine"
  VAR
    cycleCount      : DINT := 0;     // Non-retain: reset on power cycle
    totalParts      : DINT := 0;     // Retain: survives power cycle
    currentRecipe   : INT := 1;      // Retain: keep selected recipe
    motorRunning    : BOOL := FALSE; // Non-retain: safe restart state
  END_VAR

This is a significant safety and functionality advantage. In standard DBs, you would need separate "retain" and "non-retain" DBs to achieve this — adding complexity.

Performance Impact#

The Siemens Programming Guideline states that optimized blocks have no performance disadvantage compared to standard blocks on S7-1500. In fact, they are typically faster because:

• The compiler can optimize memory alignment for the CPU architecture
• S7-1200/1500 use Little-Endian internally — optimized blocks avoid the Big-Endian conversion overhead that standard blocks require
• Boolean variables are stored as full bytes in optimized blocks, enabling faster single-instruction access

For programs with heavy DB access (data processing, recipe management, batch control), the performance difference is measurable.

How PLCcheck Pro Helps#

PLCcheck Pro analyzes your STEP 7 Classic program and identifies:

• Every absolute DB reference that must be converted to symbolic before optimizing
• DB variables accessed by PUT/GET (must stay standard or be restructured)
• DB variables accessed by HMI/SCADA (external interface inventory)
• Recommended block-by-block optimization sequence

This analysis is the prerequisite for a controlled migration from standard to optimized DBs — without breaking anything.

Analyze your DB access patterns →

Frequently Asked Questions#

Can I mix standard and optimized DBs in one project?

Yes. This is the recommended approach during migration. Communication DBs stay standard, everything else becomes optimized. TIA Portal has no problem with mixed projects.

Does switching a DB from standard to optimized delete my data?

No data is lost. But all absolute references (DBW0, DBD4, etc.) become invalid and must be replaced with symbolic names before recompilation. TIA Portal will show compilation errors for every invalid reference — which is actually helpful because it identifies exactly what needs changing.

Why are BOOLs stored as bytes in optimized DBs?

The S7-1500 CPU can access a full byte in a single instruction but needs additional instructions to access individual bits within a byte. Storing each BOOL as a full byte uses more memory but provides faster access. Since S7-1500 has abundant memory, this is the right trade-off.

Maintained by PLCcheck.ai. Last update: March 2026. Not affiliated with Siemens AG.