Fixing SIMOTION STOP on TechnologicalFaultTask Interrupt Overflow

1. Problem Overview

On multi-axis SIMOTION 425 DP/PN controllers paired with SINAMICS S120 double and single motor modules, removing the Delay program execution selection from the Enable Function on more than one axis at the same instant drives the controller directly into STOP mode. The diagnostic buffer entry recorded by the runtime is:

STOP caused by execution system, cause: too many interrupts for the task TechnologicalFaultTask

Once the STOP is active, the user program is no longer executed. All SINAMICS outputs are disabled and follow the configured substitute-value behavior described for SIMOTION SCOUT TIA operating modes. Recovery requires either a STOP→RUN transition from the SIMOTION SCOUT TIA Control Operating Mode dialog or a power-cycle of the SIMOTION CPU. Restoring the Delay program execution selection re-stabilizes the system, but the user observes a measurable motion latency that the original removal was meant to eliminate.

The phenomenon is not a defect in the SIMOTION firmware; it is an architectural consequence of how the TechnologicalFaultTask is scheduled. When several TO axes trigger the same fault task in the same servo cycle, the runtime exceeds the configured alarm queue depth, raises alarm 30002, and escalates by forcing the controller to STOP.

2. Affected Hardware and Topology

The fault is observed on systems configured with the following components:

The fault is independent of the bus media — both DP and PN variants of the D425 reproduce the symptom once the gating mechanism is removed.

3. Root Cause Analysis

SIMOTION provides a per-axis feature called Delay program execution on the Enable Function of a TO. When the selection is enabled, a motion command issued while the axis is already enabling (or has not finished its previous motion) is queued and dispatched only after the axis transitions to OPERATIONAL/ENABLED. When the selection is cleared, every motion command is fired immediately, regardless of axis state. This is documented in the SIMOTION Runtime Basic Functions manual section "Programming Execution System / Tasks / System Cycle Clocks".

On a five-axis system, two simultaneous enable calls — each followed immediately by a positioning command — generate two simultaneous TechnologicalFaultTask alarms. Because TechnologicalFaultTask is configured with a single alarm slot per default, the runtime registers too many interrupts and escalates to STOP. The diagnostic buffer shows a cascade of alarm 30002 entries followed by the STOP reason code.

3.1 The TechnologicalFaultTask Alarm Path

Unlike MotionTask or BackgroundTask, TechnologicalFaultTask is a priority task: it is triggered by alarms from TO axes, not by the cyclic IPO clock. The runtime allows only a limited number of pending alarm events per IPO cycle. If the number is exceeded, the controller transitions to STOP with the reason described above.

3.2 Why the Delay Mask Hides the Problem

The Delay program execution feature serializes motion commands through the TO's enable handshake. This coincidentally prevents two TechnologicalFaultTask interrupts from firing on the same cycle. The user observes the symptom only after disabling this serialization — the underlying issue (lack of pre-flight axis-state verification) is exposed.

4. Diagnosis Buffer Interpretation

Before changing any code, capture the full diagnostic buffer using SCOUT TIA:

1. Right-click the SIMOTION device → Online → Diagnostics.
2. Open the Diagnostic Buffer tab.
3. Filter for entries with type STOP and TechnologicalFaultTask.
4. Record the timestamps of each alarm 30002 entry.

A healthy trace should show one alarm per IPO cycle at most. A STOP-triggering trace will show N alarms clustered within a 1–4 ms window (one servo cycle), followed by the STOP entry. Typical cluster size matches the number of axes commanded simultaneously.

5. Solution 1 — Selective Re-Enable with Tuned Delay

The fastest mitigation is to keep the Delay program execution selection enabled, then reduce its side-effect latency by raising the issuing task's priority and shortening the IPO clock. In SCOUT TIA:

1. Open the TO configuration (e.g., ConvL1, ConvL2, …).
2. Select Function → Enable → Delay program execution and confirm the checkbox is ticked.
3. Open Execution System → Tasks and verify that motion commands are issued from MotionTask_1 or higher, not from BackgroundTask.
4. Reduce the IPO cycle to 2 ms (D425 DP/PN supports 1 ms minimum at 5 axes with PROFINET IRT).
5. Compile and download.

This restores stability but does not address the root cause: the user program still lacks pre-flight checks.

6. Solution 2 — Axis State Verification with TO System Variables

The recommended fix is to interrogate the axis state before issuing the next motion command. SIMOTION exposes a structured set of TO system variables per axis for exactly this purpose. Reference the SIMOTION TO System Variables manual for the full list; the most relevant ones for this fault are:

6.1 Structured Text (ST) Pattern

Place the gating logic in a MotionTask that runs once per IPO. The following snippet demonstrates safe multi-axis dispatch on a conveyor-like system:

// Multi-axis command dispatch with axis state gating
// Assumes TO names: ConvL1, ConvL2, ConvR1, ConvR2, AuxAxis

IF bStartSequence THEN
    bStartSequence := FALSE;
    
    // Gate 1: ensure all target axes are ENABLED and in STANDSTILL
    IF (ConvL1.operationalState = OPERATIONAL_STATE_ENABLED) AND
       (ConvL1.motionStateData.motionState = MOTION_STATE_STANDSTILL) AND
       (ConvL2.operationalState = OPERATIONAL_STATE_ENABLED) AND
       (ConvL2.motionStateData.motionState = MOTION_STATE_STANDSTILL) AND
       (ConvR1.operationalState = OPERATIONAL_STATE_ENABLED) AND
       (ConvR1.motionStateData.motionState = MOTION_STATE_STANDSTILL) THEN
        
        // Dispatch commands in fixed order; stagger if possible
        ConvL1._commandpos.velocity    := 1.0;
        ConvL1._commandpos.acceleration := 5.0;
        ConvL1._commandpos.deceleration := 5.0;
        ConvL1._commandpos.position     := lrTargetL1;
        ConvL1._commandpos.commandId    := 1;
        ConvL1._commandpos();
        
        ConvL2._commandpos.velocity    := 1.0;
        ConvL2._commandpos.acceleration := 5.0;
        ConvL2._commandpos.deceleration := 5.0;
        ConvL2._commandpos.position     := lrTargetL2;
        ConvL2._commandpos.commandId    := 1;
        ConvL2._commandpos();
        
        ConvR1._commandpos.velocity    := 1.0;
        ConvR1._commandpos.acceleration := 5.0;
        ConvR1._commandpos.deceleration := 5.0;
        ConvR1._commandpos.position     := lrTargetR1;
        ConvR1._commandpos.commandId    := 1;
        ConvR1._commandpos();
        
    ELSE
        // Defer and retry next IPO
        bStartSequence := TRUE;
        wRetryCounter  := wRetryCounter + 1;
        
        IF wRetryCounter > 50 THEN
            // Surface as a structured alarm for HMI
            _setAlarm(ALARM_SEQUENCE_NOT_READY, 0);
            wRetryCounter := 0;
        END_IF;
    END_IF;
END_IF;

6.2 MCC Equivalent

In Motion Control Chart (MCC), insert a Wait for Axis State block before each Positioning command and configure the condition as motionState == STANDSTILL. Chain the blocks with a single-cycle delay element to prevent two wait conditions resolving on the same IPO tick.

7. Solution 3 — Alarm 30002 Handling and Hiding

Alarm 30002 ("Axis command cannot be executed because axis is in a state that does not permit this command") is the alarm raised when a motion command is dispatched against a non-ready axis. The original poster chose to hide the alarm so that the TechnologicalFaultTask is not invoked. This silences the symptom but does not remove the root cause.

1. In SCOUT TIA, open Project → Alarms → Alarm Configuration.
2. Locate alarm 30002 and set its Reaction to HIDDEN for each affected TO.
3. Alternatively, configure a user-defined alarm handler in TechnologicalFaultTask that acknowledges the alarm without re-dispatch.

8. SCOUT TIA Configuration Reference

The operating-mode controls used for the diagnostic workflow are documented in the SIMOTION SCOUT TIA online help under Device Configuration → Getting Started → Run and Stop Operating Modes. Key procedural steps:

1. RUN/STOP toggle: Online → Control Operating Mode → select RUN or STOP.
2. Task configuration: Execution System tab → select TechnologicalFaultTask → set priority (default 14), monitoring time (default 5 s), and IPO cycle (default 4 ms).
3. TO enable: Open each TO → Function tab → confirm Delay program execution is set as required.
4. Alarm handling: Project tree → Alarms → Configure reactions per alarm code.

For full reference on task configuration and cycle-clock interaction, the SIMOTION Runtime Basic Functions PDF provides the canonical description of the execution system and alarm/task interaction model.

9. Recommended Approach for the Five-Axis System

For the original 5-axis topology, the recommended sequence is:

1. Re-enable Delay program execution on all five TO axes.
2. Add axis-state gating in the MotionTask before any positioning command (Section 6.1).
3. Stagger the IPO cycle assignments so that axes L1 and L2 issue commands on even IPO ticks, R1 and R2 on odd IPO ticks. This halves the simultaneous interrupt pressure on TechnologicalFaultTask.
4. Configure alarm 30002 as HIDDEN only after verifying the diagnostic buffer shows no further 30002 entries.
5. Monitor the _alarmState user-defined alarm counter on the HMI for one production shift before declaring the fix stable.

10. Verification Procedure

1. Compile and download the project to the SIMOTION D425.
2. Place the controller in RUN via the SCOUT TIA Control Operating Mode dialog.
3. Trigger the original fault scenario (two simultaneous enables followed by positioning commands).
4. Confirm the controller remains in RUN for at least 30 minutes of cyclic operation.
5. Capture the diagnostic buffer and verify no new alarm 30002 entries appear.
6. Trigger a deliberate axis fault (e.g., disable one drive via STARTER) and verify that the alarm is routed correctly without forcing STOP.
7. Measure motion-command latency with the trace tool to confirm the original latency concern is reduced to within one IPO cycle.

11. Troubleshooting Matrix

12. Firmware and Compatibility Notes

The TechnologicalFaultTask behavior described here is consistent across SIMOTION D425 firmware V4.4 through V5.4. The IPO cycle minimum on D425 DP/PN with five axes is 1 ms with PROFINET IRT and 2 ms with PROFIBUS DP. Alarm 30002 numbering and reaction handling are unchanged in this firmware window. SCOUT TIA V5.x and the successor SIMOTION Project Handler in TIA Portal V18/V19 expose the same alarm configuration; the workflow above is portable between them. Always consult the SIMOTION Runtime Basic Functions manual shipped with the specific firmware version in use for the definitive alarm list and reaction matrix.