Resolving KTP Comfort HMI Tag Misalignment in TIA V13.1 SP1 HF8

Resolving KTP Comfort HMI Tag Misalignment in TIA V13.1 SP1 HF8 with SIMOTION

This reference documents a field-confirmed behavior where KTP Comfort 900 panels driven by a SIMOTION controller and engineered with TIA Portal V13.1 SP1 + Hotfix 8 show scrambled tag values (###### or static 0) after the SIMOTION project is changed (HW Config, GSD, global DB, program code, or HMI variable list) and downloaded without a corresponding rebuild-all on the HMI side. HF8 mitigated many of the historical misalignments, but did not fully eliminate the failure mode when incremental compile/download is used. The procedures below isolate the root cause, prove it with on-target diagnostics, and apply the controlled workaround that has proven reliable on production lines.

1. Problem Definition

After editing the SIMOTION project (adding a PROFINET slave and its GSD, expanding the periphery, modifying global variables, and re-linking HMI tags), the operator panel exhibits one or more of the following symptoms:

• HMI fields display ###### (value out of range, or no value at all)
• Numeric fields show a static 0 where a non-zero process value is expected
• Some tags on the same screen are correct, others are wrong — a partial misalignment
• Re-compiling and re-downloading only the SIMOTION target does not fix the panel
• Re-downloading the HMI without a Rebuild all does not fix the panel
• Re-downloading the HMI with a Rebuild all immediately restores correct values

The pattern is reproducible and correlates strictly with the introduction or renaming of HMI-visible variables on the SIMOTION side. The defect is not a hardware fault, a PROFINET cable problem, or an HMI firmware mismatch — it is an engineering toolchain defect in the offline/online mapping of symbolic tags to absolute HMI address memory locations.

2. Affected Versions and Components

HF8 — distributed through the Siemens Industry Online Support portal — was the first hotfix to address the original TIA V13 / V13.1 realignment bugs by triggering a controlled HMI update after every Save & Compile in SCOUT. The remaining failure mode is triggered when a user performs a partial / incremental compile on either side of the coupling.

3. Root Cause: HMI Maps to Memory, Not to Symbols

The fundamental architectural fact that drives this class of bug is:

SIMOTION exposes its HMI variables as absolute memory addresses, not as symbolic names. The HMI connection editor builds a static memory map at compile time. When the SIMOTION project changes the layout of its global device variables, the HMI's pre-compiled memory map becomes stale — it points to offsets that no longer correspond to the new symbols.

The HMI does not dynamically rebind symbolic names to addresses at runtime over PROFINET or PROFIBUS. The mapping table is baked into the HMI image at compile time. This is by design for deterministic runtime behavior on the panel side, but it makes any structural change on the controller side require a corresponding HMI recompile.

What HF8 changed: it added an automatic re-trigger of the HMI's symbol resolution pass whenever SCOUT's Save & Compile detected a change in the HMI-visible variable surface. This is why most users observed that the manual Rebuild all ritual — mandatory in pre-HF8 — became optional in HF8.

What HF8 did not change: when the user explicitly avoids a full recompile on the HMI side (for example, by using incremental download, by manually skipping dependent objects, or by editing the HMI tags in a way the dependency walker does not flag), the HMI keeps the old memory map. The result is the partial-alignment pattern observed in the field: variables that did not change offsets still work; variables whose offsets shifted now point to the wrong location or to a location the runtime reports as invalid (####).

3.1 Why only some tags fail

Tags are packed into the HMI's address image in the order the connection is generated, typically sorted alphabetically by symbol name within each DB / global-variable area. When the user inserts new variables, all subsequent variables shift by the size of the new entry. This is why:

• Tags before the insertion point continue to work.
• Tags after the insertion point read 0, ######, or stale data.
• The pattern looks random to the operator but is mathematically deterministic from the symbol table.

4. Step-by-Step Reproduction

The following sequence reproduces the failure on a representative project. Use it to confirm the diagnosis on a bench unit before applying the workaround in production.

1. Open a project containing a SIMOTION controller and a KTP1200 Comfort (the same path applies to KTP900, KTP1500, TP1500, TP1900 Comfort).
2. Confirm baseline: compile and download SIMOTION, compile and download the HMI with Rebuild all. Verify all tags populate correctly.
3. In the device configuration, add a new PROFINET IO device (for example, a SINAMICS V90 or ET200SP head module) by importing its GSD file.
4. Map the new device's slots to SIMOTION I/O addresses and to global device variables.
5. Add new global variables in the SIMOTION program (for example, g_axAuxPos, g_iAuxState) and link them to existing or new HMI tags.
6. Modify the MCC / ST / LAD / FBD code as needed to use the new variables.
7. Do not modify the HMI tag list yet. The HMI connection points to the old variable surface.
8. Perform Save & Compile all in SCOUT. The HMI connection surface should update.
9. Download to the SIMOTION target only. Do not download the HMI.
10. Observe the panel: most tags still display correctly, but the new tags, and any tag whose memory offset shifted due to the new variable layout, now show ###### or 0.
11. Download to the HMI only, with default (incremental) compile. The result does not improve.
12. On the HMI, run Compile > Software (rebuild all) and download. The panel now shows the correct values.

5. Diagnostic Procedure

Before assuming the HMI/SIMOTION mapping is at fault, rule out the more common root causes. The matrix below is the field-tested triage path.

5.1 Confirming the HMI Memory Map is Stale

The fastest confirmation is to compare the address of a failing tag in two places:

1. HMI side: HMI tag editor > select the tag > Properties > Connection. Note the PLC tag name and the implied address.
2. Controller side: SCOUT > Symbol browser or Watch table. Search for the same symbol. Note the absolute address (DB number, byte offset, bit offset).

If the two addresses disagree, the HMI image is stale. A rebuild-all is required.

5.2 Reading the HMI Diagnostic Buffer

On the panel itself, Control Panel > System > System Information > Buffer contains entries such as:

Tag 'HMI_Tag_LineSpeed' : Address error, area DB1000, offset 12.4
Tag 'HMI_Tag_AuxPos'   : Value out of valid range

These entries are evidence — not a fault in the panel firmware — that the requested offset is not backed by a valid value in the controller at the time of the read, which is consistent with a mapping drift between HMI and SIMOTION.

6. HF8 Improvement vs. Residual Gap

HF8 introduced a dependency check on Save & Compile in SCOUT. When the SIMOTION HMI-visible variable surface changes, the HMI project is marked dirty and the next HMI compile/download regenerates the address mapping. For users who follow the canonical workflow — edit, save, compile SIMOTION, compile HMI, download both — HF8 is sufficient and the manual Rebuild all command becomes redundant.

The residual gap appears in three real-world scenarios:

1. The user performs an incremental (non-rebuild) compile on the HMI for speed, e.g., during commissioning when only one screen changed.
2. The user edits the HMI tag list to add or rename a tag without re-opening SCOUT, so the dependency walker in SCOUT never sees the change.
3. The user imports a GSD and a partial project migration is performed by the tool, leaving the HMI's view of the SIMOTION symbol surface partially synchronized.

In all three cases the symptom is identical to the pre-HF8 era: ######, 0, and a partial panel that is correct on the fields the operator does not look at and wrong on the fields they do.

7. Solution: Controlled Rebuild Procedure

The controlled, repeatable fix is the Rebuild all + full HMI download. The procedure below is the production-grade version that has been used on multi-cell lines without post-fix drift.

1. In TIA Portal, expand the HMI device in the project tree.
2. Right-click the HMI device > Compile > Software (rebuild all).
3. Wait for the build to complete. Verify there are no warnings about unresolved tags.
4. Right-click the HMI device > Download to device > Software (all).
5. When the download dialog appears, accept the prompt to overwrite the existing runtime image.
6. Wait for the panel to restart. The panel will show the loader / startup screen, then the configured start screen.
7. Verify the previously failing tags now display real values.
8. Place a watch on the HMI Connections status to confirm the connection is established before returning the line to production.

8. Preventive Best Practices

For projects under active development, the following practices eliminate the trigger conditions for this class of bug.

8.1 Reserve variable slots

Define a fixed-size block of spare HMI variables at the end of the HMI tag list — for example, 16 tags named Spare_HMI_01 through Spare_HMI_16, of types Bool, Int, Real, Word, DWord, String — and link them to a dedicated DB block in SIMOTION. When the project needs a new HMI variable, repurpose one of the spares in place. The memory map does not change; only the symbolic name changes. The HMI does not need to be reloaded.

This is the same technique used in field-proven S7-300/S7-400 deployments and is the cleanest long-term mitigation when an HMI and a motion controller are tightly coupled.

8.2 Avoid tag renaming

If a tag must be renamed, treat the rename as a delete-then-add operation in the HMI tag list. Do not rely on the HMI to automatically rebind. After rename, run the controlled rebuild procedure in section 7.

8.3 Single source of truth for the symbol surface

Maintain the SIMOTION symbol surface as the master. Never add an HMI-side tag that points to a controller symbol that does not yet exist in SCOUT. If the HMI needs to be edited in isolation (for example, a screen layout change that does not yet have the controller code ready), use a local PLC tag stub and re-link when the controller symbol becomes available.

8.4 Use HMIs with HMI-side symbolic binding where possible

For non-SIMOTION controllers (S7-1500, ET200SP CPU), TIA Portal supports fully symbolic HMI tag binding that re-resolves at compile time on every project save. This is a fundamentally different (and more robust) mechanism than the SIMOTION HMI address-mapping mechanism. The behavior described in this document is specific to the SIMOTION coupling.

8.5 Keep TIA Portal patched

Newer TIA Portal versions (V15, V15.1, V16, V17, V18) have progressively improved the SCOUT / HMI dependency tracking. Where the project allows, upgrade to a current TIA Portal version to take advantage of the strengthened coupling. Confirm the SCOUT version bundled with the newer TIA Portal is also updated.

9. SIMOTION-Specific Architectural Notes

SIMOTION's exposure of HMI variables is controlled by the Symbol interface configuration. Each unit, program, or technology object that needs to be visible to the HMI must have its variables added to the symbol interface. The symbol interface is the contract between the runtime and any external observer (HMI, OPC server, trace, web server). The HMI does not see any variable that is not in the symbol interface.

The memory map that the HMI builds is the flattened symbol interface, sorted alphabetically by symbol name. This is the source of the "offset shift" pattern described in section 3.1.

10. Verification After Repair

Use this checklist to confirm the panel is in a known-good state before returning equipment to production.

1. Open every screen that was affected. Verify all numeric fields show real, time-varying values consistent with the process.
2. For each previously failing tag, place a cross-check in SCOUT's watch table and compare the value to the HMI display. They must match to the last digit.
3. Cycle power on the HMI. Verify the tag values repopulate correctly after the restart, not just immediately after download. (This rules out a transient correct state that depends on a stale cache.)
4. Force a value change in SCOUT for at least one previously failing tag. Verify the HMI tracks the change within one PROFINET update cycle.
5. Read the HMI diagnostic buffer. Confirm there are no new "Address error" or "Value out of valid range" entries related to the previously failing tags.
6. Sign off the maintenance ticket with the project hash from TIA's project properties (timestamp + last change author) for traceability.

11. Troubleshooting Matrix

12. Field-Proven Mitigation: A Structured Spare-Variable Pattern

The most resilient long-term mitigation, validated on multi-cell production lines with SIMOTION D4x5-2 and KTP1200 Comfort panels, is a structured spare-variable pattern. Define a fixed-size block in a dedicated SIMOTION DB:

// SIMOTION ST — Spare HMI variable block
// Defined once, never resized. Tags may be repurposed by changing the HMI-side name only.
VAR_GLOBAL
    g_HmiSpareBool00   : BOOL;    g_HmiSpareBool01   : BOOL;
    g_HmiSpareBool02   : BOOL;    g_HmiSpareBool03   : BOOL;
    g_HmiSpareInt00    : DINT;    g_HmiSpareInt01    : DINT;
    g_HmiSpareInt02    : DINT;    g_HmiSpareInt03    : DINT;
    g_HmiSpareReal00   : LREAL;   g_HmiSpareReal01   : LREAL;
    g_HmiSpareReal02   : LREAL;   g_HmiSpareReal03   : LREAL;
    g_HmiSpareWord00   : WORD;    g_HmiSpareWord01   : WORD;
    g_HmiSpareDWord00  : DWORD;   g_HmiSpareDWord01  : DWORD;
    g_HmiSpareString00 : STRING[32];
END_VAR

On the HMI side, create HMI tags of matching data type, all connected to the corresponding SIMOTION tag. When a new HMI value is needed, change the HMI tag's display name (or repurpose the underlying PLC tag) without modifying the SIMOTION-side global-variable layout. The memory map never changes, the offsets never shift, and no HMI rebuild is required for routine operator-screen changes.

This pattern is the same one recommended in the Siemens SIMOTION programming and runtime configuration manual for projects with evolving HMI requirements.

13. Procedure Summary (Single Page)

For technicians who need the minimum-viable procedure:

1. Confirm the symptom matches this article (mixed correct / ###### / 0, after a SIMOTION edit).
2. Cross-check one failing tag's address in the HMI connection vs. the SIMOTION symbol table.
3. If they disagree: rebuild HMI software (rebuild all), download to device (all).
4. Verify on the panel: every previously failing tag now shows a real value.
5. Cycle power on the panel; verify the values repopulate after restart.
6. For the next iteration, either adopt the spare-variable pattern, or always rebuild-all after any SIMOTION edit that touches the symbol surface.

14. Related Behavior and TIA Portal History

The SIMOTION HMI memory-map problem has been a known pain point since the integration of SCOUT into TIA Portal. HF8 was the most significant corrective step at the V13.1 SP1 line. Subsequent TIA Portal versions (V14, V14 SP1, V15, V15.1, V16, V17, V18) have continued to improve the dependency tracking and the handling of HMI tag changes, with progressively fewer conditions under which a stale HMI image can be produced.

Users running pre-HF8 V13.1 SP1, V13.1, V13, or V12 SP1 should consider upgrading to at least HF8 (and ideally to a current TIA Portal version) before applying the procedures in this article, because the dependency walker in pre-HF8 versions is less robust and the manual rebuild-all is mandatory on every edit.

For non-SIMOTION controllers (S7-1200, S7-1500, ET200SP CPU), the HMI tag binding is fully symbolic and the behavior described in this article does not apply.

15. FAQ