S7-1200 SCADA Tag Read Failure: Absolute vs Symbolic Addressing

David Krause13 min read
SiemensTIA PortalTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

S7-1200 SCADA Tag Read Failure: Absolute vs Symbolic Addressing

Mixed fleets of S7-300 and S7-1200 CPUs in the same SCADA architecture are common during staged migration projects. The two controller families do not share an identical addressing model, and a SCADA/OPC client configured correctly for one family often fails silently against the other. This article documents the root causes of partial tag visibility, the diagnostic path that isolates the addressing mode from the transport path, and the corrective actions that restore full tag access without rewriting application code.

Field symptom covered: SCADA reads all tags from S7-300 CPUs and returns no values, E-FAIL, or partial reads from S7-1200 CPUs. Online monitoring in TIA Portal works on the same S7-1200; only the OPC/HMI read path is broken.

1. Problem Description

A typical mixed-flavor plant layout uses one PC station with SIMATIC Net (OPC Scout, WinCC, or a third-party SCADA) connecting to multiple controllers through the local S7Online access point:

  • 5x S7-300 CPUs (PROFINET or MPI accessible)
  • 3x S7-1200 CPUs (firmware V2.2 to V4.x, firmware V2.2 is the lowest still encountered in production fleets)
  • One PC station running TIA Portal V13/V14/V15/V16 and SIMATIC Net for OPC

Observed behavior:

  1. With the OPC access mode set to symbolic, the SCADA cannot read tags from any PLC.
  2. Switching the access mode to absolute restores reads from S7-300 but the S7-1200 tags remain unreadable.
  3. OPC Scout shows the tag in the namespace, but pressing Read returns E-FAIL instead of the current value.
  4. Direct TIA Portal Monitor/Modify on the same S7-1200 returns valid values in real time. The fault is in the HMI/OPC data path, not in the program.

2. Root Cause Analysis

The failure has three independent layers that must each be checked. Resolving one without the others leaves the symptom in place:

  1. Optimized data block access on S7-1200 hides the absolute offsets from any consumer that does not speak the S7-1200 symbolic API. S7-300 never had this option, which is why the older family continued to publish offsets while the newer family appeared empty.
  2. S7Online access point auto-routing binds the PC interface to a single PLC family when "Set automatically" is enabled. The PC station then resolves the wrong connection target for the other family and produces E-FAIL on read.
  3. CPU protection level with accessible from HMI unchecked blocks the PUT/GET path that OPC DA uses for absolute reads.

The combined diagnostic matrix:

Symptom Layer 1: Block access Layer 2: Access point Layer 3: Protection
Tags invisible in OPC Scout Symbolic only, no offset exposed Wrong interface auto-selected Full protection active
E-FAIL on read Optimized DB + absolute client S7Online bound to wrong subnet PUT/GET disabled
Offset column greyed out Optimized block access = ON n/a n/a
S7-300 works, S7-1200 fails S7-1200 only Common to both S7-1200 only

3. S7-300 vs S7-1200 Addressing Model

The addressing model is the single largest source of confusion in mixed fleets:

Attribute S7-300 S7-1200 (FW < 4.0) S7-1200 (FW ≥ 4.0)
Symbolic addressing in user program Optional (symbol table) Mandatory Mandatory
Optimized block access (DB) Not available Default ON since V4.0 Default ON
Absolute offsets exposed to OPC DA Always Only when optimized access is OFF Only when optimized access is OFF
OPC DA absolute read via S7 protocol Supported natively Requires PUT/GET permission and non-optimized blocks Same; OPC UA preferred for FW ≥ 4.4
OPC UA server built into CPU No No (FW < 4.4) Yes (FW ≥ 4.4)

The S7-300 family never implemented optimized block access. Its data blocks always carry stable byte offsets that OPC DA clients can address with the classic DBxx.DBBy notation. The S7-1200 introduced optimized blocks with TIA Portal V12 and made them the default starting with firmware V4.0. When the optimized attribute is set, the compiler is free to reorder variables inside the DB and the absolute offset column in TIA Portal is intentionally greyed out, because there is no meaningful physical address to publish.

This is why a SCADA that was originally built against an S7-300 and then extended to include an S7-1200 will read the older family cleanly and return nothing from the newer one, even when the same tag name and the same access mode are configured. The offset is greyed out in the DB properties is the diagnostic fingerprint of Layer 1.

4. Optimized vs Non-Optimized Data Blocks

The optimized attribute is a property of each individual data block, not a CPU-wide setting. Mixed DBs in the same project are legal and common: the engineer keeps frequently-internal scratch DBs optimized for performance and exposes only the HMI/OPC interface DBs as non-optimized.

4.1 Inspecting the attribute

  1. Open the data block in TIA Portal.
  2. Right-click the DB header in the project tree and choose Properties.
  3. Navigate to Attributes.
  4. Read the checkbox Optimized block access. If it is selected and greyed out, the block is locked into optimized mode by firmware policy; disable the checkbox to expose absolute offsets.

4.2 Required settings for absolute OPC reads

  • Uncheck Optimized block access for every DB that the SCADA addresses by offset.
  • If the project uses global constants or non-optimized bits inside a partially optimized block, split the DB so the HMI-visible area is its own non-optimized block. Partial optimization does not expose a stable offset to OPC DA.
  • Recompile the project after every change. The S7-1200 only rebuilds its symbol table on full download, not on online edit, so out-of-sync symbol tables are a common silent failure.

4.3 When you must keep optimized blocks

Performance-critical control loops and certain library blocks (LBC, LGF) require optimized access and cannot be converted. For those blocks, expose a thin interface DB that copies the relevant values out as non-optimized, or migrate the consumer to OPC UA where firmware V4.4 and later expose symbolic browse and read against optimized blocks natively.

5. S7Online Access Point and the "Set Automatically" Issue

The second root cause lives in the PC station configuration, not in the PLC project. SIMATIC Net uses an access point on the engineering station to map a logical S7 connection target to a physical network interface card. The access point S7Online is the default for STEP 7 and TIA Portal.

When the Set automatically checkbox is active in the Set PG/PC Interface dialog, Windows binding resolves the access point to the first interface that returns a response. In a mixed PROFINET/MPI environment with both S7-300 and S7-1200 controllers, this produces three failure modes:

  • The access point binds to the PROFINET interface that carries S7-1200 traffic; S7-300 reads then succeed only when the controller is also reachable on that subnet.
  • The access point binds to the MPI/TCP adapter that carries S7-300 traffic; the S7-1200 returns no response because no DCP/HTTP discovery reply is emitted on that interface.
  • The binding oscillates with every PC restart, which produces intermittent E-FAIL that engineers misdiagnose as firmware or cable issues.

5.1 Disable auto-routing

  1. Open Control Panel > Set PG/PC Interface (or search "Set PG-PC Interface" in Windows).
  2. Select the access point S7Online.
  3. Uncheck Set automatically.
  4. From the interface list, choose the exact TCP/IP adapter that connects to the PROFINET subnet carrying both S7-300 and S7-1200 controllers.
  5. Apply and close. Restart the TIA Portal and SIMATIC Net services so the OPC DA server re-reads the binding.

5.2 Configure separate access points for separate subnets

When the S7-300 controllers live on a different physical subnet than the S7-1200 controllers, two named access points give deterministic routing:

  • S7Online_PN1200 → TCP/IP adapter for the S7-1200 subnet
  • S7Online_PN300 → TCP/IP adapter for the S7-300 subnet

Reference the access points by name in SIMATIC Net Configuration Console and in the OPC DA server connection list. This decouples the binding from auto-discovery and makes the binding reproducible across reboots.

6. CPU Protection and HMI Access Settings

Even with the correct access point and non-optimized DB, the SCADA still receives E-FAIL if the CPU protection level denies the read request. The relevant attributes live in two places:

  1. Device configuration > Properties > Protection on the S7-1200 CPU.
  2. Connections > PUT/GET communication checkbox, which is a separate gate independent of the password protection level.

When Full access (no protection) is selected but the Permit access with PUT/GET communication checkbox is cleared, OPC DA reads against absolute offsets fail with E-FAIL while TIA Portal monitoring still works because the engineering tool uses a different (symbolic) channel. Setting Full access alone does not enable the OPC DA path on S7-1200. The PUT/GET checkbox must be on.

6.1 Recommended minimum-protection profile

  • Protection level: Full access (no protection) for development and commissioning PC stations.
  • Protection level: Read access or higher for production read-only SCADA, with the PUT/GET checkbox enabled.
  • Never use the legacy "cannot be remote accessed" level on a CPU that participates in OPC DA; it blocks both symbolic and absolute reads.

7. OPC Scout E-FAIL Diagnostics

When OPC Scout displays the tag but returns E-FAIL on Read, the diagnostic sequence is:

  1. Confirm the tag is bound to the right item ID, e.g. S7:[S7_1200]DB100,X0 for an absolute bit or S7:[S7_1200]DB100,BYTE0 for a byte. Mistyped item IDs return E_BAD_ITEMID, not E-FAIL; E-FAIL means the server reached the item but the read transaction failed.
  2. Open SIMATIC Net Configuration Console and verify that the connection named in the OPC server is Active. A connection stuck in Disabled returns E-FAIL on every read.
  3. Open Station Configuration Editor and check the IM/CP index assigned to the application. The OPC server uses slot indices, not symbolic names, so a wrong index silently routes reads to an empty slot.
  4. From TIA Portal, run Online > Accessible devices on the same PC station. If the S7-1200 is reachable here, the transport path is good and the failure is in the OPC item definition. If it is not reachable, the access-point routing is wrong and Step 5 of Section 5 must be repeated.

8. TIA Portal and Firmware Version Considerations

Tag-read failures often correlate with project/portal/firmware version mismatches:

S7-1200 Firmware Minimum TIA Portal OPC DA support OPC UA server built-in
V2.2 TIA V11 SP2 / V12 Yes (PUT/GET required) No
V3.0 TIA V12 SP1 Yes (PUT/GET required) No
V4.0 TIA V13 Yes (PUT/GET required) No
V4.1 / V4.2 TIA V14 / V15 Yes (PUT/GET required) No
V4.3 TIA V15.1 Yes (PUT/GET required) No
V4.4 TIA V16 Yes Yes (server license required)
V4.5 / V4.6 TIA V17 / V18 Yes Yes

A PC station running TIA Portal V13 cannot compile a project that targets S7-1200 firmware V4.4. The reverse is also true: a project built in TIA V17 cannot be downloaded to an S7-1200 firmware V2.2 because the system data blocks are incompatible. Mismatched versions between the engineering station and the target firmware do not always block online monitoring, but they routinely break the OPC DA server because the item definition was generated against a different symbol table layout.

If OPC UA is preferred over OPC DA, target S7-1200 firmware V4.4 or later, enable the OPC UA server function in the device configuration, and grant the SCADA client the Read and Browse authorization on the relevant DBs. This bypasses the optimized-block offset problem entirely because the OPC UA server reads symbolic names from the optimized blocks directly.

9. Step-by-Step Resolution Procedure

Run the procedure in order. Do not skip ahead; each step validates the layer that the next step depends on.

  1. Verify transport. From TIA Portal on the PC station, run Online > Accessible devices. Confirm that every S7-1200 appears with its IP address and firmware version. If any controller is missing, fix the network and access point (Section 5) before continuing.
  2. Disable auto-routing. In Set PG/PC Interface, uncheck Set automatically and bind S7Online to the correct TCP/IP adapter. If multiple subnets are in use, create named access points as in Section 5.2.
  3. Enable PUT/GET. In the S7-1200 device configuration, open Protection > Connection mechanisms and enable Permit access with PUT/GET communication from remote partners. Apply and download to the CPU.
  4. Convert HMI-visible DBs to non-optimized. For every DB that the SCADA reads, open its properties and uncheck Optimized block access. Recompile and download the project.
  5. Reconfigure OPC items. In the SIMATIC Net OPC server or WinCC tag management, switch the item access mode to absolute for S7-1200 tags. Use the syntax S7:[ConnectionName]DB<n>,<type><offset>, e.g. S7:[S7_1200]DB100,BYTE0.
  6. Validate with OPC Scout. Browse the server namespace, locate the S7-1200 items, and read each one. Confirm that the value matches the value shown in TIA Portal Monitor/Modify. If any item still returns E-FAIL, jump to Section 7.
  7. Lock down production access. Once reads are stable, raise the CPU protection level to Read access or HMI access as required, leaving the PUT/GET checkbox on. Verify that the SCADA still reads after the protection change.

10. Verification Checklist

Check Expected result Validation tool
All S7-300 controllers appear in Accessible devices Each CPU listed with IP and FW TIA Portal
All S7-1200 controllers appear in Accessible devices Each CPU listed with IP and FW TIA Portal
S7Online access point bound to intended adapter No automatic routing Set PG/PC Interface
OPC Scout browse shows S7-1200 DBs DBs visible with absolute offsets OPC Scout
OPC Scout read returns current values Matches TIA Portal monitor OPC Scout + TIA Portal
CPU protection allows HMI access PUT/GET enabled TIA Portal device config
Offset column greyed out in any DB None in HMI-visible DBs TIA Portal DB properties
Survives PC station reboot Tags continue to read Reboot + OPC Scout

11. Common Pitfalls and Field Notes

  • Disabling optimized access on a block that contains an ARRAY of STRUCT triggers a recompile error in older TIA Portal versions. Split the block so the HMI-visible area is its own simple-variable DB.
  • PUT/GET toggle reverts to off after a firmware update. Re-validate after every firmware upgrade on the S7-1200.
  • OPC server cache retains the old item definitions after a project recompile. Restart the OPC DA service to force a namespace refresh.
  • Windows firewall blocks port 102 (ISO-TSAP) on PC stations hardened after commissioning. Symptom is identical to a missing access-point binding: E-FAIL on every read.
  • Multiple OPC servers on the same PC compete for the S7Online access point. Disable the unused server or assign it a separate named access point.

12. Frequently Asked Questions

Why are absolute offsets greyed out in my S7-1200 data block?

The Optimized block access attribute is set in the DB properties under Attributes. Optimized blocks do not publish stable offsets because the compiler can reorder variables. Uncheck the attribute, recompile, and download the project to expose the offsets.

OPC Scout shows the tag but returns E-FAIL on Read. What does that mean?

The OPC server reached the item, but the read transaction against the PLC failed. The most common causes are PUT/GET disabled in the CPU protection settings, an S7Online access point bound to the wrong network interface, or a non-optimized block that was not recompiled after the attribute change.

Can a SCADA read optimized data blocks on S7-1200 at all?

Yes, through OPC UA on firmware V4.4 and later. The built-in OPC UA server reads symbolic names directly from optimized blocks. OPC DA cannot read optimized blocks by absolute offset; that path requires non-optimized blocks plus PUT/GET permission.

Why does my S7-300 read fine while the S7-1200 fails on the same PC station?

S7-300 always publishes offsets and never uses optimized access. The S7-1200 only publishes offsets when optimized block access is disabled per DB and PUT/GET is enabled. The mixed fleet fault is almost always a per-block attribute and a per-CPU protection flag, not a transport issue.

Does the "Set automatically" checkbox in Set PG/PC Interface cause tag read failures?

Yes. With auto-routing enabled, the access point binds to whichever interface returns the first discovery reply. In mixed PROFINET/MPI topologies this produces inconsistent binding and intermittent E-FAIL on one controller family. Disable auto-routing and bind S7Online to the intended TCP/IP adapter.

Back to blog