The checkbox says “optimized block access”; the consequences run through your whole program’s philosophy.
What it changes
Standard (non-optimized) DBs preserve the classic S7 memory image: every variable at a fixed byte/bit offset you can address absolutely (DB10.DBX4.2). Optimized DBs abandon fixed offsets: the compiler arranges variables for the CPU’s fastest access, booleans stop costing whole bytes of alignment waste, access is symbolic-only — and notably faster on 1500 hardware. You also gain per-element retentivity (retain just the recipe struct, not the whole DB) and download-without-reinitialization behaviors that make life on running machines gentler.
When standard is still right
Anything that computes offsets outside the compiler’s knowledge: raw communication buffers parsed by pointer, some third-party HMI/SCADA drivers speaking absolute addresses, legacy code migrated with pointer arithmetic (ANY pointers, SFC20-era copying), and data exchanged with systems that were told “DB10, byte 4”. The clean pattern for those cases is a small standard “interface DB” at the boundary — and optimized everything behind it.
Mixing rules: symbolic access crosses both worlds fine; slice access and AT overlays have restrictions in optimized blocks — if your style leans on overlay tricks, that is legacy style asking for refactoring, not a reason to abandon optimization.
FAQ
Is the performance difference real? On S7-1500, yes — optimized access is the native mode of the machine; standard access is emulated compatibility. Heavy programs measure the difference.
Default for new projects? Optimized everywhere, standard only at explicitly documented boundaries. The reverse default is technical debt from day one.
Zone Otomasyon migrates legacy pointer code into clean optimized structures during retrofits. Code modernization.