Siemens KTP 700 IO Field Reverting: Optimized Block Access Fix

1. Problem Summary

A Siemens KTP 700 Basic/Comfort panel connected over PROFINET to a S7-1200 CPU 1214FC (firmware V4.2) loses operator input almost immediately after the operator presses Enter on an IO field. The displayed value snaps back to the original value, so the operator believes the write was rejected. The same effect has been observed with Set Bit button events that write to PLC tags stored in the same data block. The plant programmer reported the symptom in TIA Portal V14 SP1 and confirmed that the target DB is read-only in the application code.

2. Affected System Architecture

The HMI polls the tag via PROFINET acyclic reads on a configured acquisition cycle. When the operator presses Enter on the IO field, the panel issues an acyclic write to the PLC tag. If a PLC user FB overwrites the same memory location on the very next PLC cycle, the panel re-reads the original value and displays it - giving the appearance of a "reverted" input.

3. Root Cause: Optimized Block Access on the Writing FB

Siemens S7-1200/S7-1500 data blocks and FBs can be marked with "Optimized block access" (formerly "Symbolic addressing only"). With optimized access, the compiler reorders tag addresses for efficient symbolic access and pads the structure. Symbolic-only variables have no fixed, absolute address, so the runtime places them dynamically in the work memory.

Two consequences interact to produce the symptom:

1. The HMI must reach the tag through the symbolic name rather than a stable DB offset. If the HMI connection is configured to access "absolute" DB offsets (older panels, hand-entered DB numbers, or DBs marked non-optimized mixed with optimized FBs), the address the HMI sees does not always match the address the FB actually wrote. The HMI then writes to a location the FB is not using, and the next read pulls back the FB-written value.
2. When an optimized FB holds a temporary value that it copies back to a non-optimized DB, the cycle order between FB execution and HMI acyclic write determines which value wins. If the FB runs after the HMI write, it overwrites the operator's input. The operator sees the original value again.

The reporter confirmed exactly this: a single FB was writing the tag, the FB was marked "Optimized block access", and the surrounding code in the FB had no active path - yet the cyclic OB1 invocation was still touching the symbol. Removing the optimized access flag on the FB made the IO field stable.

4. Why a "Dead" Code Path Still Writes

An SCL FB with optimized access contains in-out parameters, static variables, and the implicit transfer of the FB instance DB. Even when the visible IF condition is false, the FB still:

• Copies in-out parameters into the instance DB at the start of the call.
• Executes the assignment statements at the end of the call (in particular the last assignment to the in-out tag).
• Copies the in-out parameter back to the referenced tag at FB exit.

Because the in-out parameter is passed by reference, the compiler inserts implicit read/write code at the FB boundary. With optimized access, the referenced memory is a snapshot that gets re-written each cycle. The "dead" branch is therefore not truly dead - the parameter copy-back at FB end always executes.

5. Diagnostic Procedure

Follow the steps in order. Each step isolates one contributing factor before moving to the next.

1. Confirm the symptom on the panel. Press Enter on the IO field, watch the value for 2-3 seconds. If it reverts, capture the tag name and DB number from the HMI tag list.
2. Open the DB in TIA Portal and inspect the property "Optimized block access". If the DB is optimized and the HMI uses an absolute DB number, this is a strong suspect.
3. Cross-reference the tag. Right-click the tag, choose "Go to > Cross-references". Identify every block that reads or writes this tag.
4. Inspect each writing block's "Optimized block access" flag. In the FB properties under "Attributes", look for "Optimized block access". Note each block's state.
5. Check OB1 / cyclic OB call order. Place a breakpoint or use the watch table to confirm the FB executes in every cycle, not only when a condition is true.
6. Verify IO field limits. Open the IO field configuration and confirm the high/low limits are not clipping the entered value to the old one.
7. Test the Set Bit variant. If Set Bit on a button is also losing state, the same FB is almost certainly the cause - the Set Bit writes a tag the FB then overwrites.
8. Compare online vs offline. Use "Monitor / Modify" with a watch table to overwrite the tag manually. If the manual write sticks, the issue is the HMI write path or the FB overwriting, not the HMI display.

6. Resolution Steps

1. In the project tree, right-click the writing FB and select Properties.
2. Open the Attributes section.
3. Uncheck "Optimized block access" (or, in older TIA Portal releases, uncheck "Symbolic access only").
4. Recompile the project: right-click the PLC > Compile > Software (rebuild all blocks).
5. Download the rebuilt blocks to the CPU. Ensure you stop the CPU first if the FB is involved in safety logic (F-CPU).
6. Reconnect the panel and test the IO field. The value should now persist across cycles.

7. Alternative Resolution Paths

If you cannot remove optimized access (for example, because the FB is shared with code that depends on symbolic-only access), use one of these workarounds:

8. Verification Checklist

1. Operator enters a new value in the IO field and presses Enter. Value must remain for at least 10 seconds.
2. Open the watch table in TIA Portal online. The DB tag must match the HMI value.
3. Force the FB to execute 50 times in a row by toggling its enable input. The HMI value must remain stable.
4. Power-cycle the HMI. After reconnection, the IO field must display the last entered value, not the original.
5. Test the Set Bit buttons. The bit must stay set until the FB explicitly clears it, not until the next cycle.
6. Check the diagnostic buffer of the CPU for any PROFINET I/O faults during the test. None should appear.

9. Why IO Field Limits Were the First Suspect

The original poster was first asked to verify the IO field high/low limits because out-of-range entries are silently clamped to the limit. On a KTP 700, the limits are configured in the IO field properties under "Limits". If the new value exceeds the configured high limit, the panel writes the limit value - not the entered value - and the operator sees what looks like a reversion. Before changing block attributes, always confirm the limits match the operator's intent:

• High limit >= maximum intended value.
• Low limit <= minimum intended value.
• Decimal places match the data type of the PLC tag (REAL vs INT).
• If the tag is REAL on the PLC, ensure the IO field output format includes the right number of decimals, otherwise rounding can make the panel display a value one step off the PLC value.

Reference: WinCC Unified documentation describes the IO field display behaviour at IO field (RT Unified). The Unified panel variant shows similar behaviour when the bound tag is overwritten by PLC logic after the operator's input.

10. Optimized vs Standard Access in TIA Portal

For S7-1200 CPUs and Comfort/Basic panels, the safest contract is: DBs that bind to HMI tags are non-optimized; FBs that only compute internal values are optimized. This keeps the HMI/PLC contract stable while still letting compute FBs benefit from the optimized layout.

11. Interaction with PROFINET Update Time

The PROFINET update time is independent of this fault, but it can amplify or mask it. With a 1 ms update time and a 2 ms OB1 cycle, the FB can overwrite the operator's write on the very next PROFINET cycle. With a 16 ms update time, the panel might fetch the operator's value before the FB overwrites - and the fault appears intermittent. Reducing the update time does not fix the fault; it makes it consistent. The only real fix is the access-flag change or one of the alternative paths above.

12. Related Symptoms on the Same Root Cause

• Set Bit on a button: The bit flickers and clears itself. Same mechanism - the FB rewrites the tag.
• Recipe values appear "stuck" at old defaults: The HMI writes the recipe, the FB then re-applies the previous default.
• Trend view shows flat line despite operator changes: The trend polls the tag, but the FB rewrites faster than the trend sample rate.
• Tag retentivity lost on restart: The FB default at first run clobbers the retentive value because the optimized instance DB is reset on download.

If more than one of these symptoms is present on the same DB, the optimized FB access flag is the prime suspect.

13. Best-Practice Configuration Checklist

1. Tag all DBs that are HMI-facing as non-optimized.
2. Tag all compute FBs that do not bind to HMI as optimized.
3. Document the access model in the project notes so future edits do not flip the flag silently.
4. Use the same naming convention for HMI-bound tags (e.g. prefix HMI_) to make cross-references easier.
5. Avoid mixing optimized FBs and non-optimized DBs in the same call stack when the FB uses in-out parameters targeting the DB.
6. For S7-1200 firmware V4.x, always confirm the firmware/HMI tag compatibility using the TIA Portal compatibility matrix before commissioning.

14. Firmware and TIA Portal Compatibility Notes

The reporter used TIA Portal V14 SP1 with CPU 1214FC firmware V4.2. At this version:

• Optimized block access for FBs is fully supported and is the default for new FB creation in TIA Portal V14 onward.
• CPU 1214FC firmware V4.2 supports both symbolic and absolute HMI access, but absolute access is recommended when the panel is on the older WinCC Comfort / Basic runtime.
• Later TIA Portal versions (V15, V16, V17, V18, V19, V20) extend symbolic-only support and improve the diagnostics when access types are mixed, but the underlying mechanism is unchanged.

For new projects, prefer TIA Portal V18 or V19 with the corresponding CPU firmware to take advantage of the improved symbolic access diagnostics. For existing V14 SP1 projects, the fix above applies unchanged.

15. When the Fix Does Not Help

If removing optimized access on the FB does not resolve the symptom, escalate the diagnosis as follows:

1. Confirm the FB really is the only writer. Use "Cross-references" to enumerate every writer of the tag.
2. Check HMI tags for "Acquire continuously" mode. Set the IO field to "Acquire on demand" if a continuous poll is conflicting with the write.
3. Inspect the CPU's diagnostic buffer for PROFINET I/O faults or HMI connection drops. A dropped connection during a write can leave the PLC value unchanged.
4. Verify the HMI connection's "Access point" and "Connection resource" - a wrong S7 connection index can route the write to a different DB.
5. Look for an HMI tag pointer access in a screen script that overwrites the tag after each input event.
6. Check whether the DB is being used as an "actual" parameter of a multi-instance FB. Multi-instance FBs can mask their writers in cross-references.

16. Safety Program Considerations (CPU 1214FC)

The "FC" suffix indicates a fail-safe CPU. The fault described here is in the standard user program. The safety program has its own F-DBs and F-FBs and is not involved. However:

• Never edit safety blocks live. Stop the CPU and follow the F-change procedure before downloading.
• Do not move HMI tags into F-DBs. F-DBs are not accessible from HMI panels by design.
• If the operator's input drives a safety-relevant state, route it through a standard DB tag, then copy it into the F-DB under a separate, audited code path.

17. Quick Reference Matrix

18. FAQ