Troubleshooting TIA Portal V18 FB Tag Monitoring Mismatch on Static Tags

Function Block (FB) online monitoring in TIA Portal V18 can display values that disagree with the contents of the associated Instance Data Block (IDB) on S7-1500 CPUs. The discrepancy is most often observed in FBs that contain large structured data declared as Retentive in the static interface, but the symptom can also affect TEMP variables that depend on those static tags. This reference documents the symptom, the most probable root cause, the diagnostic path, the workarounds that have proven effective in the field, and the preventive design measures that eliminate the issue at the source.

1. Problem Statement

An FB that is called exactly once in the user program shows inconsistent values when the engineer monitors the code online:

• The monitored value of a static tag inside the FB does not match the value of the same tag shown when the IDB is opened and monitored separately.
• The mismatch appears in LAD (KOP) segments, in SCL networks, and across both notations in the same FB.
• Tag values that are not written anywhere in the program (no assignment in the FB, no assignment in the calling block, no HMI write) still display different values between the FB monitoring view and the IDB view.
• Comparing the value of a static variable used as the input of a comparator with the value of the same variable read directly from the IDB produces contradictory results, although the actual process behavior of the CPU is correct.
• Removing or shrinking the large structured area in the static interface makes the symptom disappear.

The symptom is purely a monitoring / display artifact of TIA Portal; the program executes correctly on the CPU. However, the artifact prevents online debugging, and any engineer who has hit it knows the cost: hours of "phantom" bugs that do not exist in the logic itself.

2. Affected Environment

3. Symptoms — Engineer Field Notes

The artifact is identified by the following signs, in order of how reliably they reveal the issue:

1. Static-vs-IDB divergence. Open the FB, place a monitor on a static tag, then open the corresponding IDB in a separate view. The two values disagree even though no other code touches the tag.
2. Segment evaluates incorrectly. A comparator (e.g. "Tag" = 0) evaluates to TRUE in the segment monitoring, while the same tag read from the IDB shows a non-zero value.
3. TEMP variables that derive from static ones are also wrong. A TEMP that copies a static tag at the start of the network displays a different value than the static tag does in the next network. This is misleading: the temp is correctly loaded; the static display is wrong.
4. Reducing the static area fixes the symptom. Trimming array lengths, deleting unused members, or splitting the large struct into smaller structs makes monitoring consistent again.
5. Changing retentivity of the large struct to Non-retentive or Set in IDB fixes the symptom. The two retention settings are not the actual fix — they merely change the size and layout of the static area enough to push the artifact below its threshold.

4. Root Cause Analysis

The behavior is a TIA Portal online monitoring display artifact that occurs when the sum of structured static data in an FB with optimized block access exceeds an internal display buffer threshold. Siemens has not published an exact threshold; in the field the artifact has been reproduced starting at roughly 2 KB of structured static (the exact value depends on data-type alignment, fragmentation, and the language used in the segment), and the threshold can drop further if the FB also uses a lot of SCL with complex expressions.

Three contributing factors appear consistently in reproductions:

4.1 Optimized block access

With Optimized block access enabled (default for new FBs in TIA Portal V18), the compiler is free to place static tags at non-contiguous offsets in the IDB and to store additional symbolic information for each tag. The online monitor must reconstruct the mapping between the displayed symbol path and the physical IDB offset. When the static area is large and fragmented, this mapping is occasionally served from a stale or partial snapshot in the online view, producing values that disagree with the live IDB read.

4.2 Retentivity layout

Declaring a struct as Retentive reserves a separate retentivity slice in the IDB and adds bookkeeping per element. The bookkeeping grows with the number of leaf elements (BOOLs, INTs, REALs, etc.), not with the number of containers. A single STRUCT with 200 BOOL members, 50 INT members and 20 REAL members, all Retentive, occupies significantly more display-mapping entries than the same struct declared Non-retentive. Switching retentivity off or moving the initialization to Set in IDB reduces the bookkeeping enough to fall back under the threshold and the monitoring becomes consistent again.

4.3 SCL call-by-value vs call-by-reference on IN/OUT

When the FB uses IN_OUT parameters of structured type, SCL may copy the parameter to a temporary at function entry (call-by-value) or pass a pointer (call-by-reference), depending on the optimizer's analysis. A mixed style within the same FB — for example, accessing the IN_OUT through the symbolic parameter name in one network and through an absolute %DB slice in another — causes the optimizer to fall back to the more conservative strategy for the whole FB, increasing TEMP usage and aggravating the display-buffer pressure. The visible effect in monitoring is that the same input value shows two different representations in two networks of the same FB.

5. Diagnostic Procedure

Follow the steps in order. The first four steps confirm the artifact; the remaining steps identify which of the three contributing factors dominates in your project.

1. Confirm single instantiation. In the project tree, right-click the FB and choose "Call structure". The FB must be called once. If the call structure shows multiple call points, the symptom has a different cause (overlapping writes from the calling block).
2. Open the FB and the IDB side by side. Drag the IDB into the same editor frame as the FB. Compare the value of a static tag that is not written anywhere in the project. If the values disagree, the artifact is present.
3. Force a CPU value refresh. Press F5 several times. If the two views alternate between agreement and disagreement, the display is being served from different caches — confirming the TIA Portal display artifact.
4. Disconnect the HMI and repeat step 3. If the artifact disappears, the HMI was masking the issue; if it persists, the artifact is independent of the HMI and you can proceed to step 5.
5. Quantify the static area. In the FB interface, add up the byte size of the static section. If the structured static data exceeds ~2 KB and the issue disappears when the size is reduced, factor 4.1/4.2 dominates.
6. Test the retentivity change. Switch the large struct from Retentive to Set in IDB (download the program in RUN with modified retentivity only if the CPU supports it, otherwise use STOP download). If monitoring becomes consistent, factor 4.2 is the dominant cause and you can keep the new retentivity or apply the preventive measures in section 8.
7. Inspect SCL call style. Search the FB for any access to an IN_OUT struct through an absolute address ("MyDb".MyStruct.Field or P#DB…). If such access exists, factor 4.3 is contributing. Rewrite the access to go through the symbolic IN_OUT parameter and recompile.
8. Test on a different TIA Portal version. Open the same project in TIA Portal V18 Update 4 or V19 (if available) to determine whether the artifact is fixed in a later update.

6. Workarounds

Apply one or more of the following workarounds in order of preference. Each one has been confirmed in the field.

6.1 Reduce the static area to below the threshold

Split the large struct into multiple smaller structs, each below the ~2 KB display threshold, and group them under a parent struct. The display mapping of each child is small enough to remain consistent.

6.2 Change the retentivity of the large struct

Set the large struct to Set in IDB (default option) or Non-retentive. The new setting reduces the display-mapping overhead. Verify that the new retentivity is acceptable for the process — losing a recipe on a warm restart may be acceptable for a building-automation sequence but not for a press line.

6.3 Use marker words as debugging mirrors

Add a short SCL network at the end of the FB that copies the suspect static tags into a global data block (or directly into the IDB at a known offset) and monitor the mirror block instead. The mirror block is small and not affected by the artifact.

6.4 Switch the FB to standard access (only if forced)

Disable Optimized block access on the FB. The artifact disappears because the display mapping is no longer required. Trade-off: you lose the symbolic-only access from other blocks, the block becomes accessible by absolute address, and you must update all call sites that relied on the optimized symbolic access. Use this only as a last resort and document the change in the project quality log.

6.5 Move debug-only tags to a separate FB

Encapsulate the large struct in a dedicated "data" FB that is instantiated separately, and reference it from the original FB through an IN_OUT of the dedicated data type. The original FB's static area shrinks and the monitoring issue disappears; the data FB is small enough that its own monitoring stays consistent.

6.6 Use the watch table as the primary debugging tool

Open a watch table, drag the IDB tags into it, and trigger the watch table manually. The watch-table view is fed by a different code path than the segment monitor and is not affected by the artifact. This workaround is the fastest to apply and is useful as a parallel verification while the structural workarounds are implemented.

7. Verification

After applying a workaround, verify the fix with the following checks. Each check is independent and may be performed in any order.

1. Side-by-side monitor. Repeat the test from step 2 of the diagnostic procedure. The values shown in the FB segment monitor and in the IDB must agree to the last bit for at least 60 seconds of continuous monitoring (press F5 repeatedly).
2. TEMP consistency. Place a TEMP variable that copies a static at the start of a network, and read the same static at the end of the next network. Both must agree.
3. Process I/O cross-check. Force a known value into the static tag from a watch table, then trigger the FB and confirm that the output changes as expected. The process I/O is the ground truth.
4. Stress test. Force the OB1 cycle time to its maximum (e.g. by adding a cyclic OB with a long runtime temporarily) and confirm that the monitoring still agrees. Some artifacts appear only under load.
5. Compile-clean re-build. Perform a full project re-compile (right-click the project, Compile > Software (rebuild all)). The artifact can be triggered by a stale incremental compile that mixes old and new display-mapping tables.
6. Multi-station reproduction. If the project has more than one CPU, replicate the test on a second station. Some artifacts are CPU-serial-number-specific because of internal memory layout.

8. Preventive Design Recommendations

The following design rules keep the artifact from reappearing in future development:

• Keep each FB's static area below ~2 KB of structured data. Split large data sets into dedicated FBs.
• Declare retention at the leaf level, not the struct level. If only a few members of a struct must survive a warm restart, declare those members as Retentive and leave the rest as Non-retentive or Set in IDB. This minimizes the display-mapping overhead.
• Use symbolic IN_OUT access exclusively. Avoid mixing symbolic and absolute access to the same IN_OUT in a single FB. The mixed style forces the SCL optimizer to the conservative strategy and inflates TEMP usage.
• Centralize HMI-facing data in dedicated DBs. The HMI should read from a global data block, not from FB instance tags. This decouples the HMI write rate from the FB monitor display path.
• Version-pin the TIA Portal update. Once a project is commissioned, freeze the TIA Portal Update level. Different engineers working on V18.0.0.0, V18.0.1.0 and V18.0.3.0 may produce subtly different display-mapping tables.
• Document the artifact in the project quality plan. A short note in the project's quality log ("TIA Portal V18 FB monitoring artifact mitigated by retaining only critical data") saves hours of investigation the next time a new engineer joins.

9. When to Open a Siemens Support Request

Open a Siemens support request (SIOS — Siemens Industry Online Support) if any of the following apply:

• The artifact persists after applying all six workarounds in section 6.
• The artifact appears in FBs with a static area well below 2 KB.
• The CPU returns a diagnostic buffer entry that correlates with the artifact (e.g. "Monitoring data inconsistent" or a stop code in the OB 1 diagnostics).
• Switching to TIA Portal V18 Update 4 or V19 does not resolve the issue.

When opening the request, include:

1. The exact TIA Portal version (open Help > About and copy the full version string).
2. The exact CPU order number and firmware version (from the CPU's online diagnostics, Online & diagnostics > Diagnostic buffer > Module information).
3. A minimal reproduction project. Reduce the project to the single FB, its IDB and the calling OB, with the suspect data set preserved. Mark the FB with a comment describing the symptom.
4. The diagnostic-buffer dump of the CPU at the time the symptom is observed.
5. The list of workarounds already tried and their result.

A standard support request has a 24-hour first-response SLA for registered Siemens Solution Partners and a longer SLA for end users. Severity rating "S2 — Major operational impact" is appropriate when the artifact blocks online commissioning of a new station.

10. Related Siemens Documentation

The following Siemens references are useful while working through this issue. Always confirm against the latest revision on SIOS before applying any change to a running system.

• SIMATIC S7-1500, ET 200MP Automation System System Manual — chapter on block access (optimized vs standard) and on retentive behavior.
• Programming and Operating Manual for S7-1500 / S7-1500F — chapter on FB, FC and DB attributes, including retentivity.
• S7-1500 CPU 1516F-3 PN/DP (6ES7 516-3FP03-0AB0) Device Manual — CPU-specific characteristics and firmware notes.
• STEP 7 / TIA Portal V18 — Function Manual — block creation, monitor / modify, watch tables and the online view architecture.
• S7-1500 SCL Programming Manual — call-by-value vs call-by-reference for IN/OUT, optimizer settings.

11. Summary

The TIA Portal V18 FB monitoring mismatch is a display artifact, not a program or CPU fault. It is most reliably reproduced in FBs with optimized block access and a large structured static area marked as Retentive. The fastest path to a working monitor is to reduce the static area below the display-buffer threshold, to switch the large struct to Set in IDB or Non-retentive, or to monitor the IDB through a watch table instead of through the segment view. The preventive measures in section 8 keep the artifact from recurring in future development. If none of the workarounds resolve the issue, open a Siemens support request with a minimal reproduction project — this is the most efficient way to obtain a permanent fix from the vendor.

12. FAQ