TIA Portal Data Block Offset Display Show Absolute Addresses

Overview: Why the DB Offset View Matters

In classic STEP 7 (V5.5 and earlier), every Data Block (DB) opened in the editor showed two clearly separated panes: the Declaration view (where you typed the variable name, type, and initial/comment) and the Data view (where the actual runtime values were monitored, forced, and where each variable carried an absolute byte/bit offset column). Programmers relied on the Data view to map S7 symbols onto the raw memory layout required for OPN DB/L DBW calls, indirect addressing, and HMI tag bindings.

When TIA Portal (originally SIMATIC STEP 7 Professional / Basic, today the engineering framework inside the TIA Portal) replaced the classic tool, the editor was redesigned. The DB tab now exposes both the declaration area and the data area in a single combined grid, and the offset column is the only element that distinguishes the classic "Data view" from the classic "Declaration view". This causes recurring confusion for engineers who:

• Need to know the absolute byte address of a tag inside a STRUCT or ARRAY (for HMI tag configuration, Profibus/Profinet slot assignment, or cross-reference to a foreign device).
• Are converting STEP 7 V5.5 projects that used absolute addressing (e.g., DB100.DBD200) and want to verify the TIA Portal layout matches.
• Are diagnosing a fault that points to a specific offset, such as a Profinet diagnostic frame referencing byte 247 of a receive DB.
• Are writing generic blocks (FB/FC) that perform pointer arithmetic on the incoming VARIANT or ANY pointer.

This article documents every method available in TIA Portal V14 through V19 to surface absolute offsets, explains why the column sometimes disappears, and walks through the optimized/non-optimized access switch that controls offset visibility in the first place.

Prerequisites

• SIMATIC STEP 7 Professional V14 SP1 or higher (V16, V17, V18, V19 covered explicitly; the V19 behavior is the most complete).
• Target CPU: S7-1200 (firmware V4.0 or higher) or S7-1500/ET 200SP CPU. S7-300/400 CPUs are not programmed with TIA Portal in normal use, but the same rules apply when a legacy project is opened in TIA.
• The DB must be in your project tree under Program blocks > System blocks / Program blocks.
• For column-based work, the project must be open in editable state (no exclusive access by another online user).

DB View Modes in TIA Portal

TIA Portal does not have a tabbed "Declaration view / Data view" toggle like the classic editor. Instead, a single DB tab adapts its contents to the state of the project:

The offset column is the anchor feature. Once it is visible, every variable carries a byte-granular address such as 0.0, 2.0, 4.0. For bit-level tags a sub-offset is rendered as e.g. 6.3 (byte 6, bit 3). The display is decimal; right-click the column header to switch to hexadecimal if the project is configured for hex display.

Method 1: Enable the Offset Column via Right-Click

The fastest, least-invasive path. Use it when the DB is open and you can see the column header row but no Offset column.

1. Double-click the DB in the project tree to open the editor.
2. Hover the mouse over any column header (Name, Data type, Initial value, Comment).
3. Right-click the header bar — a context menu opens listing every available column with a check mark next to the currently visible ones.
4. Click Offset to add the check mark.
5. Drag the Offset header to the position you want (TIA remembers the position per user, not per project).

This method works for both optimized and non-optimized DBs. The column always shows, but the values are meaningful only on non-optimized DBs (see Method 3).

Method 2: Toggle to the Classic "Data View" Using the Online View Selector

TIA Portal does not literally call the runtime pane "Data view", but it gives you the same capability through the Monitor on/off button in the toolbar.

1. Compile the project and download the DB to the CPU (or have an existing online connection).
2. Open the DB and click the glasses icon (Monitor on/off) in the toolbar, or press Ctrl+F7.
3. The grid switches to a read-only layout where each row shows the actual value column populated with the live process value. The offset column is still present and is the key reference for HMI / cross-target work.
4. To modify a value, type into the actual-value cell and press Enter. A confirm dialog appears listing every cell you are about to change. Accept with OK only after the safety review (see the Safety section below).

Method 3: The Critical Switch — Optimized vs Non-Optimized Access

This is the heart of the question. The Offset column is only meaningful when the DB is configured for non-optimized (sometimes called "standard") access. When a DB is optimized, the compiler is free to reorder the variables to improve cache performance and to overlay them with system areas used for download management. The byte offsets you see in an optimized DB are symbolic offsets: they are not the physical byte address in the load memory.

How to check the current access mode

1. Right-click the DB in the project tree and choose Properties.
2. Select Attributes in the navigation panel.
3. Look at the checkbox Optimized block access.
4. Read-only summary: in the same dialog, Information > Cross-references shows whether any absolute address still references this DB (a hint that turning optimization off is required).

How to disable optimization

1. In the same Attributes page, uncheck Optimized block access.
2. Confirm with OK. A warning appears: "All absolute accesses to this data block must be checked."
3. Recompile the program. The compiler issues errors for every SCL/ST/LAD/FBD expression that referenced the block with an absolute address that no longer matches the new layout.
4. Download the hardware configuration and software to the CPU.

When you must keep optimization on

Some features are incompatible with non-optimized access:

• Downloading a single DB to the CPU without stopping the PLC (RUN mode download of a DB).
• Using the block as the data storage of an FB with Multiple instance capability on S7-1500 (multi-instance DBs are always optimized).
• Using the DB as the source/target of a MOVE_BLK_VARIANT or Serialize/Deserialize instruction with symbolic references and access-optimized code.
• Using the DB as the I/O data record of a Profinet/Profibus slave in some GSD-based devices that demand contiguous byte layouts (rare; Profinet IRT usually accepts both).

If you cannot turn optimization off, the next-best workflow is to create a non-optimized mirror DB that contains the same data layout in fixed positions and to MOVE_BLK the optimized block into the mirror on every cycle. This pattern is common for OPC UA servers and Profinet diagnostics.

Method 4: Display the Offset Inside STRUCT and ARRAY

Engineers frequently need the offset of a member inside a nested structure (for example, the third element of an array of UDTs, or a specific field of a complex type). TIA Portal's behavior here is version-dependent:

For older versions the workaround is:

1. Click into the STRUCT row to expand it.
2. Look at the Start offset shown for the parent (e.g. Offset 12.0).
3. Add the size of preceding members manually. The size is given in the Data type column (BOOL = 1 bit/byte boundary, BYTE = 1, WORD = 2, DWORD = 4, LWORD = 8, INT/REAL = 4, DINT/LREAL = 4/8, STRING[n] = n+2, WSTRING[n] = 2n+4, DATE_AND_TIME = 8, DTL = 12).
4. Confirm with a Cross-reference (right-click the symbol > Go to > Usage) and read the absolute address in the operand of any L/T/OPN instruction that references the variable.

Method 5: Use the Cross-Reference Tool as an Offset Source

When the offset column is hidden, suppressed, or hidden behind a graphical SCL expression, the cross-reference tool gives the absolute address anyway.

1. Right-click any tag inside the DB and choose Go to > Cross-references (or press Ctrl+Alt+F7).
2. The Inspector window opens the Cross-references tab and lists every access: address, block, language, network, symbol.
3. The Address column shows the absolute operand, e.g. DB100.DBX12.0 (bit) or DB100.DBW14 (word). This is the byte/bit address that the compiler assigned and is identical to the value in the Offset column for non-optimized blocks.

Method 6: Programmatic Offset Lookup Using SCL

For projects with many DBs and automated documentation, a small SCL routine can dump the offset of every tag. The standard pointer arithmetic instruction is PEEK or the system function GetSymbolAbsoluteAddress (S7-1500, available in the basic program of the CPU).

// SCL fragment - read the absolute address of "MyTag" inside "MyDB"
#retVal := GetSymbolAbsoluteAddress(
    symbolName := ""MyDB".""MyTag""",
    bitOffset  := #bitOffset,
    byteOffset := #byteOffset,
    area       := #area,
    areaOffset := #areaOffset);
// #byteOffset now holds the byte address relative to the DB start

Cross-Platform Note: S7-300/400 Projects Opened in TIA Portal

When a STEP 7 V5.5 project is migrated to TIA Portal, every DB is automatically imported as non-optimized, because the original S7-300/400 firmware has no concept of optimized block layout. The Offset column is always present in the migrated DB. This is why a user opening an S7-300/400 DB in TIA Portal sees offsets even when a peer who programs S7-1200/1500 sees none — the difference is the optimization flag, not the editor.

If the S7-300/400 project is then re-targeted to an S7-1500 CPU, TIA Portal offers to keep the DB non-optimized for compatibility (the safe option for migrations) or to optimize it. Choose Keep as non-optimized for the first migration, and only re-optimize after you have audited every absolute access.

Safety and Process-Critical Considerations

Modifying DB values from the Data view is a live operation against the running CPU. The following rules apply regardless of the TIA version:

• Always perform the modification with a second engineer observing (the so-called four-eyes principle). TIA does not enforce this, but the safety log will show the user name that performed the change.
• Open the Safety > Audit log (TIA V17 and newer) to record the modification. Configure the audit log under Project tree > CPU > Properties > Security.
• Disable the Modify from partner / HMI feature on safety-related F-CPUs. The F-CPU firmware refuses all online modifications to F-blocks anyway, but DBs containing safety-related mirrored state can still be modified; protect them with the CPU's access level password (level 4: read/write with password).
• Use Force with extreme caution. Forced values persist across CPU restart if the DB is retentive. Clear forces with the Cancel forcing button before downloading the project again, otherwise the download will fail with diagnostic buffer entry 0xE2 ("Force job cannot be performed because another force job is active").

Troubleshooting Matrix

Field-Proven Tips and Best Practices

1. Add a comment line at the top of every non-optimized DB stating the byte size and the largest offset, e.g. // DB occupies bytes 0..199, last member at 198. The next maintainer will thank you.
2. For HMI bindings, always create the tag in the HMI by drag-and-drop from the PLC tag table. This generates a symbolic reference that does not depend on the byte offset and survives re-ordering of the optimized DB.
3. For external consumers that need a fixed offset (e.g. a Profinet IRT device with a GSD-defined record), use a non-optimized DB with the same byte layout as the consumer's record. Document the byte size in the comment of every member.
4. When porting an S7-300/400 program that uses DB100.DBD200 heavily, keep DB100 non-optimized forever. The cost of an unoptimized block on an S7-1500 is negligible (typically < 5 % cache impact, measured on a 1515-2 PN).
5. Use the "Monitor with trigger" mode (right-click the value > Trigger) when diagnosing an intermittent fault. The trigger condition can be a comparator (==, <>, <, >), a bit pattern, or a rising/falling edge. This is the most underused feature of the Data view.
6. If the project has more than 50 DBs, enable Tools > Settings > PLC programming > Show offsets in DB globally. TIA then remembers the column visibility per user across all projects.

Verification Checklist

After applying any of the methods above, confirm the result with these checks:

1. Open the DB. Confirm the Offset column is visible and shows byte-granular values.
2. Click into a STRUCT or ARRAY member. Confirm the offset is non-zero and matches the parent offset + the size of preceding members.
3. Right-click a variable and open the cross-reference list. Confirm the Address column reads the same value as the Offset column.
4. Compile the project. The compile log should show zero warnings about "DB cannot be accessed absolutely" or "Optimized block contains pointer accesses".
5. Download the project to the CPU. Open the online Data view (glasses icon) and confirm the actual-value column populates within a few scan cycles.
6. Modify one value from the online view. Confirm the value changes in the running process and that the safety audit log records the user, the timestamp, and the new value.
7. Restart the CPU. Confirm the new value is retained (only if the DB is configured as retentive and the value is a retentive tag).

FAQ