Resolving SIMOTION D435 Upload Inconsistency in Scout 4.2

Problem Overview: SIMOTION D435 Module Reports Inconsistent After Upload

When using SIMOTION Scout V4.2 / V4.2.1 with the SIMOTION D435 motion controller, engineers frequently encounter a situation in which the "Load CPU/Drive Unit to PG" (also labelled Upload device to PG) operation completes without error, yet the D435 module on the S7 station is flagged as inconsistent in the project navigator. The inconsistency is typically shown as a red error overlay on the D435 device icon, the symbol of the SIMOTION CPU in HWConfig, or as an entry in the consistency log. The symptom is independent of the actual runtime state of the controller: the target device is healthy, communication works, and the drive object is reachable online; nevertheless, the offline project cannot be brought into a consistent state through the upload wizard alone.

This article documents the root cause identified on the field: the SIMOTION upload path does not transfer HWConfig data. The Scout upload only synchronises SIMOTION runtime data (programs, technology objects, configuration data, trace data, drive parameters stored inside the SIMOTION project). The PROFIBUS / PROFINET topology, the S7 station structure, the slot assignment, and the GSD references belonging to the SIMOTION D435 are owned by STEP 7 HWConfig and remain in the original project. If the offline project was opened from a different source (for example, a ZIP archive retrieved with "Retrieve from archive"), the offline HWConfig and the online device data drift apart, and the D435 shows up inconsistent immediately after upload.

SIMOTION Scout Project Model: HWConfig vs. SIMOTION Data

SIMOTION Scout is built as a STEP 7 plug-in. The D435 is a SIMOTION device with an integrated SINAMICS S120 drive subsystem, and it is inserted into a STEP 7 S7 station as a module on the PROFINET / PROFIBUS network. The project on disk therefore contains two cooperating databases:

1. STEP 7 HWConfig (S7 project data) — owns the station, rack, slot, GSD/GSDML references, submodule configuration, and the SIMOTION module's address area.
2. SIMOTION project (DCC, MCC, ST, LAD/FBD sources, technology objects, drive configuration) — owns the runtime program, axis configuration, TO data, cam data, and the SINAMICS drive parameter set inside the controller.

The two databases reference each other: HWConfig knows that slot X contains a SIMOTION D435, and the SIMOTION project knows that it is bound to the station created in HWConfig. When either side changes, the cross-reference must be regenerated. SIMOTION's Target Device Output window and the consistency log surface the result of this cross-check.

Root Cause: HWConfig Data Is Not Transferred During SIMOTION Upload

Selecting CPU/Drive Unit → Load to PG in SIMOTION Scout triggers a write of the SIMOTION-only data from the target device to the offline project on the engineering station. The upload uses the SIMOTION runtime's online services (port 102 / ISO-on-TCP for S7 routing, or PROFINET with the configured connection). The payload that the controller returns contains:

• The active SIMOTION project (programs, libraries used online, technology object configuration).
• Drive parameters stored inside the SIMOTION project (SINAMICS S120 parameter set assigned to the SIMOTION axis context).
• Retain / persistent variables if configured.
• Trace recordings and diagnostics buffer contents (online read, not stored in the project).

It does not contain:

• The S7 station structure (rack, slot, neighbouring modules).
• The HWConfig object properties of the SIMOTION D435 (rack number, slot, I/O addresses, diagnostic addresses, submodule parameter assignment).
• The PROFIBUS / PROFINET configuration of the D435 as a node.
• The GSD or GSDML import references required to rebuild the station.

The upload therefore completes, the SIMOTION project is updated, but the S7 station in HWConfig remains the one that was opened from the offline project. If the offline HWConfig was loaded from an archive that did not include the live station data, the project is in two parts: a fresh SIMOTION side, and a stale S7 side. Scout's consistency checker compares the SIMOTION station reference (slot, name, address) inside the uploaded project against the S7 station reference still in the offline HWConfig, finds a mismatch, and marks the D435 inconsistent.

Reproducing the Inconsistency in Scout V4.2 / V4.2.1

The fault is reproducible on a clean machine using SIMOTION Scout V4.2.1 with a D435 controller running firmware compatible with Scout V4.2 (typically V4.2.x firmware for the SIMOTION side, SINAMICS V4.x for the drive side). The procedure is:

1. Create a complete, consistent project for the D435 in Scout V4.2.1 on machine A.
2. Archive the entire project folder into a ZIP file (for example, using the STEP 7 Archive function, or the OS-level zip tool).
3. Transfer the ZIP to machine B and select File → Retrieve → Project from a compressed archive (.zip) inside Scout.
4. Open the project on machine B, navigate to the D435 in the project tree, and confirm the project is consistent (no red overlay, no entries in the consistency log).
5. Go online, select CPU/Drive Unit → Load to PG (or Target system → Load → Load to PG depending on the menu layout).
6. Wait for the upload to complete; the SIMOTION project is refreshed.
7. Inspect the project navigator: the D435 now shows a red error overlay and the consistency log lists the D435 as inconsistent.

Variations on this recipe that exhibit the same defect include opening a project from a network share whose offline state was last saved on a different engineering machine, copying the project via file share instead of Retrieve from archive, and restoring the project from a backup that was created on a different Scout version than the live one.

Resolution Path A: Download the Project to Restore HWConfig

When the controller is reachable online and the running configuration is the desired baseline, the fastest recovery is a full project download. This pushes both the SIMOTION side and the S7 side from the offline project to the controller, so the controller's stored station description is rebuilt from the offline project.

1. Resolve the offline inconsistency on the engineering side first by opening the original unpacked project from the folder — not from the archive (see Resolution Path C).
2. Open SIMOTIC Manager / TIA Portal as required, navigate to the S7 station containing the D435.
3. Select PLC → Download to Target System → Hardware and Software (only differs in S7) from HWConfig to write the station configuration to the controller.
4. In Scout, right-click the D435 and select Target system → Download → Project to target system (or CPU/Drive Unit → Download).
5. Choose the options for technology objects, drive configuration, and program sources; tick Download with consistency check if available.
6. Confirm the download and observe the Target Device Output window. Each step is logged with a green check or a red cross.
7. After the download, select Project → Check consistency. The D435 should now be consistent.

Resolution Path B: Upload the Station from HWConfig

If the offline project cannot be brought to consistency and the controller is the source of truth, the S7 side can be read back from the controller independently of the SIMOTION upload.

1. In SIMATIC Manager, open the project that contains the D435 (the same project opened in Scout, since Scout shares the STEP 7 database).
2. Open HWConfig for the station.
3. Select PLC → Upload Station to PG. The dialog lists detected stations on the subnet; choose the D435 station and confirm.
4. HWConfig reads the actual station configuration from the controller and replaces the offline station with the live one.
5. Return to Scout and select Project → Check consistency. The cross-reference between the freshly uploaded S7 station and the previously uploaded SIMOTION project now matches.

This approach has the advantage of not disturbing the running controller, because only the offline engineering data is updated. The disadvantage is that any unsaved offline changes on the engineering side will be overwritten; export them to source files first if they need to be preserved.

Resolution Path C: Open the Original Unpacked Project

Field experience with Scout V4.2.1 indicates that the project retrieved from a compressed archive may carry a stale station reference even when the archive is fresh. The cleanest recovery is therefore to abandon the archive-derived project and reopen the original folder-based project.

1. Locate the original project folder — the one that was last saved on the engineering machine that originally compiled the project.
2. Close the archive-derived project in Scout.
3. Use File → Open → Project and navigate to the original .s7proj or unpacked project folder. Do not use Retrieve from archive for this step.
4. Wait for the consistency check to complete. The D435 should be consistent immediately.
5. If a fresh upload to PG is still required, perform it now. With the correct offline HWConfig in place, the post-upload state remains consistent.

The root cause behind the archive-induced inconsistency is that Retrieve from archive in Scout is a wrapper around the STEP 7 Simatic Manager archive function. The wrapper rebuilds the project skeleton, but the GSDML references, the absolute paths inside the STEP 7 database, and the cross-references to the SIMOTION side can desynchronise from what is on the controller, especially when the archive was created on a machine with a different Scout install path, language, or installed option packs.

"Retrieve from Archive" Behavior: ZIP vs. Folder Project

STEP 7's Retrieve function is designed to recreate a project on disk from a compressed archive, preserving the internal structure of the STEP 7 database. SIMOTION Scout invokes the same function for the S7 portion of the project. The result is normally equivalent to copying the unpacked project folder, with two notable differences:

• Absolute paths: Internal references to GSD files, library directories, and .srf symbols may still be anchored to the originating machine. Scout V4.2 in particular is sensitive to a missing SIMOTION directory in the project root.
• Symbol table binding: The shared symbol table between the S7 side and the SIMOTION side is rebuilt by the Retrieve process, but the checksum against the controller is not. This is the most common source of the D435 being flagged inconsistent immediately after a Retrieve.

Workaround for projects that must be transferred as a single file: archive using STEP 7 → Archive on the originating machine, then retrieve with STEP 7 → Retrieve on the target machine. This keeps the absolute paths consistent because both sides use the same archive root logic. Avoid the Scout-level Retrieve from compressed archive shortcut when the project is intended to be opened on a machine that does not have an identical Scout installation.

Consistency Check Procedures and Diagnostic Windows

Scout provides several windows and menus that surface the consistency state. Knowing which window to look at is half the solution.

For the specific case of the D435 upload inconsistency, the most useful diagnostics are the consistency log (for the offline check) and the Target Device Output window (for the online upload result). When the project is opened from the correct folder and the upload is performed, both windows should report no errors and the D435 should turn from red to a normal icon in the project navigator.

Verification After Repair

After applying any of the three resolution paths, run the following verification sequence to confirm the fix is durable.

1. Offline consistency: Project → Check consistency. No entries with severity Error; the D435 icon is no longer red.
2. Online connection: Target system → Connect to target system. Connection is established without the consistency prompt reappearing.
3. Upload round-trip: CPU/Drive Unit → Load to PG with the project already consistent. The upload completes, the consistency check passes again.
4. Drive data integrity: In Scout, open the SINAMICS drive object inside the D435 and verify the parameter set was preserved. Diff against the last known-good parameter set if available.
5. Technology object integrity: Open each axis, external encoder, cam, and path. Verify the configuration and the assignment of the drive is intact.
6. Retain variables: If the project uses retain data, verify the values match the expected state. A loss of retain indicates a controller reset was performed, which is acceptable for a download fix but not for an upload fix.
7. Project archive test: Archive the now-consistent project to a ZIP, retrieve on a different machine, and re-verify. If the inconsistency returns on the second machine, the issue is the retrieve step, not the controller.

Troubleshooting Matrix: Symptoms and Corrective Actions

Version and Firmware Constraints: Scout 4.2.1, D435 Firmware

Scout V4.2 was released as a transitional version supporting both the classic SIMATIC Manager and the early TIA Portal integration of SIMOTION. V4.2.1 is the maintenance update that addressed several consistency issues, including the handling of compressed archives. The compatible SIMOTION D435 firmware is in the V4.2.x line; pushing a D435 to a V4.3 or V4.4 firmware requires a matching Scout upgrade. Mismatched firmware and Scout versions typically manifest as a "version conflict" in the consistency log rather than a generic D435 inconsistency, but the symptom can look identical to the engineer at first glance.

For projects that must be maintained long term, Siemens recommends aligning all engineering stations to the same Scout version, the same installed option packs, and the same firmware on the controller. A standard SIMOTION project archive should always include the matching GSD / GSDML import set.

Best Practices for SIMOTION D435 Project Backup and Recovery

The following field-proven practices minimise the chance of the D435 consistency issue recurring:

1. Use the same Scout version and option packs across the engineering team. A project archived on a machine with the TIA option installed can fail to retrieve cleanly on a machine that only has the classic Scout.
2. Archive from STEP 7, not from Scout, when the project will be opened on a different machine. This routes through the canonical archive logic that Scout itself calls internally and avoids the wrapper-induced path issues.
3. Keep the source files checked in: Store ST, MCC, LAD/FBD sources, and the project as a whole in a version control system. The upload-to-PG workflow is for short-term retrieval, not for the canonical backup.
4. Document the controller firmware and Scout version in the project header. A simple comment block at the top of the main source file records the engineering baseline, so the next engineer can match the toolchain before opening the project.
5. After every online change, run Project → Check consistency before archiving. This forces the consistency log to clear and ensures the archive is a known-good baseline.
6. For multi-machine fleet, run a download round-trip on a single sacrificial machine after each Scout upgrade to confirm the consistency handling is still robust.
7. Use the SIMOTION D435 web server (default port 80 / 443) for quick health checks independent of Scout. The web server can confirm whether the controller is in RUN / STOP and whether the drive is in fault, without requiring a full engineering session.

FAQ