Resolving Simotion D435 CX32 Automatic Configuration Failures

Problem Overview

When commissioning a SIMOTION D435-2 controller with two CX32-2 Controller Extensions distributed across the integrated DRIVE-CLiQ ports X102 and X103, the automatic configuration phase may complete for the integrated Sinamics and the first CX32 (on X102) but stall at the second CX32 (on X103) with the diagnostic state Wait for CU link slaves. In subsequent re-runs, SCOUT (or TIA Portal with the SIMOTION option) may report a topology comparison warning, indicating that the configured topology on one side does not match the physical topology on the other. The fault pattern is firmware-version agnostic and is driven instead by stale project state inside the SIMOTION project and SCOUT/TIA cache.

This article documents the field-recovered procedure, the DRIVE-CLiQ behavior that drives it, and the diagnostic steps that allow the engineer to distinguish hardware from project causes before any rebuild is attempted.

Affected Hardware and Firmware

The fault pattern has been reproduced across D435-2 firmware V4.4, V4.5, V5.1, and V5.2 paired with CX32-2 firmware V2.6, V4.3, V4.4, V4.5, V4.7, and V5.2. The root cause is independent of firmware level but the recovery procedure is the same across all combinations. Confirm the active firmware using Menu > Target System > Accessible Nodes in SCOUT or Online > Diagnostics > Firmware Version in TIA Portal before continuing.

DRIVE-CLiQ Topology Background

The D435-2 executes the SIMOTION user program and simultaneously acts as a DRIVE-CLiQ hub for the integrated Sinamics. CX32 extensions inherit the role of a distributed Control Unit — they do not run SIMOTION programs, but they forward axis data, terminal data, and TM/ SMC/SM module I/O back to the D435-2 over DRIVE-CLiQ ports X102 or X103. The D435-2 port map is fixed in firmware:

The integrated Sinamics on the D435-2 itself is enumerated as port 0 and is always the first component under the D435 in the topology view. Each CX32 in turn exposes its own X100-X105 ports, so axes can be cascaded to a depth of 8 nodes per CX32 line-up.

Figure 1 — Typical fault topology: X102 to CX32 #1 completes, X103 to CX32 #2 stalls at the Wait-for-CU-link-slaves state.

Root Cause Analysis

Three independent causes have been documented in the field for the same symptom set. Each should be ruled out in the order presented before any rebuild is initiated.

1. Stale topology entries inside the offline SIMOTION project. SCOUT caches the previous topology and only partially overwrites it when a new CX32 is added through the HW catalog. The X102 CX32 receives a clean assignment because the original project never referenced it, but the X103 CX32 inherits prior slot/port mapping from a previous CX32 incarnation. The remaining entries on the X103 side force the controller to wait for a CU link that no longer exists, surfacing as Wait for CU link slaves.
2. Component firmware mismatch after a partial firmware update. If the D435-2 firmware is updated but the CX32-2 firmware is left at an older version (or vice-versa), DRIVE-CLiQ negotiation stalls because the heartbeat / version-request telegrams do not match the firmware signature the D435 expects. The first CX32 may have been previously updated while the second was missed, which is a common pattern in multi-cabinet systems.
3. DRIVE-CLiQ cable or backplane failure on the X103 line. A bent pin, contamination on the RJ45+ locking tab, or a damaged cable between D435 X103 and CX32 #2 can keep the link at half-up. The integrated Sinamics and CX32 #1 come up because they sit on different physical ports, masking the X103 defect until the configuration phase attempts to enumerate it.

Diagnostic Procedure

Run the following checks before opening the project offline. Each step is non-destructive to the running program.

1. Capture the alarm buffer. With the controller online, navigate to Target System > Alarms in SCOUT (or Online > Alarms in TIA). Trigger the Wait-for-CU-link-slaves state by repeating the automatic configuration and press the Cancel button the moment it stalls. The buffer will typically hold DRIVE-CLiQ topology alarms — F08501 (DRIVE-CLiQ: connection lost) and F08502 (DRIVE-CLiQ: component sign-of-life failure) are the most common. Filter the buffer to the X103 subtree by right-clicking the column header.
2. Inspect the topology tree. In SCOUT open Target System > Topology. The right pane (offline project) should mirror the left pane (actual topology). A divergence marked with a red X next to the X103 entry confirms the offline / online mismatch. The Topology Comparison dialog lists the missing or extra component, including its DRIVE-CLiQ address and serial number.
3. Read the CX32-2 diagnostic LEDs. On the CX32-2 the RDY LED should be solid green, the OUT LED for the X103 port solid green, and the LINK LED blinking at 1 Hz once topology is established. If OUT on the X103 port is dark or red, the issue is at the physical layer (cable, port, or CX32 module).
4. Loop the X103 cable to the integrated Sinamics. Temporarily plug the X103 cable into the integrated Sinamics X100 port (a known-good port) to confirm whether the cable is healthy. If the topology then completes, the D435 X103 port is suspect. If it still stalls, the cable or CX32 #2 is suspect.
5. Confirm firmware parity. Use Target System > Device Diagnostics > Firmware for the D435 and each CX32. The D435-2 firmware should match the SIMOTION runtime version, and the CX32-2 firmware should match the Sinamics CU320 firmware of the cascaded line-up. A drift of more than one minor version typically requires a coordinated update.

Step-by-Step Recovery (Clean Rebuild)

If the diagnostic step confirms a stale project topology, the following clean rebuild restores automatic configuration. The procedure keeps the SIMOTION program source intact; only the HW configuration is rebuilt.

1. Back up the active project. In SCOUT use Project > Archive > Save As with with sources enabled. In TIA Portal use Project > Archive. Save the archive to a path that is not on a network share prone to write-protect locking.
2. Go offline with the D435-2 and confirm that the PC/PG is the only active node on PROFINET/PROFIBUS.
3. Open the HW configuration of the SIMOTION D435-2. In SCOUT this is the HW Config editor; in TIA Portal it is the Device View of the D435-2 module.
4. Remove every CX32-2 instance from the topology. Right-click each CX32 in the rack and select Delete. SCOUT will prompt to also delete the assigned SIMOTION program(s). Answer Yes — the programs will be re-bound automatically after the CX32 is reinserted. This is the operation that the user successfully ran in the source case.
5. Save and compile the project. Use Station > Save and Compile in SCOUT or Project tree > Compile > HW only in TIA. Confirm no compile errors before continuing.
6. Re-insert CX32-2 #1 on port X102. Drag the CX32-2 from the catalog to the X102 subslot. The integrated Sinamics remains at port 0 and is untouched.
7. Re-insert CX32-2 #2 on port X103. Drag a fresh CX32-2 instance to the X103 subslot. Do not duplicate an existing entry; the catalog insertion must create a new component ID.
8. Re-bind the user program to the new CX32 instances. If SCOUT removed the binding, drag the program object back onto the assigned execution level (BackgroundTask / CyclicTask / MotionTask) of the D435-2.
9. Recompile and download the project to the D435-2. Use Target System > Download > Project to Target System in SCOUT or Online > Download to Device in TIA.
10. Re-run Automatic Configuration. Right-click the D435-2 > Automatic Configuration. The status bar should advance from Establish CU link — Wait for CU link slaves — to Configuration OK within one topology scan cycle.

Verification

After automatic configuration completes, validate each axis and module individually before returning the line to production.

1. Topology tree consistency. In SCOUT, Target System > Topology > Compare Offline/Online must show no differences. In TIA Portal, the Device View of the D435-2 should show green check marks on every component.
2. Axis test. From the SIMOTION user program issue a controlled motion command on each axis (e.g., _enableAxis(); _pos[axis] = 0; _move(velocity, position)). Confirm the actual position tracks the setpoint within the configured following-error window.
3. Alarm buffer clean. Target System > Alarms > Clear the buffer, exercise the line for one full shift, and confirm no new F08501, F08502, or F01300 (Topology error) alarms have been logged.
4. Hot-plug simulation. With the line running, momentarily disconnect and reconnect the X103 cable. The CX32 #2 should fall back, re-link, and resume operation within 2-5 seconds without a controller restart.
5. Project consistency across reboots. Power-cycle the entire line and confirm that the D435-2 boots into RUN state without operator intervention. The automatic configuration is now deterministic and reproducible.

Preventive Practices

The fault can be eliminated at the source with a small set of project-management and commissioning rules.

• Use one project per physical configuration. Never reuse an offline SIMOTION project after a CX32 or motor swap. Branch the source tree in version control instead of overwriting the HW configuration in place.
• Standardize firmware images. Maintain a single firmware archive for each release. Before a multi-CX32 site visit, flash all D435-2 and CX32-2 modules from the same archive to avoid partial-upgrade drift.
• Validate the topology at first power-up. Use Automatic Configuration on a bench rig (with the CX32 line isolated) and archive the resulting topology view. Use the same archive for production to guarantee first-time-right commissioning.
• Label every DRIVE-CLiQ cable at both ends. The DRIVE-CLiQ protocol allows automatic crossover detection, but a mis-plugged cable at the back of a cabinet will still stall the configuration phase. Pre-printed cable labels (CX32-1 ↔ X102, CX32-2 ↔ X103) eliminate this class of error.
• Lock the SCOUT/TIA cache. In SCOUT disable Options > Settings > Online > Automatic Online Topology Update after the first successful configuration. This prevents the offline project from being silently rewritten by a transient DRIVE-CLiQ topology deviation during commissioning.
• Plan for at least one factory reset per year. Schedule a planned maintenance window where the D435-2 and CX32-2 modules are factory-reset and the archived project is reloaded. This keeps the offline and online topologies in lock-step and surfaces any latent project drift.

Related Faults and Alarm Codes

Compatibility Matrix

The CX32-2 is the variant used in current commissioning. Older CX32-1 hardware (without the -2 suffix) is not firmware-compatible with the D435-2 family and should not be mixed on the same DRIVE-CLiQ line.

Frequently Asked Questions