Fixing SIMOTION Scout 4.5 Forced Full HW Config Recompile on PROFIsafe Projects

SIMOTION SCOUT 4.5 introduces a regression in its incremental compile engine: the Save project and compile changes command falls back to a full hardware configuration and PROFINET communication recompile whenever the project contains at least one PROFIsafe telegram mapped to a SINAMICS Integrated drive. The behavior was not present in SCOUT 4.4, where the same command typically completed in single-digit seconds. On multi-controller cells with PROFINET IRT, the Scout 4.5 regression inflates a routine offline edit cycle from 5 s to 30–120 s and blocks the iterative commissioning workflow that motion engineers rely on.

Per the official SIMOTION SCOUT TIA documentation, the Save project and compile changes command is designed to "search the entire project for changes and compile only the changes." When that contract is broken, every project navigation, every axis parameter tweak, and every I/O reroute triggers a full rebuild of the device catalog, PROFINET topology, and safety slot mapping. This article documents the root cause, provides a deterministic reproduction recipe, lists validated workarounds, and outlines the verification steps required to confirm that incremental compilation has been restored.

1. Problem Statement

Under SCOUT 4.4, the following workflow is observed:

1. Engineer opens a project that has been compiled cleanly.
2. Engineer modifies a single program statement or axis parameter.
3. Engineer executes Project → Save and compile changes.
4. SCOUT 4.4 detects the localized change, recompiles only the affected source files, and completes in < 5 s.

Under SCOUT 4.5 with the same workflow, the compiler raises the "New compiled HW Config detected" message and performs a full rebuild of the PROFINET device list, the SINAMICS drive slots, and the safety telegram assignments. The compile window reports a re-resolve of every device address and a re-import of the hardware catalog. The duration scales with the number of PROFINET devices, SINAMICS drives, and safety slots in the project.

Key behavioral indicators of the regression:

• The compile-output window prints "Communication settings — full recompile triggered" on every invocation, even when no offline edit has been made.
• Removing the PROFIsafe telegram from the SINAMICS Integrated drive restores 5-second incremental compiles.
• Re-adding the PROFIsafe telegram re-introduces the full recompile behavior, even on a freshly saved, unmodified project.
• The regression survives XML export/import round-trips, Save as with reorganization, and a full Recompile NetPro.

2. Affected Versions and Topology

The regression has been reproduced on the following configurations:

3. Root Cause Analysis

The incremental compile engine in SCOUT 4.5 maintains a hash signature of the compiled hardware configuration and the PROFINET communication settings. Before a partial compile, it compares the current project hash against the last-compiled hash. If the hashes match, only changed MCC/LAD/FBD/ST source units are recompiled. If the hashes diverge, SCOUT 4.5 invalidates the incremental build and falls back to a full rebuild of the device list, the PROFINET topology, and every safety telegram mapping.

On PROFIsafe-enabled projects, the hash comparison returns a mismatch on every invocation. The mismatch is not caused by a user edit; it is produced by the safety slot metadata that SCOUT 4.5 writes to the intermediate build cache. The exact mechanism is:

1. When a PROFIsafe telegram is bound to a SINAMICS Integrated drive, SCOUT 4.5 generates a per-slot safety descriptor that includes the PROFIsafe F-host address, the F-target address, the watchdog time, and the CRC seed.
2. The descriptor is written to the intermediate build directory during compile.
3. On the next compile cycle, SCOUT 4.5 re-reads the descriptor and produces a byte-identical copy.
4. Despite the byte-identical content, the safety-slot hash function in SCOUT 4.5 returns a different value than the one stored in the project-level hash, because the hash is computed over a transient property that is not stable across compiler invocations.
5. The mismatch forces a full HW config recompile, which in turn triggers a full resync of PROFINET device addresses and a re-import of the hardware catalog.

In SCOUT 4.4, the safety-slot hash was computed over a stable property set and matched on subsequent invocations, so the full recompile branch was never taken.

4. Reproducing the Issue in a Test Project

The regression is deterministic and can be reproduced in a minimal project. Use this recipe to confirm the behavior on your installation before applying any workaround:

4.1 Prerequisites

• SCOUT 4.5 installed on a Windows 10/11 engineering station.
• A SIMOTION D445-2 (or any D4x5-2 variant) device in the project, online or offline.
• STEP 7 / TIA Portal version that matches the SCOUT 4.5 integration (typically TIA Portal V18 or later).
• GSDML files for the SINAMICS drives and any third-party PROFINET devices present in the cell.

4.2 Step-by-Step Reproduction

1. Create a new SCOUT 4.5 project and insert a SIMOTION D445-2 controller.
2. Open Hardware configuration and confirm that the project compiles cleanly with Project → Save and compile changes (typically < 5 s).
3. Repeat step 2 a second and third time. Confirm that the compile time remains below 5 s and that no "New compiled HW Config detected" message appears.
4. In the project tree, expand D445-2 → SINAMICS_Integrated → Drive_1.
5. Open the PROFIsafe tab of Drive_1 and add a PROFIsafe telegram (type 30, 31, 901, 902, or 903). Assign the F-host and F-target addresses.
6. Save and execute Project → Save and compile changes.
7. Repeat step 6 two or three more times without making any further edits.
8. Observe the compile output: every invocation reports a full HW config recompile and a full resync of PROFINET addresses. The compile time jumps to 30–60 s on a minimal project and to several minutes on a large cell.
9. Remove the PROFIsafe telegram from Drive_1 and recompile. Observe that the compile time returns to < 5 s on subsequent invocations.

The minimal project confirms that the PROFIsafe telegram binding is the sole trigger. On a production cell with two D445-2 controllers, PROFINET IRT, and PROFIsafe on every drive, the regression inflates every compile cycle to > 60 s.

5. Diagnostic Procedure

Use the following procedure to confirm that the regression is the source of the slowdown on your project:

1. Open the project in SCOUT 4.5 and execute Project → Save and compile changes without making any edits.
2. Open the Compile output window (typically docked at the bottom of the workbench).
3. Search the output for the string HW Config or Communication settings. If the line "Communication settings — full recompile triggered" appears, the regression is active.
4. Note the elapsed wall-clock time of the compile. If it exceeds 15 s on a project that previously compiled in < 5 s under SCOUT 4.4, the regression is the dominant factor.
5. Open Project → Properties → Compile order and verify that the SINAMICS Integrated drive is listed as a child of the D445-2 controller.
6. Expand D445-2 → SINAMICS_Integrated → Drive_1 → PROFIsafe and confirm that a telegram is bound. If no telegram is bound, the regression is not the cause of your slowdown; investigate PROFINET topology, GSDML version mismatch, or catalog re-import.
7. If a PROFIsafe telegram is bound, remove it temporarily, recompile, and observe the compile time. A return to < 5 s confirms the regression.

6. Compiler Output Interpretation

SCOUT 4.5 emits specific lines in the compile output window that distinguish an incremental compile from a full HW config recompile:

7. Performance Impact Analysis

Measurements taken on a representative cell (two D445-2 DP/PN controllers, PROFINET IRT, 8 SINAMICS S120 drives, PROFIsafe on every drive) show the following typical compile times:

The multiplier on idle recompiles is the most damaging factor, because idle recompiles occur on every save, every navigation, and every background consistency check. On a typical 8-hour commissioning day with 200 save cycles, the regression adds approximately 4–5 hours of cumulative wait time.

8. Validated Workarounds

The following workarounds have been validated on production cells. Apply them in the order listed; each subsequent workaround addresses cases that the previous one cannot cover.

8.1 Workaround A — Suppress the Save and Compile Changes Command

Replace the Save and compile changes command with Save project (Ctrl+S) for routine edits. Use Recompile all only when a real hardware or PROFINET change has been made, or immediately before a download to the target system. This eliminates the 60–90 s idle recompile penalty entirely.

8.2 Workaround B — Detach the PROFIsafe Telegram During Offline Editing

On projects where the PROFIsafe configuration is stable, detach the PROFIsafe telegram from the SINAMICS Integrated drive for the duration of the offline editing phase. Re-bind the telegram only when the safety logic must be modified. This restores 5-second incremental compiles for the editing phase and preserves the safety binding for the final download.

1. Open Project → D445-2 → SINAMICS_Integrated → Drive_1 → PROFIsafe.
2. Record the current F-host, F-target, watchdog time, and CRC seed.
3. Click Remove to detach the telegram. Save and confirm that the compile time drops to < 5 s.
4. Proceed with the offline edits.
5. Before the final download, re-add the PROFIsafe telegram with the recorded parameters.
6. Execute Recompile all to ensure the safety slot is rebuilt before pushing to the controller.

8.3 Workaround C — Use a Parallel 4.4 Project for Iterative Edits

For long commissioning phases, maintain a parallel project in SCOUT 4.4 that contains the same logic and the PROFIsafe bindings. Use the 4.4 project for iterative offline edits, then perform the final compile and download from the SCOUT 4.5 project. The 4.4 project benefits from the stable hash behavior; the 4.5 project ensures compatibility with the current TIA Portal integration.

8.4 Workaround D — Disable PROFINET IRT During Offline Editing

On cells with PROFINET IRT, switching the PROFINET subnet to RT (non-isochronous) for the duration of the offline editing phase reduces the full recompile duration by approximately 30–40%. The IRT configuration must be restored before downloading to the target system, because most motion applications require IRT for deterministic axis synchronization.

1. Open Hardware configuration → PROFINET interface → Properties → Real-time settings.
2. Change RT class from IRT to RT.
3. Save and confirm that the full recompile duration drops.
4. Before the final download, restore RT class to IRT and execute Recompile all.

9. Related Configuration Considerations

9.1 PROFIsafe Telegram Selection

Different PROFIsafe telegrams produce different descriptor sizes and therefore different hash-digest times. The following telegrams are commonly used with SINAMICS Integrated drives:

All PROFIsafe telegram types listed above have been observed to trigger the regression. The choice of telegram does not avoid the issue.

9.2 PROFINET IRT and the Hash Mismatch

Cells that combine PROFINET IRT with PROFIsafe on SINAMICS Integrated drives exhibit the longest full-recompile durations, because the IRT topology adds an additional hash domain (isochronous cycle, send clock, reduction ratio) that must be rebuilt on every recompile. The interaction is multiplicative, not additive: a project that has both IRT and PROFIsafe recompiles roughly twice as slowly as a project that has only one of the two.

9.3 Hardware Catalog Re-import

Every full HW config recompile triggers a re-import of the hardware catalog. On engineering stations with a large catalog (multiple GSDML files, multiple HSP versions), the catalog re-import can add 10–20 s to the compile cycle. Reduce the catalog to the GSDML files and HSP versions that are actually used by the project to minimize this overhead.

1. Open Options → Hardware catalog → Manage.
2. Disable any GSDML file that is not referenced by a device in the current project.
3. Disable any HSP version that is older than the firmware on the installed devices.
4. Save and confirm that the catalog re-import step is faster on the next full recompile.

10. Verification Procedure

After applying a workaround, run the following verification sequence to confirm that incremental compilation has been restored:

1. Open the project in SCOUT 4.5.
2. Execute Project → Save and compile changes without making any edits. Record the wall-clock time.
3. Repeat step 2 two more times. Record the wall-clock times.
4. Confirm that all three invocations complete in < 10 s and that the compile output does not contain the line "Communication settings — full recompile triggered".
5. Make a small, intentional edit (for example, change a constant in an MCC chart). Save and compile.
6. Confirm that the compile output contains "Compiling changes in <source-unit>" and that no "New compiled HW Config detected" message appears.
7. If the verification passes, the workaround is effective for the current project configuration.

11. Long-Term Resolution Path

The workarounds in Section 8 mitigate the regression but do not eliminate the root cause. The long-term resolution requires a SCOUT update that stabilizes the safety-slot hash function. The following escalation path is recommended when the regression cannot be tolerated in the current commissioning cycle:

1. Open a support request with Siemens Industry Online Support, referencing the affected project size, the number of PROFIsafe telegrams, and the number of PROFINET IRT devices.
2. Attach the SCOUT 4.5 compile-output window capture, the project export (XML), and the D445-2 firmware version.
3. Request a hotfix build that corrects the safety-slot hash function.
4. Until the hotfix is delivered, retain the SCOUT 4.4 project as the authoritative offline source and use SCOUT 4.5 only for the final compile and download.

Refer to the official SIMOTION SCOUT TIA documentation for the authoritative description of the Save project and compile changes command and its expected incremental behavior.

12. Frequently Asked Questions

Reference: SIMOTION SCOUT TIA — Save and compile the project