Resolving SIMOTION D435-2 WinCC Flexible Alarm 140020 Communication Loss

Alarm 140020 on a SIMOTION D435-2 paired with WinCC Flexible 2008 SP3 Runtime is one of the most common version-mismatch symptoms reported in motion-and-HMI installations. The runtime starts, the Ethernet link between the PC-based HMI and the SIMOTION controller is physically intact, but every tag value is replaced with ##### in the HMI screens, and the alarm view reports a fatal error stating that the data of the CPU and the data of the HMI are no longer in the same version. The fault survives every partial repair attempt (incremental compile, full rebuild, reload of either side alone), and recovery is often only possible with a complete, isolated reinstallation of the engineering environment. This article reconstructs the full failure path, the diagnostic procedure that should be executed before any reinstall is considered, and the clean-environment recovery method that has been observed to resolve the issue when the engineering workstation is in an inconsistent state.

1. Problem Summary

The reported symptom set is consistent across the documented cases:

• SIMOTION D435-2 has been in production for 3–4 years with stable WinCC Flexible RT communication over Industrial Ethernet.
• Engineering changes are made in SIMOTION Scout (program modifications, axis configuration, new tags).
• The user runs Save and Compile modifications (or Save and Compile all) and downloads the new SIMOTION project to the D435-2.
• The WinCC Flexible Runtime is restarted. The HMI starts, the connection to the D435-2 is shown as established in the connection diagnostics, but all tag values are displayed as #####.
• The HMI alarm view displays alarm 140020, text: "Data of the CPU and data of the HMI are not in the same versions" (German: "Daten der CPU und Daten der HMI sind nicht in gleicher Version").
• Any subsequent attempt to make a small change in Scout (for example, adding a single tag), saving, compiling, and reloading, repeats the failure.
• Rolling the project back to a previously working backup (both the Scout and WinCC Flexible images at the same point in time) restores normal operation, proving that the runtime is healthy and only the version-data handshake is broken.

The combination of ##### values, established connection status, and alarm 140020 is the unique fingerprint of a failed HMI consistency check between SIMOTION Scout and WinCC Flexible.

2. Alarm 140020: HMI Version Mismatch Decoded

Alarm 140020 is a WinCC Flexible Runtime alarm, not a SIMOTION firmware alarm. The string is generated by the WinCC Flexible Runtime when the version signature of the SIMOTION project that was compiled into the HMI database does not match the version signature of the SIMOTION project that is currently online on the D435-2.

The check is deliberately strict. WinCC Flexible Runtime refuses to map tag values when the SIMOTION program on the controller has been compiled with a Scout version that the HMI was not regenerated against. This prevents a class of silent failures where a renamed or restructured tag in Scout would otherwise be silently dropped or mis-typed in the HMI.

3. How the HMI Consistency Check Works

The HMI consistency check relies on a version signature file that SIMOTION Scout produces at compile time. The signature contains:

1. The SIMOTION project identifier.
2. The compile timestamp of the SIMOTION program (firmware target, libraries, units, axis configuration).
3. A SHA-style hash of the exported tag list that the HMI is expected to consume.
4. The Scout build number that produced the export.

WinCC Flexible reads this signature at Runtime start from one of three locations, in order of preference:

1. WinCC project integrated in SIMOTION Scout — the signature is stored inside the Scout project tree and consumed directly by the integrated WinCC editor. This is the canonical and most reliable path.
2. WinCC project integrated in STEP 7 (but not in Scout) — the signature is generated by Scout into a side-channel file and consumed by the STEP 7-integrated WinCC Flexible via the SIMATIC Manager's inter-project references. This is the path that fails most often in field reports because the side-channel file is the first thing that breaks when the engineering environment is unhealthy.
3. Stand-alone WinCC project — the signature is imported manually and the engineer is responsible for keeping the imports aligned. This is rare on a SIMOTION D435-2 machine.

3.1 Data-flow diagram (inline SVG)

4. Reference Environment

5. Root Cause Analysis

Field experience with this exact symptom set points to one of three layered root causes, in descending order of frequency.

5.1 Engineering-environment corruption (most common in long-running installations)

A workstation that has been touched by multiple HMI / SCADA products over its life — for example, WinCC Flexible 2008, WinCC (the SCADA product, not Flexible), TIA Portal, WinCC Explorer, ProTool, or older Smart Service tooling — accumulates:

• Conflicting registry entries under HKLM\SOFTWARE\Siemens\Automation and the WOW6432Node mirror.
• Stale COM components and DCOM launch permissions.
• Multiple versions of the S7ONLINE access point, each registered by a different install.
• Shared DLLs in %SystemRoot%\System32 and \SysWOW64 that are rolled back to older versions by an uninstall of a sibling product.

The documented resolution path in this category is to remove the conflicting product (for example, uninstalling WinCC SCADA from a workstation that also runs WinCC Flexible) and then re-install or re-register the remaining engineering chain. When the uninstall itself has damaged a shared DLL, the damage is permanent until the engineering chain is reinstalled from a clean image.

5.2 Stale or locked side-channel signature

If the engineering workstation is healthy but the WinCC project is not integrated in Scout, the version signature travels through a file under the STEP 7 project tree. Symptoms of a stale/locked signature:

• Compile of the SIMOTION program in Scout completes without error and the file timestamp updates.
• WinCC Flexible is opened during the same compile; the integrated tag picker still shows the old tag list.
• Closing and reopening WinCC Flexible has no effect.
• Selecting Options → WinCC Flexible → Delete Temporary Files and then Rebuild All succeeds but the generated image still references the previous signature.

The fix at this level is to close both Scout and WinCC Flexible, end the S7DOS and CCAgent processes from Task Manager, then run a Save As with With reorganization in SIMATIC Manager. If the reorganized STEP 7 project also has the same problem, the issue is environmental (5.1) not project-related.

5.3 Mixed-integrity WinCC project

The least common, but most stubborn, failure is a WinCC Flexible project that was at one point integrated in Scout, was then detached, and is now integrated only in STEP 7. The HmiVersionStoreGlobal cache that Scout populates is left in an ambiguous state. Re-integrating the project in Scout blocks at the HmiVersionStoreGlobal dialog because Scout detects a half-committed state and refuses to overwrite it. The unblock path is to delete the HmiVersionStoreGlobal subtree from the STEP 7 project before re-integrating — but this requires STEP 7 to be re-launched with administrative rights and the project to be in a checked-in state.

6. Diagnostic Decision Tree

Run the checks below in order. Each step is non-destructive to the controller. Stop at the first success row.

7. Non-Destructive Recovery Procedure

Execute these steps on the engineering workstation before touching the controller.

7.1 Prerequisites

• Administrative rights on the engineering PC.
• STEP 7 V5.5 SP4 HF11 source media.
• SIMOTION Scout V4.5 source media.
• WinCC Flexible 2008 SP3 source media (plus Update 7, if available).
• Current project backups of both the Scout project and the STEP 7 / WinCC Flexible project, taken at a known-working state.
• Write access to the STEP 7 project directory and to %TEMP%.

7.2 Procedure

1. Close all engineering tools: SIMATIC Manager, Scout, WinCC Flexible, S7-PLCSIM, and any active Runtime. Confirm no S7DOS.exe, CCAgent.exe, scout.exe, or winccflex.exe remain in Task Manager.
2. Stop the S7DOS service: sc stop S7DOS from an elevated command prompt.
3. Open SIMATIC Manager and open the STEP 7 project that contains the WinCC Flexible project.
4. Right-click the WinCC Flexible station → WinCC Flexible → Delete Temporary Files.
5. Right-click the WinCC Flexible station → Rebuild All. Confirm the build log shows a fresh compile timestamp.
6. Open the SIMOTION project in Scout. Project → Save and Compile All. Wait for the green check.
7. Close Scout.
8. Reopen Scout. Verify the integrated tag list now reflects the new tags (if any were added).
9. Close SIMATIC Manager. Save As the project to a new directory with With reorganization.
10. Reload the SIMOTION project to the D435-2 (Stop CPU → download → Run).
11. Restart the WinCC Flexible Runtime on the PC677.
12. Confirm in the HMI connection diagnostics that the connection is up. Confirm one tag updates live. Confirm alarm 140020 is not active.

8. Clean-Environment Recovery

This is the procedure that has been observed to resolve alarm 140020 when the engineering workstation has accumulated damage from sibling HMI/SCADA products. It is destructive to the workstation's installed software and requires a clean OS image.

8.1 Capture the project artifacts first

Before touching the workstation, copy to external media:

1. The full STEP 7 project directory (the *.s7p file and all sub-directories, including S7Pro, Hmi_Es, and the HmiVersionStoreGlobal cache).
2. The current SIMOTION Scout project (compress to *.zip while Scout is closed).
3. Any device-level *.sdf archives or *.itb backups of the D435-2.
4. All license keys (AuthorW license files, Automation License Manager export).
5. The PC677's runtime project backup (WinCC Flexible → Project → Backup) if separate from the engineering copy.

8.2 Rebuild the workstation

1. Re-image the engineering PC from a known-good OS image. Do not run any product installer before the base image is verified. Do not install WinCC (the SCADA product), ProTool, TIA Portal, or any other HMI/SCADA product on the same image as WinCC Flexible 2008. These products share DLLs and registry hives and are the documented source of the corruption pattern that triggers 140020.
2. Apply OS updates and any required runtime layers (e.g., .NET Framework, Message Queuing).
3. Install STEP 7 V5.5 SP4 HF11 first. Reboot.
4. Install SIMOTION Scout V4.5. Reboot.
5. Install WinCC Flexible 2008 SP3. Apply the latest available update (Update 7 in the documented case). Reboot.
6. Import the license keys via Automation License Manager.
7. Restore the STEP 7 project (including the integrated WinCC Flexible project) from the captured backup.
8. Open SIMATIC Manager, then open the WinCC Flexible project. Run Rebuild All once on the new image to regenerate the intermediate files against the freshly installed components.
9. Open Scout, open the SIMOTION project, run Save and Compile All.
10. Re-establish the device-level connection to the D435-2 and download the SIMOTION project.
11. Re-establish the WinCC Flexible Runtime connection to the PC677 and download the Runtime project.
12. Run the Runtime on the PC677 and verify the consistency check passes on first start.

9. Verification

After the recovery procedure, the following must all be true:

1. WinCC Flexible Runtime starts without alarm 140020 in the alarm view.
2. The connection status of the SIMOTION connection shows Connected (not Fault or Disconnected).
3. Live tag values from the D435-2 are visible on at least one HMI screen and update on operator command (e.g., a jog button or setpoint write).
4. A small engineering change in Scout (rename a tag, add a tag, modify an axis parameter) propagates to the HMI after the documented save/compile/reload/rebuild sequence without raising alarm 140020.
5. Alarm 140020, if it appears transiently during the next save/compile cycle, is acknowledged and does not return on the next Runtime restart.

10. Best Practices for Stable Scout / WinCC Flexible Pairing

1. Integrate the WinCC project in Scout, not only in STEP 7, whenever the SIMOTION project is the source of truth. The side-channel path is the most failure-prone part of the chain.
2. Use a single engineering workstation for the SIMOTION + WinCC Flexible stack. Sibling HMI/SCADA products on the same image are the most common root cause of persistent 140020 errors.
3. Keep the engineering chain at the latest cumulative update level that Siemens has certified for the combination. For Scout 4.5, this is the cumulative hotfix for STEP 7 V5.5 and the latest WinCC Flexible 2008 SP3 update.
4. Take a project backup (STEP 7 + Scout, including version data) before every engineering change that affects the SIMOTION-to-HMI tag interface.
5. Document the project integration model in the project header. If the WinCC project is integrated in STEP 7 only, document the date and reason, and add a comment that any re-integration in Scout must include deletion of the stale HmiVersionStoreGlobal cache.
6. Lock the engineering workstation's install surface. Disable side-by-side product installs by removing local admin rights from engineers who do not need them.
7. Audit S7DOS and CCAgent versions on the engineering PC. Mismatched versions after a partial uninstall are a strong indicator of environmental damage.
8. Use a separate PC677 image for production from the development image. The PC677's runtime image should be frozen after Factory Acceptance Test and only patched through a controlled change procedure.

11. Error-Code and Symptom Cross-Reference

12. When to Escalate

Escalation to Siemens Technical Support is warranted when:

• Alarm 140020 persists on a clean OS image with only the certified engineering chain installed.
• The SIMOTION D435-2 firmware has been updated and the WinCC Flexible 2008 SP3 has not been re-validated against the new firmware by Siemens.
• Multiple engineering workstations exhibit the same symptom with the same project, indicating a project-level (not workstation-level) defect.
• The PC677 hardware is suspected, with intermittent communication drops that overlap with the 140020 occurrence pattern.

When escalating, attach: the SIMOTION project archive, the STEP 7 + WinCC Flexible project archive, the Scout and WinCC Flexible build numbers, the D435-2 firmware version, the Windows version of the engineering workstation, and the alarm log export from the PC677.

13. Frequently Asked Questions