Resolving SIMOTION F360:B180 Technological Alarm Buffer Overflow

Resolving SIMOTION F360:B180 Technological Alarm Buffer Overflow on SIMOTION D

SIMOTION motion controllers (SCOUT / TIA-based engineering) emit a specific diagnostic event, 16# F360:B180, when the runtime can no longer queue technological alarms and warnings. The diagnostic buffer saturates because alarms are being created and acknowledged faster than the runtime can drain them, and the controller responds by transitioning to STOP. This reference walks through the exact decode of the event, the underlying anti-pattern that generates it, and the corrective engineering pattern required on a SINAMICS DCM drive system connected over PROFIBUS.

1. Problem Definition

The diagnostic buffer is the SIMOTION equivalent of the S7-1500 diagnostic event queue referenced in the SIMATIC ET 200AL equipment manual: when a new diagnostic event cannot be queued because the buffer is full, the runtime escalates and may shut down the controller.

2. Decoding Z1 / Additional Information

SIMOTION uses the German term Zusatzinformation (additional information), abbreviated Z1 through Z5 in the help system and trace dumps. They appear in:

• SCOUT diagnostic buffer (online → Target system → Diagnostic buffer)
• The diagnostic.xml file generated by the SIMOTION device trace
• The online help for the event ID (F1 on the entry)
• System event logs exported with Save service data

For 16# F360:B180, the relevant Z field is Z1 (Additional Information 1). Reading it as a 32-bit word gives:

Z1 = 16# 0004 0000
         ^^^^
         <--- relevant byte-pair  (Bits 16-31)

The upper half-word contains the qualitative reason code. The values currently documented for the F360:B180 Z1 field are:

A Z1 of 0004 is the smoking gun: the user program is creating and clearing technological alarms in a tight cycle inside the TecFault task.

3. Root Cause Analysis

SIMOTION organizes execution into a hierarchy of tasks. The two tasks relevant to alarm handling are:

Acknowledging the very alarm that triggered the TecFault task creates a re-entrant fault cycle:

1. DCM drive raises alarm (e.g., 20005 Torque/Force Limit Exceeded) over PROFIBUS.
2. SIMOTION runtime queues the alarm in the technological alarm buffer.
3. TecFault task fires; user program executes _mc_reset / acknowledgeAlarm.
4. Acknowledgment empties the alarm buffer slot and immediately re-queues the same alarm (because the underlying drive state has not changed — OFF3 was just commanded).
5. Within the same TecFault execution the alarm is queued again, then acknowledged again, repeatedly, faster than the buffer can drain.
6. Buffer overflow event F360:B180 is raised with Z1=0004.
7. Runtime enforces the configured STOP reaction and brings the CPU down.

4. The TecFault Acknowledge Anti-Pattern

The common code that produces this failure looks like the example below. It is structurally identical to the pattern documented as invalid in the SIMOTION SCOUT programming manual:

// TecFaultTask - INVALID PATTERN
IF (alarmIsPending(20005)) THEN
    _mc_reset(axis := DCM_Axis_1);   // WRONG: in TecFault context
    _mc_power(axis := DCM_Axis_1, enable := TRUE);
END_IF;
IF (alarmIsPending(20005)) THEN
    _mc_reset(axis := DCM_Axis_2);   // WRONG: re-entrant
    _mc_power(axis := DCM_Axis_2, enable := TRUE);
END_IF;
// ... repeated for 3 more axes

Why this fails:

• The TecFault task runs once per pending technological alarm; acknowledging the same alarm inside it triggers another TecFault firing for the same axis.
• Resetting and re-powering inside TecFault does not give the DCM time to clear the underlying PROFIdrive state word bits (e.g., bit 3 Fault present, bit 7 Warning present).
• The OFF3 (fast stop) you commanded through the drive direct word is racing with the SIMOTION enabling block, generating repeated 20005 entries.

5. The Correct Acknowledge Pattern

Move the acknowledgment out of TecFault and into a MotionTask (preferred) or BackgroundTask. The TecFault task should only observe and set flags.

// TecFaultTask - VALID PATTERN
IF (alarmIsPending(20005, DCM_Axis_1)) THEN
    gDcmAxis1ResetRequest := TRUE;
END_IF;
IF (alarmIsPending(20005, DCM_Axis_2)) THEN
    gDcmAxis2ResetRequest := TRUE;
END_IF;
// (continue for axes 3 and 4)

// BackgroundTask - VALID PATTERN
IF (gDcmAxis1ResetRequest) THEN
    gDcmAxis1ResetRequest := FALSE;
    _mc_reset(axis := DCM_Axis_1);
    _mc_power(axis := DCM_Axis_1, enable := TRUE);
END_IF;
IF (gDcmAxis2ResetRequest) THEN
    gDcmAxis2ResetRequest := FALSE;
    _mc_reset(axis := DCM_Axis_2);
    _mc_power(axis := DCM_Axis_2, enable := TRUE);
END_IF;
// (continue for axes 3 and 4)

Why this works:

• The TecFault task fires once, raises the flag, and returns — the runtime can drain the alarm buffer.
• The BackgroundTask runs at its configured cycle (e.g., 10 ms), giving the DCM drive a full PROFIBUS cycle to actually clear the fault bit before reset is re-attempted.
• Each axis gets one reset attempt per BackgroundTask pass, eliminating the create-acknowledge loop.

6. Resolving the OFF3 / Enabling Block Conflict on DCM Drives

Driving OFF3 directly into the SINAMICS DCM control word while the SIMOTION _mc_power enabling block still holds the axis in Operation Enable produces a continuous 20005 (Torque/Force Limit Exceeded) storm. Both sources are commanding motion behavior:

Correct approaches (pick exactly one, never combine):

1. Drive OFF3 through the SIMOTION axis object: use the standard _mc_stop with stopMode = EMERGENCY_STOP. SIMOTION sets OFF3, ramps the setpoint, and clears the enabling in a coordinated handshake.
2. Drive OFF3 from the safety circuit only: route OFF3 via PROFIsafe or hardwired F-DI to the drive terminals; ensure the SIMOTION _mc_power enable is dropped simultaneously through a separate _mc_power(enable := FALSE) in the safety-related task.
3. Avoid direct OFF3 over PROFIBUS to a SIMOTION-controlled axis: this is the failure pattern in the source. SIMOTION expects to be the master of the enable state machine.

Recommended MCC / ST snippet for a SIMOTION-driven DCM axis fast stop:

// FastStop input from HMI or safety circuit
IF (gFastStopRequest) AND (NOT gFastStopActive) THEN
    gFastStopActive := TRUE;
    // Disable power first so SIMOTION stops demanding torque
    _mc_power(axis := DCM_Axis_1, enable := FALSE);
    // Then command drive-side fast stop ramp
    _mc_stop(axis := DCM_Axis_1, 
             deceleration := 5000.0, 
             jerk := 10000.0);
END_IF;

IF (axisState = STANDSTILL) AND (gFastStopActive) THEN
    gFastStopActive := FALSE;
END_IF;

7. Alarm Masking Strategy for 20005 and Similar

Alarm 20005 (Torque/Force Limit Exceeded) cannot be globally masked off in SIMOTION because it carries diagnostic information that the runtime uses to enforce the axis state machine. What can be done:

8. Buffer Sizing and Configuration Changes

The technological alarm buffer is sized by the alarm queue depth in the SIMOTION device configuration:

If you must keep the default buffer size, ensure the acknowledged-alarm rate stays below queue depth / PROFIBUS cycle — e.g., 64 entries / 4 ms = 16,000 acknowledgments per second maximum sustained, which a re-entrant TecFault loop easily exceeds.

9. Verification Procedure

1. Connect SCOUT online to the SIMOTION D controller.
2. Open Target system → Diagnostic buffer and clear it.
3. Trigger the previously failing scenario (OFF3 with enabling active).
4. Confirm F360:B180 does not appear in the diagnostic buffer within 60 s.
5. Open Task trace and confirm TecFault fires only once per drive alarm, not in a continuous loop.
6. Open Alarm history and confirm 20005 appears once per actual drive-side event, not in a tight burst.
7. Confirm SIMOTION remains in RUN after the test scenario.
8. Force a stop / start cycle, repeat the scenario five times, confirm zero F360:B180 entries.

10. Troubleshooting Matrix

11. Related Event IDs to Watch