TIA Portal V12 Block Access: Enabling Standard DB Offsets

Overview

In TIA Portal V12, every new Data Block (DB) created for an S7-1500 CPU is, by default, configured with the Optimized block access attribute. The side effect is that the offset column of the DB no longer displays the absolute byte/bit addresses engineers traditionally rely on (e.g., DB1.DBD0, DB1.DBX4.0). Address fields appear blank, symbolic names remain fully functional, and any external HMIs, third-party tools, or legacy code expecting fixed offsets break.

This reference documents the correct procedure to switch a DB back to standard block access in TIA Portal V12, explains the grayed-out checkbox case, and lists the firmware, CPU, and migration constraints you need to verify before changing the attribute.

Block Access Modes at a Glance

Prerequisites

1. TIA Portal V12 (V12.0 / V12 SP1) or later installed; matching the firmware range of the target CPU.
2. An S7-1500 / ET 200MP CPU project – on an S7-300/400 the attribute is fixed and the dialog differs.
3. CPU firmware V1.5 or higher for full optimized-block access features (V1.0 supports it with limitations; V1.6+ adds full RUN-mode download improvements).
4. Source code offline; do not attempt to toggle the attribute while the CPU is in RUN with a live HMI polling absolute offsets.
5. If the DB is referenced from a library (master copy / type) with locked attributes, unlink the type first or accept that the change must be made in the library master.

Step-by-Step: Switch a DB to Standard Block Access (V12)

Method 1 – Set During DB Creation

1. In the project tree, right-click Program blocks → Add new block → Data block (DB).
2. In the Add new block dialog, expand the Type dropdown and select DB (data block).
3. Set Name and Number as required (e.g., DB10).
4. For an S7-1500 target, the Type selector offers a checkbox labeled Standard-compatible for S7-300/400 in older service packs; in V12 SP1 it is the radio Standard block access. Select this option.
5. Click OK to create the DB. The newly created DB will now expose a fixed offset column (Byte offset / Bit offset).
6. Right-click the Program blocks folder → Compile → Software (rebuild all blocks) so that all dependent FBs, FCs, and OB references are re-resolved against the new layout.

Method 2 – Change Attribute on an Existing DB

1. In the project tree, right-click the existing DB and choose Properties.
2. Open the Attributes tab.
3. Locate the Optimized block access checkbox. Uncheck it. The setting is grey-highlighted only when the project is part of a library type with locked attributes; in that case use Method 3.
4. Confirm with OK.
5. Re-compile the entire Program blocks folder. Open blocks that referenced the DB by absolute address will now resolve correctly; any symbolic-only references continue to work unchanged.
6. Download the new program to the CPU. With optimized block access removed, the DB layout changes: a STOP/start or warm restart of the CPU is normally required when a DB switches from optimized to standard, because retentive areas and the runtime memory model differ.

Step-by-Step: When the Checkbox Is Grayed Out (Locked)

The Optimized block access checkbox can be locked for the following reasons. Resolve them in the order shown.

1. Library type usage. The DB was generated from a type in a master-copy library; the attribute is fixed by the type.
   Fix: open the master copy library, change the attribute there, re-publish the type, and update the instances in the project (Right-click library → Update instances).
2. Know-how protection. The block is know-how protected.
   Fix: remove the protection (Properties → Protection → Remove), change the attribute, re-apply protection if required.
3. CPU family locked. The target CPU is set to a profile that forces optimized access (e.g., some S7-1500 firmware-specific templates).
   Fix: right-click the PLC → Properties → Protection & Security; verify nothing is forcing the layout. In V12 the field is on the Compilation sub-tab under the Block access group.
4. Project is read-only / checked in. In multi-user (TiaMultiuser) or with PLCSIM attachment, the DB may be checked in.
   Fix: check out the DB, retry.
5. Cross-compiled S7-300/400 reference. The DB still references a UDT or area that originated from an S7-300/400 program; the compiler locks the attribute.
   Fix: delete the cross-reference, change the attribute, then re-add the reference – the DB is now editable.

Technical Differences Engineers Must Understand

Address visibility

Standard block access displays, for each tag, an absolute address column (%DB1.DBX0.0 in symbolic view, DB1.DBX0.0 in absolute view). Optimized block access hides this column entirely – the only address shown is the symbolic one.

Retain granularity

With optimized access you can set the Retain attribute on individual tags inside the DB. With standard access, retain is set for the whole block. Programs that rely on partial retain (e.g., a recipe DB that retains the recipe index but not the temporary flag) must use optimized access.

Download in RUN

Optimized blocks support incremental download in RUN with no loss of process values for tags whose layout has not changed. Standard blocks require a STOP→RUN transition after structural changes.

Symbolic vs absolute consumers

• WinCC (TIA) / Comfort Panels – read symbolic tags from optimized blocks transparently.
• Third-party HMIs (Pro-face, Beijer, Red Lion, etc.) – usually need absolute offsets. Configure the DB as standard.
• OPC DA / Modbus gateways – typically need offsets. Configure as standard.
• Put/Get (S7-communication) from a remote PLC – needs absolute addresses; use standard.

Firmware and Migration Notes

When migrating a STEP 7 V5.x project containing a DB with explicit offsets, the TIA V12 migrator keeps the original standard layout only if you select Standard-compatible for S7-300/400 in the migration wizard. The default migrator path on S7-1500 targets preserves the data, but switches the new block to optimized, so all absolute references in third-party code need to be replaced by symbolic references or the attribute must be re-set to standard.

Verification

1. Open the DB in TIA Portal and confirm the Offset column is now visible (Byte offset and Bit offset).
2. Open an OB, FB, or FC that previously referenced DB10.DBD0 and verify the address resolves – no red squiggles.
3. Compile the project (Project tree → Program blocks → right-click → Compile → Software). The build must complete with no warnings about mismatched block access.
4. Download to the CPU. If the project was online, place the CPU in STOP first, then download, then RUN.
5. From the project tree, expand Program blocks → DB10, right-click → Monitor / Modify. The online values appear next to their absolute offsets, confirming the standard layout is active.
6. Trigger a CIP/Modbus/OPC read from the third-party consumer; offsets should now match the static table.

Troubleshooting Matrix

Best Practices

• Decide at project start. For a brand-new S7-1500 program that uses only TIA Portal components, leave optimized access enabled to retain per-tag retain and RUN-mode download benefits.
• For mixed-vendor or HMI absolute access, select Standard-compatible for S7-300/400 at DB creation. Do not toggle the attribute on a populated DB unless a STOP/reset is acceptable.
• Document the choice in the block header (title, comment) so future engineers know why offsets are or are not visible.
• Avoid mixing optimized and standard DBs that exchange data through a shared UDT – the compiler does not block this, but the offsets will not be portable between projects.
• Use DBs of type Global DB for exchange with HMIs and gateways; reserve Instance DBs for FB-static data and accept that instance DBs are always optimized on S7-1500.
• When migrating from STEP 7 V5.x, export the absolute address list (Excel) before the migration so you can audit offset changes after the DB is re-created.

Field-Commissioning Checklist

1. Before on-site work, verify the TIA Portal version on the programming laptop matches the project (V12 / V12 SP1 / V13).
2. Open the project offline and audit every DB: right-click the Program blocks folder → Compile → Software; any addressable error must be resolved before traveling.
3. Confirm the CPU firmware on site matches the configuration – open Online → Accessible nodes, read the Order number and Firmware fields.
4. Bring a backup of the offline project (TIA Portal Project → Archive) on a separate USB drive.
5. During commissioning, place the CPU in STOP, perform a memory reset, download the project, then switch to RUN and verify the HMI and third-party clients.
6. Capture the DB offsets into the site As-built documentation immediately after the change is verified – a future firmware update can re-trigger the same question.

FAQ