On the S7-1500, a new data block normally uses optimized access. You address its variables by name, and the compiler chooses their memory layout for processor access. A standard block instead exposes fixed byte.bit offsets for absolute addressing. The illustration compares these access models; its packing diagram is simplified and must not be used as an exact memory map for this controller.
Both columns declare the same five variables, in the same order. On the left, standard access follows declaration order and alignment rules. The shaded spaces show padding in this illustration. On the right, optimized access reorders the variables for access. The picture puts the Bools first at one byte each, as an S7-1500 stores them, but the order is not an exact controller layout. Use the switch to compare the illustration, not to calculate the memory required by a real project.
Because optimized access uses symbolic names, you can't write %DB20.DBX4.0 as an absolute address for the optimized block. Bit 4.0 is not a fixed location exposed by that access model. The compiler manages placement; your program refers to the variable by name. Adding variables still requires checking the relevant compilation, download and reinitialization conditions.
✅ Stay optimized when the program and its interfaces support symbolic access. This is the default for new blocks on the supported controllers. It avoids depending on manually calculated offsets, but does not mean that every layout occupies less memory or that every change can be downloaded without reinitialization.
⚠️ Switch to standard when an interface requires absolute addressing, such as a legacy communication block, byte-oriented access through SLICE/pointers, or code that uses fixed addresses.
Migration trap: convert an old standard DB to optimized and every absolute %DBxx.DBXy.z reference can become invalid, including HMI references that use those offsets. Review the references and change supported connections to symbolic names before converting the block. Check the resulting program and connections after the conversion.
In an optimized DB, the Offset column is blank/greyed. Why can't you just read the byte address?