Resolving SIMOTION D Technology Fault Task Buffer Overflow

Problem Overview

A SIMOTION D motion controller configured as a PROFINET I-Device with PROFIsafe coupling to a SIMATIC S7 F-CPU and SINAMICS S120 integrated drives can transition to STOP shortly after power-up or after a SIMOTION project download. The SIMOTION diagnostic buffer shows a technology fault task (MotionTask / TaskFault) message buffer overflow, with the overflow being driven by drive-side alarms on the SINAMICS side, typically reported as "Fault in the drive on the log address Exx". Because no automatic alarm acknowledgement or reset is configured, the buffer accumulates more fault entries than the configured technology alarm queue can hold, and the controller stops rather than continuing to RUN.

The failure pattern is consistent:

• SINAMICS drives (or the SINAMICS Integrated of the SIMOTION D) power up more slowly than the SIMOTION controller itself.
• During the SIMOTION startup, the controller tries to communicate with the drives and with the F-CPU before the SINAMICS PROFINET interface is ready.
• The PROFIsafe slot reports F_HOST_FLOOR or F_CRC_FAIL-class responses, which SIMOTION surfaces as technology alarms.
• Each re-attempt to read or write F-IO adds another alarm to the TaskFault queue. When the queue depth is exceeded, SIMOTION raises alarm 50005 / 50006 (message buffer overflow) and goes to STOP.

This is a startup-time race condition, not a steady-state hardware fault. The same line can run for months once both controllers and drives have stabilised; the STOP recurs only on cold start or on SIMOTION project download (where the PROFINET connection to the S7 F-CPU is momentarily torn down and re-built).

Root Cause Analysis

Three underlying conditions combine to produce the message buffer overflow:

1. Asymmetric startup timing of SINAMICS versus SIMOTION

SIMOTION D completes its own boot (BIOS, firmware, runtime, topology scan) significantly faster than the SINAMICS S120 drive line-up finishes its own ramp-up, parameter load, and PROFINET identification. The SINAMICS integrated in a SIMOTION D4x5 typically needs 20-40 s from power-on until the cyclic PROFINET data exchange is healthy; external SINAMICS S120 booksize/blocksize units with CBE20 PROFINET boards can take 30-60 s depending on the configured DRIVE-CLiQ topology and the number of Motor Modules.

2. Technology fault task queue depth vs. F-IO poll rate

The technology fault task has a finite number of message slots. The default configuration reserves only a small number of alarm entries for "drive not reachable"-class events. The first time SIMOTION calls the PROFIsafe telegram processing (via the safety slot mapped in the I-Device interface), the SINAMICS side answers with a non-OK F-host status. SIMOTION raises one alarm. The next background cycle raises another. With PROFIsafe slot replacement in progress, the alarms can arrive faster than the application task can clear them.

3. No alarm filter on F-host communication errors

By default, the alarm configuration in the SIMOTION project escalates every drive-side F-host failure into the technology fault task. There is no native "do not escalate F-host startup errors to the technology fault task" checkbox; the escalation path is the only one available. The only way to keep these events out of the TaskFault queue is to either prevent them from being generated (by waiting for SINAMICS to be ready) or to filter the alarm source at the SIMOTION alarm handler.

Result: TechnologyFaultTask alarm queue overflow → SIMOTION STOP reaction. A short, well-defined sequence in the startup task breaks the chain.

Affected Products and Versions

The behaviour is observed on the following hardware/runtime combinations. Confirm you are on a firmware where the workaround is supported.

Reference manuals: SIMOTION D4x5-2 Commissioning and Hardware Installation Manual, SIMOTION D4x5-2 Manual, Edition 12/2016, and the SIMOTION Communication System Manual.

Diagnostic Procedure

Before changing the program, capture a complete diagnostic dump so the actual alarm class and source are confirmed. Do not assume the alarm is what the field reports.

Step 1 - Export the SIMOTION diagnostic buffer

In SCOUT / TIA Portal (with SIMOTION option), connect online to the SIMOTION D, right-click the device → Diagnostics → Diagnostic Buffer. Save the buffer as a CSV and look for the recurring sequence:

Entry 50102  TaskFault  message buffer full  ... Entry 50005  Drive  F-host  log addr E05 ... Entry 50005  Drive  F-host  log addr E05 ... Entry 50005  Drive  F-host  log addr E05 ... Entry 50103  TechnologyFaultTask overflow -> STOP

The number of "Drive F-host" entries before the overflow tells you the effective queue depth. Typical values are 8-16 entries. If you see more than 30 before the overflow, you may have a real drive problem rather than a startup race.

Step 2 - Identify the source log address Exx

The log address corresponds to a PROFINET slot in the SIMOTION I-Device interface. In SCOUT the address is visible under PROFINET IO → SIMOTION-D → Slot list. Cross-reference with the F-host configuration in the S7 F-CPU's hardware configuration. Slots in the 0x0000-0x00FF range are device-level; 0x0100-0xFFFF are subslot-level (where PROFIsafe typically lives). Example mapping seen in the field:

Step 3 - Check the alarm configuration in SCOUT

Open Project → Alarms → Alarm Configuration in SCOUT. The relevant columns are:

• Alarm class - must be set to a non-STOP class (e.g. Warnings or Messages) for F-host startup events. The default is often Faults, which escalates to TaskFault.
• Acknowledgement - if set to Power On, every restart will re-fire pending entries. Switch to Reset by program and acknowledge explicitly in the startup task.
• Task assignment - confirm that the F-host alarm source is not forced into TechnologyFaultTask. Move it to a background task if the application allows it.

Step 4 - Confirm the SINAMICS side has finished startup

From the S7 F-CPU side, evaluate the F-host status word (typically byte 1 of the F-IO status). A non-zero QBAD flag means the slot is not yet valid. The SINAMICS drive object LED states and the drive parameter r0002 (drive state) should be checked; it must show Operation - enable possible (state 4) or higher before SIMOTION's technology fault task is allowed to use the slot.

Solution: Startup Synchronization with _getSafeValue

The proven field fix is to gate the safety I/O consumption in the SIMOTION StartupTask until all required SINAMICS objects have reached a usable state. Use the SIMOTION system function _getSafeValue() inside a poll loop, with a bounded retry counter, so that the technology fault task is never entered while F-IO is still uninitialised.

Prerequisites

• SCOUT / TIA V18 or later, with the SIMOTION option pack installed.
• F-library for SIMOTION (F-Safety blocks for SIMOTION) imported into the project.
• Technology fault task assigned, and the application StartupTask declared with a longer watchdog (see SIMOTION SCOUT Programming and Operating Manual).
• Knowledge of the configured safety I/O addresses and the F-host slot list from the S7 F-CPU hardware configuration.

Implementation

Add the following logic to the project's StartupTask (ST or MCC). The example is in Structured Text for SIMOTION V5.x:

// Startup synchronization - wait for F-IO availability
// Avoid TaskFault message buffer overflow caused by SINAMICS startup delay

VAR
    nWaitTicks   : DINT := 0;        // counter for wait loops
    nMaxWait     : DINT := 600;      // 600 * 100ms = 60s budget for SINAMICS
    bFioReady    : BOOL := FALSE;
    stFStatus    : STRUCT
        bQBad  : BOOL;
        bPass  : BOOL;
        wCRC   : WORD;
    END_STRUCT;
END_VAR

// Step 1: poll SINAMICS drive state via standard PROFINET slot
// (read the standard telegram status word of the drive object)
WHILE (nWaitTicks < nMaxWait) AND (NOT bFioReady) DO
    // Read F-host status for each configured safety slot
    _getSafeValue(
        ioId       := to_SafetyIOId('FModule_Axis1'),
        subslot    := 1,
        status     := stFStatus,
        retVal     := stRetVal);

    IF (stRetVal = 0) AND (NOT stFStatus.bQBad) AND stFStatus.bPass THEN
        bFioReady := TRUE;
    ELSE
        // Delay 100 ms and re-try. Use a background-task tick counter
        // so StartupTask watchdog is not exhausted.
        nWaitTicks := nWaitTicks + 1;
        TaskDelay(time := T#100ms);
    END_IF;
END_WHILE;

IF NOT bFioReady THEN
    // F-IO did not come up in the budget window.
    // Log a controlled message, do NOT raise a drive alarm that
    // would land in TaskFault.
    _alarmHdlCreate(sAlarmId := 50010,
                    sSeverity := _ALARM_WARNING);
    // Stay in startup - do not return. Operator must intervene.
    RETURN;
END_IF;

// Step 2: clear any pre-existing F-host alarms that piled up
// during the wait loop. These are the entries that would
// otherwise overflow TaskFault.
FOR i := 1 TO 16 DO
    _alarmHdlClear(sAlarmId := 50005 + i);
END_FOR;

// Step 3: only now let MotionTasks start consuming F-IO
// Set a project flag the BackgroundTask and MotionTask check.
bSafetyIOAvailable := TRUE;

The wait loop calls _getSafeValue() from the F-Safety library for SIMOTION. The function returns the F-host status bits without raising an alarm when the slot is not yet valid, which is exactly what is needed: it lets the application observe the slot state without generating a new TaskFault entry on every poll. Reference: SIMOTION SCOUT Programming and Operating Manual, Edition 06/2019, section "Safety system functions".

Alternative: Mask the alarm source temporarily

If a code change is not possible, the alarm configuration can be changed so that the F-host alarm source does not escalate to the technology fault task during the startup phase. This is less robust than the _getSafeValue() approach but is a valid fallback.

1. Open Alarm Configuration in SCOUT.
2. Filter on alarm class Faults, source Drive F-host.
3. Change task assignment from TechnologyFaultTask to BackgroundTask.
4. Set the alarm acknowledgement to Reset by program.
5. Add a short ST snippet in BackgroundTask that calls _alarmHdlClear() for the relevant alarm IDs as soon as the F-host is healthy.

Be aware that this also masks genuine drive F-host failures during normal operation. Use only as a stop-gap until the code-level fix is rolled out.

PROFINET I-Device and PROFIsafe Configuration Checks

Beyond the runtime fix, several configuration items in the S7 F-CPU hardware configuration and in the SIMOTION I-Device setup reduce the frequency of F-host startup alarms at their source.

Reference: SIMOTION Communication System Manual, section "PROFINET IO with I-Device", and the SIMOTION D4x5-2 Manual, section "Commissioning with PROFIsafe".

Technology Fault Task Queue Tuning

The default task configuration allocates a conservative number of alarm entries to TechnologyFaultTask. The queue depth is project-configurable and is sometimes set incorrectly in a copy-paste of an older project. Review these parameters in SCOUT under Project → Tasks → TechnologyFaultTask:

Verification

After applying the fix, perform a worst-case verification - the same conditions that originally triggered the STOP.

1. Power cycle the line with SINAMICS, SIMOTION D, and S7 F-CPU all de-energised for at least 30 s.
2. Power the SINAMICS line-up first; wait for the SINAMICS Ready LED to be solid green on every Motor Module.
3. Power the SIMOTION D and the S7 F-CPU in the same sequence as production.
4. Watch the SIMOTION StartupTask in online mode: the wait loop should be visible, iterating at 100 ms per loop. A typical SINAMICS S120 line-up converges in 8-25 s.
5. Confirm that no 50005-class "Drive F-host" alarms are written to the technology fault task buffer.
6. Confirm that no 50006 / 50103 "message buffer overflow" entries appear.
7. Perform an S7 F-CPU STOP/RUN while SIMOTION is in RUN, and a SIMOTION project download while the S7 F-CPU is in RUN. Both scenarios previously triggered the STOP; both should now complete without a buffer overflow.
8. Repeat the cold-start sequence at least 10 times. Random timing can hide a marginal fix; the issue must be reproducible with no fault entries.

Related SIMOTION Alarms

Troubleshooting Matrix

Edge Cases and Field Notes

• Multiple SINAMICS line-ups behind one SIMOTION D: the wait budget must cover the slowest Motor Module, not the average. A 60 s budget is a safe default for two or three line-ups; a single CU320-2 with one line-up typically converges in < 15 s.
• Hot restart of the S7 F-CPU: the F-host slot state transitions to invalid for 1-2 PROFINET cycles. If the application reads the slot during that window, the alarm is generated. The startup-flag gating must remain in effect for the entire controller life, not only at first power-up.
• SIMOTION P320-3 (PC-based): the same alarm IDs apply, but the underlying PROFINET stack is the CP1616 board. Apply the same _getSafeValue() approach; the wait budget is typically shorter because the PC's Windows boot dominates anyway.
• Replacement of an S7 F-CPU: a new F-CPU has a different PROFIsafe address by default. Confirm that the address matches what is configured in SIMOTION's F-host slot, or the CRC alarms will never clear.
• F-library version: the _getSafeValue() signature differs between the F-library V1.x (SIMOTION V4.4) and the F-library V5.x (SIMOTION V5.x). Verify the function signature against the installed library version.