Troubleshooting SIMOTION D435-2 Stuck in STOP with Event 16#F360:B2BA

A SIMOTION D435-2 that powers up, completes startup, displays READY=ON, STOP=ON, and SF=ON, and refuses to transition to RUN with diagnostic event 16#F360:B2BA in the buffer is a classic post-firmware-change / post-CF-card-swap failure. The combination of a yellow STOP LED, a red SF (System Fault) LED, and a controller that completes startup but cannot execute user code is diagnostic of a configuration/runtime mismatch — typically a technology package (TP) version mismatch, a corrupted runtime project, or a license/inconsistency issue on the replacement CF card.

This reference consolidates the engineering procedure to identify, isolate, and recover the controller, drawing on official Siemens SIMOTION D435-2 commissioning documentation and the SCOUT TIA operating mode workflow.

1. Problem Summary

2. SIMOTION D435-2 Hardware and Firmware Context

The SIMOTION D435-2 is a drive-based motion controller that integrates a SIMOTION CPU and a SINAMICS S120 power unit / control unit on a single platform. The runtime is loaded from a CompactFlash (CF) card inserted in the controller. The CF card holds:

• The SIMOTION runtime image matching the firmware version
• User project (technology packages, programs, configuration data, TO configuration)
• Licensing information (CF card-based license)
• Persistent system data (drive parameters, encoder data, retain variables)

When a CF card is replaced, the runtime image on the new card must match the version of SCOUT/SCOUT TIA used for the project download, and the technology package versions referenced by the project must be installed on the target. Firmware V5.4 requires a consistent toolchain — typically SIMOTION SCOUT TIA V5.4 SPx or the matching version of TIA Portal with the SIMOTION option package.

3. LED Status Interpretation

The D435-2 front-panel LEDs used in this diagnosis follow the standard SIMOTION CPU LED model. See the SIMOTION D4x5-2 Commissioning and Hardware Documentation for the canonical LED table.

Per the official SCOUT Getting Started D435-2 sample project manual, a yellow STOP LED with all other LEDs off means startup is complete and the device is idle in STOP. The presence of an additional red SF LED indicates that startup completed but a system fault is latched.

4. Diagnostic Event 16#F360:B2BA — Structure and Decoding

SIMOTION diagnostic events follow a fixed hexadecimal structure:

Event ID: 16# F360 : B2BA
         │   │      └────► Sequential event number (specific cause)
         │   └───────────► Event class (technology, configuration, runtime, etc.)
         └───────────────► 0xF prefix = fault class (F-class = error, F3xx = technology/runtime)

F-class events in the 0xF3xx range typically belong to the SIMOTION runtime / technology object layer. The exact meaning of B2BA is firmware-version-dependent, but in the V5.4 context the event is most commonly associated with one of the following conditions on a freshly swapped CF card or after a firmware upgrade:

• Technology package version mismatch — the project references a TP (e.g., TPTO, TPCAM, TPaxis) version not present on the runtime, or a TP is corrupt on the CF card.
• Inconsistent project / runtime pairing — the project on the CF card was downloaded with a SCOUT version that does not match the runtime image version, or vice versa.
• CF card license or boot image inconsistency — the replacement CF card does not carry the correct license key for the loaded project, or the boot block is non-conformal.
• Loss of retain / persistent data — the controller detected that the retain data area is inconsistent with the current configuration, which on D435-2 can surface as a runtime startup fault.

5. Root Cause Analysis Matrix

6. Pre-Recovery Checklist

Before clearing the controller, capture the following — clearing the diagnostic buffer destroys the evidence required to root-cause F-class events.

1. Connect to the D435-2 with SCOUT / SCOUT TIA over the configured PROFIBUS or PROFINET route.
2. Open Diagnosis > Device Diagnostics > Diagnostic Buffer and export the full buffer to a text or CSV file. Capture all entries from the most recent power-on, not only the highlighted F360:B2BA.
3. Take a screenshot of the Device Diagnostics > Version view: SIMOTION runtime version, technology package versions, SINAMICS version, and CF card serial number.
4. Export the project archive from the offline PG/PC: Project > Archive. Name it with the date, the controller MLFB, and the firmware version.
5. Verify the CF card part number and capacity against the SIMOTION D4x5-2 approved CF card list in the hardware manual. Non-approved cards can produce intermittent F3xx events.
6. Confirm the PG/PC SCOUT version: Help > About. SCOUT major.minor must match the SIMOTION runtime version (V5.4 ↔ SCOUT 5.4 SPx).

7. Step-by-Step Recovery Procedure

The following procedure is the field-proven recovery sequence. It is intentionally conservative: it does not delete user data, does not reformat the CF card, and does not require a license retransfer unless the CF card itself is the root cause.

7.1 Acknowledge the Fault and Try a Controlled STOP → RUN

1. In SCOUT, right-click the D435-2 node and choose Operating Mode.
2. The Control Operating Mode dialog allows switching between RUN and STOP. Per the SIMOTION SCOUT TIA operating modes documentation, this is the canonical way to command a state change from engineering.
3. Acknowledge the F-class event when prompted. If the controller returns a "state change not permitted" error, the F-class event must be cleared first by acknowledging or by following the steps in 7.2.
4. Issue RUN. If the controller returns to RUN and the SF LED clears, the cause was transient (e.g., a momentary topology hiccup). Continue with verification in Section 8.

7.2 Verify Project / Runtime / TP Consistency

1. In SCOUT, open the project and select the D435-2.
2. Choose Target System > Compare > Online/Offline. Review the diff.
3. Any of the following diffs confirm a version mismatch and are the most common cause of 16#F360:B2BA on a freshly swapped CF card:
   • Technology package version differs between online and offline.
   • SIMOTION runtime version on the target differs from the SCOUT build version.
   • Drive / SINAMICS version differs from the offline project.
4. If mismatches exist, you must realign. Do not simply reload the project — the runtime on the CF card is the source of truth for the F-class event.

7.3 Realize the Project to the Controller

1. Ensure SCOUT version matches the controller firmware V5.4 exactly (down to SP level where possible).
2. Right-click the D435-2 → Target System > Download > To Target System.
3. Select Download to target system with reset. This clears the retain data and the diagnostic buffer as part of the controlled download.
4. When the download completes, the controller will perform an automatic restart. Observe the LED sequence: RDY flashing → all LEDs off briefly → RDY solid → STOP solid.

7.4 Perform a Copy RAM to ROM

1. After the download, the project is in volatile RAM. Issue Target System > Copy RAM to ROM to persist the configuration to the CF card. The original report from the field notes that Copy RAM to ROM was performed, but the controller still did not run — this is consistent with the runtime image on the CF card being the issue, not the project data. Repeat the download with reset before declaring the fault cleared.

7.5 If the Controller Still Does Not Run

Escalate in this order:

1. Reload the runtime image on the CF card. Use SIMOTION CF card management (SCOUT > Target System > CF Card > Load Runtime Image to CF Card) and select the runtime image that matches SCOUT V5.4 exactly. This rebuilds the boot block and the system data area on the card.
2. Reapply the license. The CF card license is keyed to the card serial number. A new card requires a license retransfer via the Web License Manager or the Automation License Manager.
3. Verify the hardware topology. After a hardware change, run Target System > Compare > Topology in SCOUT. A D435-2 has DRIVE-CLiQ ports; a misconfigured or swapped port assignment will surface as a startup F-class event.
4. Check SINAMICS side. Open the SINAMICS integrated drive in SCOUT and read its diagnostic buffer. A drive-side startup fault can prevent the SIMOTION CPU from completing the transition to RUN.
5. Replace the CF card with a known-good card from the approved list. If the new card is non-approved or has been used in a different controller family, it can produce F3xx events even after a clean download.

8. Verification

After recovery, perform the following checks before returning the machine to production:

Run a controlled motion test (jog, homing, single-axis positioning) before resuming full production. A F3xx fault that was previously masked by the immediate SF state can resurface as a motion-side error after the controller is back in RUN.

9. Prevention and Best Practices

• Pair the CF card with the runtime version. Use the SIMOTION CF card image that matches the SCOUT version (V5.4 → CF card image 5.4.x). Do not mix images across major versions.
• Use only approved CF cards. The hardware manual lists approved vendors, capacities, and part numbers. Industrial-grade SLC cards only; consumer MLC/TLC cards will fail in this environment.
• Always perform a controlled download with reset after a CF card swap. A simple project download without reset can leave inconsistent retain data and license artifacts that surface as F3xx events on the next restart.
• Export and archive the project before any firmware change. SCOUT project archives are the only reliable way to roll back if a firmware upgrade is not compatible with the existing TP versions.
• Read the full diagnostic buffer, not just the highlighted event. SIMOTION events are correlated; the root cause is often a few entries before the F3xx that stopped the controller.
• Document the firmware and TP version matrix in your project. A SIMOTION V5.4 controller can run projects built with multiple TP versions, but the runtime image on the CF card must contain the highest TP version referenced.

10. Field-Proven Diagnostic Sequence (Summary)

1. Capture full diagnostic buffer (export to file).
2. Read the message text of 16#F360:B2BA and any preceding events.
3. Compare online vs. offline project (TP versions, runtime version, drive version).
4. Realign SCOUT version with controller firmware V5.4.
5. Download to target system with reset.
6. Copy RAM to ROM.
7. Command RUN via the SCOUT operating mode dialog.
8. Verify LEDs, TOs, retain data, and a basic motion test.
9. If still failing, reload the CF card runtime image and reapply the license.
10. Replace the CF card only as a last resort.

FAQ