Resolving SIMOTION D435-2PN STOP on TM15 DRIVE-CLiQ Startup

Problem Overview

The SIMOTION D435-2PN motion controller enters the STOP operating state on every cold start when one or more TM15 terminal modules are connected through DRIVE-CLiQ to the integrated Control Unit. The diagnostic buffer reports a peripheral fault because the SIMOTION user program begins to access TM15 I/O before the module has finished its DRIVE-CLiQ startup and synchronization phase. The same symptom is reported on D435-2 DP/PN variants, D445-2, D455-2, and the older D435 (non-2) when TM15 modules are used in fast-I/O (SIMOTION) mode.

The condition is not a configuration error in the strict sense – topology detection succeeds and the module is present. The fault is a temporal race between the SIMOTION runtime startup sequence and the TM15 firmware initialization, and it is aggravated when the application reads the I/O image inside the StartupTask or in a BackgroundTask that runs before the IO_module_Synchronized alarm is raised.

Hardware Identification

SIMOTION D435-2PN

The D435-2PN combines a SIMOTION runtime (kernel) and a SINAMICS S120 Control Unit on a single hardware platform. The "-2PN" suffix indicates two PROFINET interfaces. The relevant MLFB for the device in this scenario is:

The integrated CU provides the DRIVE-CLiQ ports that connect to the TM15 modules. Each TM15 occupies one DRIVE-CLiQ node. The TM15 is not a PROFINET device – it is a DRIVE-CLiQ device that is mapped into the SIMOTION I/O address space by the SCOUT / TIA configuration.

TM15 Module Variants

Two physical TM15 variants exist. Selecting the wrong type in the hardware catalog produces different runtime behavior and a different I/O image. The MLFBs are:

If the hardware catalog in SCOUT shows TM15 and TM15 (SIMOTION), you have the fast-I/O variant (6SL3055-0AA00-3FA0). If the catalog shows TM15 DI/DO, you have the standard variant. The alarm handling, the PeripheralFaultTask interaction, and the IO_module_Synchronized signaling differ between the two.

DRIVE-CLiQ Startup Sequence

When the SIMOTION D435-2PN is powered, the integrated CU executes a fixed sequence:

1. Power-on self-test of the CU hardware.
2. DRIVE-CLiQ discovery on each port – neighbors are detected and identified.
3. Component firmware check – the TM15 firmware version is read and compared against the configured version.
4. Topology comparison – the discovered topology is compared to the project configuration. A topology fault puts the CU into STOP immediately, but this is not the symptom described in this article.
5. I/O module configuration download – the configuration is pushed to each TM15.
6. TM15 internal initialization – the FPGA-based I/O logic configures, calibrates, and synchronizes to the SIMOTION cycle clock.
7. SIMOTION runtime starts the configured task system.
8. User program execution begins, including StartupTask, BackgroundTask, and any other tasks.

Steps 6 and 8 are not synchronous. The user program can begin executing I/O accesses before the TM15 reports ready. The PeripheralFaultTask is the only built-in mechanism SIMOTION provides to catch the fault and either retry, substitute a safe value, or signal back to the application that the I/O is not yet valid.

Root Cause of the STOP

The diagnostic buffer entry you observe is generated by the SIMOTION runtime when the user program attempts to read or write a TM15 I/O address that is not yet marked as valid in the peripheral state model. The SIMOTION kernel raises a peripheral access fault and, by default, this transitions the controller to STOP.

Three things contribute to the race:

1. DRIVE-CLiQ startup latency. TM15 firmware takes a measurable time to complete its internal sync. During this window, the I/O image is undefined.
2. No automatic gating of I/O access. SIMOTION does not delay the first task cycle waiting for I/O readiness. The first cycle runs as soon as the runtime is up.
3. ProjectGenerator gboStartupCheckOK does not include DRIVE-CLiQ I/O. The gboStartupCheckOK Boolean from the project generator's startup check function block is intended for SINAMICS drive readiness and for PROFINET IO devices, not for DRIVE-CLiQ-attached TM15 modules. The flag will not gate TM15 access.

Therefore, relying on gboStartupCheckOK to prevent early TM15 access is insufficient. The correct gate is either the PeripheralFaultTask mechanism or a polling check using the runtime I/O validity functions _GetSafeValue / _SetSafeValue.

Solution Architecture

Three independent, complementary mechanisms are available. Use them together for the most robust startup behavior:

1. Implement the PeripheralFaultTask and use the IO_module_Synchronized alarm to mark the TM15 as ready.
2. Use _GetSafeValue / _SetSafeValue to safely read/write I/O with an automatic safe-value fallback during the startup window.
3. Set the I/O module's startup behavior to ready after synchronization in the hardware configuration so that the runtime does not start the user tasks until the TM15 is synchronized (this is the cleanest solution when supported by the module variant and firmware).

PeripheralFaultTask Configuration

The PeripheralFaultTask is a system task in SIMOTION. It is configured in SCOUT (or TIA Portal with the SIMOTION option) under Project > System Tasks > PeripheralFaultTask. The task is invoked whenever the SIMOTION kernel detects a peripheral fault (read or write to an invalid I/O address).

Step-by-step in SCOUT

1. Open the SIMOTION project in SCOUT.
2. Select the D435-2PN device in the project navigator.
3. Open Execution system > System tasks.
4. Right-click PeripheralFaultTask and select Properties.
5. Set the task priority below your other tasks (priority 9 / 10 is typical – it must be lower than BackgroundTask so it does not pre-empt normal processing).
6. Assign the PeripheralFaultTask to a program – typically the same program organization unit (POU) that contains the StartupTask, or a dedicated alarm-handling POU.
7. Compile and download.

Inside the PeripheralFaultTask

Use the system function _readDriveFault / _readPeripheralFault (function block or system function depending on the runtime version) to identify the affected I/O address. Then map the address to the TM15 slot and confirm synchronization. The key bit of information is the alarm identifier: on a TM15 in SIMOTION mode, the runtime raises an alarm with the identifier IO_module_Synchronized (alarm number 0x0D000001 or as decoded by the alarm mechanism) that includes the logical I/O address of the module that has just completed synchronization. The PeripheralFaultTask can latch this state and clear it once the module is fully online.

IO_module_Synchronized Alarm

The IO_module_Synchronized alarm is generated by the SIMOTION kernel when a TM15 (in SIMOTION mode) has completed its DRIVE-CLiQ startup, downloaded its configuration, and locked to the SIMOTION cycle clock. The alarm carries the logical base address of the TM15 so that the application can identify which module is now ready.

In ST (Structured Text), latch this in a module-ready data structure:

// PeripheralFaultTask POU
// Latch the IO_module_Synchronized alarm for each TM15

FUNCTION_BLOCK fbTM15ReadyLatch
VAR
    aReady : ARRAY[1..8] OF BOOL;  // index = TM15 number
    iAlarmId : DINT;
    dwLogAddress : DWORD;
END_VAR

BEGIN
    // Read the current peripheral fault / alarm information
    iAlarmId := _getAlarmId();
    dwLogAddress := _getAlarmLogAddress();

    // IO_module_Synchronized alarm identifier
    IF iAlarmId = 16#0D000001 THEN
        // Map logical base address to TM15 index via configuration table
        CASE dwLogAddress OF
            16#0100: aReady[1] := TRUE;  // TM15 #1 logical base
            16#0200: aReady[2] := TRUE;  // TM15 #2 logical base
            // ... extend for each TM15 in the project
        END_CASE;
        _resetAlarm();
    END_IF;
END_FUNCTION_BLOCK

_GetSafeValue and _SetSafeValue

SIMOTION provides two system functions specifically for the case where I/O is not yet accessible:

Using these functions is the most defensive approach. The application code does not need to know whether the TM15 is online – it simply reads/writes with a safe fallback, and the safe value is configurable per channel.

Safe-value configuration

The default safe value is 0 for digital inputs and outputs. For digital inputs that are safety-relevant, set the safe value to 1 (e.g. emergency stop) so that the application behaves as if the safety chain is open until the real input is available. Configure the safe value in SCOUT under Properties of the I/O channel > Substitute value.

ProjectGenerator Startup Check

The project generator's startup check produces a Boolean gboStartupCheckOK that is set when the configured drives and PROFINET IO devices have signalled ready. It does not include DRIVE-CLiQ-attached TM15 modules. Therefore, gating I/O access on gboStartupCheckOK alone will not prevent the TM15 access race.

The correct composite gate for an application that uses both PROFINET IO and DRIVE-CLiQ TM15 is:

// Combined startup gate: drives + PROFINET IO + DRIVE-CLiQ TM15
FUNCTION_BLOCK fbApplicationReady
VAR
    bDrivesReady : BOOL;     // from gboStartupCheckOK
    bTM15Ready   : BOOL;     // from fbTM15ReadyLatch (latched on IO_module_Synchronized)
END_VAR

BEGIN
    bDrivesReady := gboStartupCheckOK;
    bTM15Ready   := fbTM15ReadyLatch.aReady[1] AND fbTM15ReadyLatch.aReady[2];
END_FUNCTION_BLOCK

Use the output of fbApplicationReady to gate the I/O processing section of the application.

Hardware-Level Configuration: Startup Behavior

In the SCOUT hardware configuration, the TM15 has a Startup behavior property with two options:

Set the TM15 to Ready after synchronization. This still does not prevent the PeripheralFaultTask from firing during the first few cycles if the user program accesses I/O before the sync completes, but it tightens the window significantly and combined with the PeripheralFaultTask it produces a clean startup.

Diagnostic Buffer Reference

The diagnostic buffer entries you will see during this fault are of the form:

To read the diagnostic buffer from SCOUT, select the D435-2PN device, right-click and choose Target system > Diagnostics > Diagnostic buffer. The buffer is time-stamped and shows the order of events – the IO_module_Synchronized alarm always appears after the peripheral fault entry on a troubled startup, which is the visible proof of the race condition.

Complete Implementation Example

The following is a working scaffold that combines all three mechanisms. Adapt the constants, the alarm identifier, and the logical addresses to match your specific project.

PROGRAM Main
VAR
    fbTM15Ready   : fbTM15ReadyLatch;   // latches IO_module_Synchronized
    fbAppReady    : fbApplicationReady; // combined gate
    bProcessIO    : BOOL;               // TRUE when safe to use TM15 I/O
    bDiSafe       : BOOL;               // safe value from _GetSafeValue
    bDiReal       : BOOL;               // real input from TM15 #1 byte 0 bit 0
    wDiMask       : WORD;               // bit mask for inputs of interest
END_VAR

BEGIN
    // 1) Latch TM15 readiness from the PeripheralFaultTask
    //    (fbTM15Ready.aReady[] is updated by the PeripheralFaultTask POU)

    // 2) Compute the combined application-ready gate
    fbAppReady();
    bProcessIO := fbAppReady.bDrivesReady AND fbAppReady.bTM15Ready;

    // 3) Process I/O only when the gate is TRUE
    IF bProcessIO THEN
        // Safe read – falls back to safe value during the window, no fault
        IF _GetSafeValue(ioTM15_1_Inputs := 16#0100, bValue := bDiReal) THEN
            // Real input was read; use bDiReal
        ELSE
            // Safe value returned; use bDiSafe
            bDiReal := bDiSafe;
        END_IF;

        // Safe write – never faults
        _SetSafeValue(ioTM15_1_Outputs := 16#0180, bValue := TRUE);
    ELSE
        // Not yet ready – do not access hardware I/O at all
        // Force outputs to their safe values via _SetSafeValue
        _SetSafeValue(ioTM15_1_Outputs := 16#0180, bValue := FALSE);
    END_IF;
END_PROGRAM

Verification Procedure

After applying the changes:

1. Save the project and download to the D435-2PN (SCOUT > Target system > Download).
2. Cold-start the machine (full power-down, then power-up).
3. Open the SCOUT online diagnostic buffer and confirm there are no peripheral fault entries for the TM15 logical address range.
4. Confirm that the IO_module_Synchronized alarm is present in the buffer and that fbTM15ReadyLatch.aReady[1] and aReady[2] go TRUE within the first second after power-up.
5. Confirm that the controller reaches RUN within the normal startup time and that the application processes I/O only after the gate is TRUE.
6. Repeat the cold start 5–10 times. The behavior should be consistent – no intermittent STOP.

Edge Cases and Field Notes

• Firmware mismatch. If the TM15 firmware version does not match the version declared in the SCOUT project, the CU raises a topology/configuration alarm and the TM15 will not come online. The IO_module_Synchronized alarm will not fire. Resolve by aligning the TM15 firmware with the version in the project (e.g. via SIMOTION IT web server or by the SD card / card image update procedure documented in the SIMOTION D4x5-2 manual).
• DRIVE-CLiQ cable hot-plug. If a TM15 is hot-plugged while the controller is in RUN, the same race can occur transiently. The same PeripheralFaultTask handling covers this case.
• Multiple TM15 modules in a daisy chain. TM15 modules do not have DRIVE-CLiQ pass-through ports. Each module occupies a dedicated port on the CU. Do not connect two TM15 modules to a single hub without using a DMC20 (DRIVE-CLiQ Hub Module) – the DMC20 also has a startup time, and modules behind it will be later still.
• TM15 DI/DO versus TM15 (SIMOTION). The standard TM15 DI/DO does not raise IO_module_Synchronized in the same form. For that variant, gate access purely on the peripheral-validity flag returned by _GetSafeValue, or use a startup delay task that holds off I/O processing for a fixed number of cycles (typically 3–5 cycles at 1 ms each is enough).
• Project generator's gboStartupCheckOK. The flag will go TRUE on its own schedule (drives and PROFINET IO). It is not delayed by the TM15. Use it as part of the gate, but do not rely on it alone.

Troubleshooting Matrix