OPN Instruction on S7-1500 Disable Optimized Block Access in TIA

Overview: OPN, OPNDI, and the S7-1500 STL Compiler

The OPN (Open Data Block) and OPNDI (Open Instance Data Block) instructions are part of the STEP 7 STL (Statement List) instruction set. They load the number of a global data block into the DB register, or the number of an instance data block into the DI register, so that subsequent absolute DB-relative accesses such as L DBW 0, T DBB 4, or U DIX 0.0 resolve against the opened block. In the S7-300/400 generation these instructions were the canonical way to write compact, register-driven STL against absolute DB addresses.

On the S7-1500 generation, the same instructions are still implemented in firmware and exposed by the TIA Portal STL editor, but the compiler enforces a precondition that did not exist in the older systems: the target data block — and, in many configurations, the calling block — must be configured for standard (non-optimized) block access. If either block is configured for optimized access, the compiler rejects the instruction with the message:

The instructions "OPN" and "OPNDI" are only allowed in blocks with standard access.

This article walks through the root cause, the configuration steps to clear the error, the constraints around variable DB numbers (BLOCK_DB inputs), and the verification sequence. It applies to CPU firmware V1.8 and later on S7-1500, S7-1500R/H (redundant), ET 200SP CPU, and the S7-1500 Software Controller, with TIA Portal V13 through V20.

Why Optimized Blocks Reject OPN

The S7-1500 data model separates two block-storage philosophies:

The OPN instruction inherently relies on absolute offsets inside the opened DB. The CPU loads the DB number into the DB register, and the next L, T, U, ==I, or any other STL operation with a DBx operand resolves to DB_base_address + offset. With optimized blocks, the compiler cannot guarantee that DBW 0 actually maps to offset 0 of the declared tag set, because the compiler is free to reorder, pack, and align tags. The same is true at runtime if the compiler preserves a stable symbolic slot — but the system prohibits mixing this with OPN-driven absolute access.

This is why the error references "standard access" rather than "a specific firmware limitation." The instruction is supported; the access model is not.

Prerequisites

1. TIA Portal V13 SP1 or later (V13 SP2+ recommended for STL/OPN improvements). V16 and later add stricter checks on legacy STL fragments.
2. S7-1500 CPU with firmware V1.8 or later. OPN is documented for V20 in the current Siemens TIA Portal Help: OPN — Open Data Block in DB Register (S7-1500) reference page.
3. The STL block in which OPN is used must already be authored in an STL source file, an STL FC/FB/OB, or a block whose language is set to STL.
4. You must be able to modify the attributes of the DB being opened and, in some setups, of the calling block (OB/FB/FC).
5. PLC data consistency: changing a DB attribute from optimized to standard after the PLC has downloaded and consumed symbolic HMI/OPC bindings will invalidate those bindings — capture the project before flipping the attribute.

Step-by-Step: Clearing the "OPN Only Allowed in Standard Access" Error

Step 1 — Open the DB properties

1. In the project tree, expand Program blocks.
2. Right-click the target data block (for example, DB100) and select Properties.
3. In the left-hand navigation of the Properties dialog, choose Attributes.
4. Uncheck the box labeled Optimized block access.
5. Confirm with OK.

The DB is now a standard-access block. Its tag declarations retain their declared offsets; absolute DBW/DBB/DBX addresses are now addressable both in the editor and at runtime.

Step 2 — Verify the calling block access model

If the OPN instruction lives inside an FB or FC that itself is optimized, the compiler will still complain about the access model of the surrounding code. Open the calling FB/FC properties and repeat the procedure:

1. Right-click the FB/FC, choose Properties.
2. Navigate to Attributes.
3. Disable Optimized block access.
4. For an FB, also confirm Parameter passing via registers is selected if you rely on the legacy register-parameter mechanism (this is also required for any IN/OUT parameters of type BLOCK_DB).

Step 3 — Recompile in the correct order

The TIA Portal compiler resolves STL absolute references against the DB symbol table only after the DB has been compiled. If you simply flip the attribute and click Compile on the project, the compiler may still see stale information. Use the explicit order:

1. Right-click the DB → Compile → Software (rebuild all blocks).
2. Right-click the FB/FC containing OPN → Compile.
3. Right-click the entire Program blocks folder → Compile → Software (rebuild all blocks) for the final pass.

After the second compile step the OPN-related error message should clear. If it persists, inspect the Messages pane for an "indirectly referenced" optimization flag on a nested FB or multi-instance DB.

Step 4 — Download and verify in the device

1. Select the PLC in the project tree.
2. Click Download to device → Hardware and software (only changes), or do a full download if the access-model change is structural.
3. After download, go online and force the DB number into a known state (or set the DB to retentive defaults).
4. In an STL watch table, execute the OPN line and observe the DB register via STW/STW_DB monitoring or a READ_DBL watch if exposed.

Using OPN with a Variable DB Number (BLOCK_DB Input)

A common legacy pattern from S7-300/400 code is to make the DB number a parameter of the FB so that one FB instance can operate on different global DBs:

FUNCTION_BLOCK FB50
VAR_INPUT
  iDB : BLOCK_DB;
END_VAR
VAR_TEMP
  wValue : WORD;
END_VAR
BEGIN
    OPN   #iDB;            // Open the DB whose number was passed in
    L     DBW 0;           // Read offset 0 of the opened DB
    T     #wValue;
END_FUNCTION_BLOCK

This pattern continues to work on the S7-1500 as long as three conditions are met:

1. The FB FB50 itself has Optimized block access disabled.
2. The target DBs (DB100, DB200, …) all have Optimized block access disabled.
3. The BLOCK_DB input is connected to a constant DB (for example DB100) or to a tag that resolves to a valid, downloaded DB number at runtime.

The TIA Portal compiler validates conditions 1 and 2 statically. It cannot validate condition 3 because the DB number is dynamic; a runtime check will fault with SF (system fault) and a diagnostic buffer entry of "Area length error when reading" or "DB not loaded" if the passed DB number does not exist or is not standard-access on the active CPU.

OPN, OPNDI, CDB, and the DB/DI Register Pair

Internally the S7-1500 maintains two registers:

The same access-model rule applies to OPNDI: instance DBs opened via OPNDI must also be standard-access. On the S7-1500 the recommended modern pattern is to use fully qualified symbolic instance access (e.g., #iAxis.iPosition) instead of OPNDI, but OPNDI is still required for any STL code that manipulates instance data through absolute offsets — common in motion, cam, and legacy FB libraries.

Compiler Rules Around Mixed Access

When the compiler sees an STL block containing OPN, it inspects the access attribute of every DB that could be opened — directly referenced by number or via a BLOCK_DB input. The compiler rejects the build if any reachable DB is optimized. Practical implications:

• If you add a new DB to the project and the FB contains OPN, the new DB is also forced into the standard-access model unless you refactor.
• Reusable libraries (LBC type blocks distributed as type FB) cannot enforce this at the type level — each instance site must check.
• Splitting the access model mid-project (some DBs optimized, some standard) is allowed but forces the calling STL block to operate against the standard subset only.

Migration Notes from S7-300/400 to S7-1500

Migrating an S7-300/400 program that uses OPN to an S7-1500 target in TIA Portal introduces several predictable issues. Address them in this order:

1. Block attribute reset. Migration from STEP 7 Classic to TIA Portal can mark converted DBs as optimized by default. Open each DB used by OPN and disable the optimization attribute.
2. Address-model sanity check. S7-300/400 STL frequently relies on byte-aligned word reads. The S7-1500 with non-optimized blocks still places WORD and INT tags on byte boundaries, but multi-byte structures may differ if you had hand-edited offsets in the Classic project.
3. DB number conflicts. S7-1500 reserves DB numbers 0–15 for system purposes; using OPN DB0 through OPN DB15 in legacy code will produce runtime errors. Remap to DB 16+.
4. Removed STL operations. A small set of legacy operations (MAS, MAB, MBA, MSA, MSB) are no longer supported on S7-1500 STL. The compiler will reject them — replace with ==D, ==I, or SCL.
5. BLOCK_DB behavior. In S7-300/400, passing a DB number that was not loaded produced a graceful fault. On S7-1500, the same fault is reported through the diagnostic buffer with a more specific event ID; use the diagnostic buffer rather than legacy SZL lists.

Troubleshooting Matrix

Verification Checklist

1. In the project tree, confirm every DB used by OPN shows the standard-access icon (no optimization marker).
2. Right-click the program blocks folder → Compile → Software (rebuild all blocks) with zero errors and zero warnings related to OPN, OPNDI, or access model.
3. Open the STL block in the editor. The OPN line should be free of red squiggles; hover should show "OK" rather than "Compiler error".
4. Download to the CPU and go online. Open a watch table. Set a break on the line after OPN. Force the DB register to the expected number (STW monitoring if available, or read DBB 0 directly to confirm mapping).
5. If using BLOCK_DB, write a small test routine that opens DB100, reads DBW 0, then opens DB200 and reads DBW 0 — both should return valid values.
6. Capture the diagnostic buffer before and after each OPN sequence to confirm no SF entries are logged.

Performance and Safety Considerations

Disabling optimized block access on a DB does not change runtime behavior at the instruction level — DBW reads are still single-load operations. The cost is at compile time and at the symbolic interface: non-optimized DBs expose their offsets to HMI, OPC UA, and to any other consumer that reads the DB layout. From a functional-safety perspective (S7-1500F), safety programs require non-optimized FBs for many legacy F-runtime libraries; the same attribute also applies to the F-DBs. Plan attribute changes with the F-runtime documentation in hand.

FAQ