Resolving SINUMERIK D410 Stop Mode After Power Restart

1. Problem Summary

The SINUMERIK 840D sl D410 controller enters STOP after a power-on restart even though the CPU "Startup when target system starts" parameter is set to RUN. The controller briefly transitions to RUN at the end of its boot sequence, executes a portion of the user program, and then drops back to STOP when a non-valid I/O access is detected. Operators can force the PLC back to RUN by toggling the mode selector switch (DIP 2, or DIP 2+3 in OFF→ON transition), but this is a manual workaround, not a fix. The fault returns on every cold start until the underlying I/O validity problem is eliminated.

The behavior is symptomatic of a Profibus slave that has not yet completed initialization when the PLC main scan reaches a direct I/O read or write. Common triggering conditions include:

• An external PLC (e.g., SIMATIC S7-300/S7-400) on Profibus-DP that has a longer power-up time than the D410.
• A Profibus slave that has lost its configuration and is briefly unreachable during re-parameterization.
• A safety-related I/O module (ET 200S, ET 200pro, SINUMERIK MCP, SINUMERIK PP) that is reset when the D410 re-initializes the bus.
• A SINUMERIK operator panel (OP 010, OP 012, OP 015, TP 015A) whose Profibus interface takes several seconds to come online.

When the PLC executes an instruction such as L IW 64 or T QW 0 against an input or output byte that does not have a valid physical source, the operating system raises a "Peripheral I/O access error" and forces the CPU into STOP. Safety-related programs in the D410 that use the SPL (Safety Programmable Logic) need defensive access patterns because the safety runtime is stricter than the standard PLC about reporting I/O faults and may transition the system to a stop state when an invalid F-I/O is read.

This article documents the root cause analysis, the diagnostic steps, the proper use of the safety I/O access functions _getSafeValue and _setSafeValue, the relevant diagnostic buffer event codes, and a sample program for handling the I/O validity window during Profibus startup.

2. SINUMERIK D410 System Architecture

The D410 is a compact member of the SINUMERIK 840D sl product family. It pairs a numerical kernel (NCK) with an integrated SIMATIC PLC, an SPL runtime for Safety Integrated, and a Profibus-DP master for distributed I/O. From the PLC programmer's perspective, the D410 behaves like a SIMATIC S7-300 CPU (PLC 317 derivative) with the following characteristics relevant to startup behavior:

The D410 powers up, brings the NCK online, then runs the PLC firmware, then loads and executes OB100 (warm restart) followed by OB1 (main cyclic). The SPL runtime initializes the F-runtime group configuration and the F-I/O modules at the end of the boot sequence. Profibus slaves are parameterized and queried in parallel with the SPL initialization; the slave handshake and parameterization can take several seconds on a fully loaded bus. The boot timing is documented in the SINUMERIK 840D sl Programming Manual on the Siemens Industry Online Support portal (support.industry.siemens.com).

Two important consequences follow from this boot order:

1. The PLC main scan starts before the Profibus slaves have completed their parameterization. Any direct I/O access in OB1 or OB100 that targets a Profibus I/O address may execute before the slave is online.
2. The SPL runs concurrently with Profibus startup but applies stricter validity checks on F-I/O. If a safety function in the SPL reads a safe input before the F-I/O module is reachable, the SPL raises a safety error and the system handles it according to the configured stop category (full shutdown or controlled stop).

Both effects combine to produce the reported symptom: the CPU reaches RUN, executes OB1 for one or two cycles, and then drops to STOP when an I/O access hits a slave that is not yet live. The fault entry in the diagnostic buffer at the reported timestamp (e.g., 12:24 in the example) is recorded with the exact event ID for the failed I/O access, allowing direct correlation with the user program line that triggered the STOP.

3. Root Cause: Direct I/O Access to Unavailable Profibus Slave

The diagnostic buffer entry "Error occurred while reading a system or I/O variable" combined with "access a non valid I/O" is the canonical signature of a direct I/O read or write against an address whose underlying slave is not yet in data exchange. The PLC firmware raises this event and immediately drives the CPU to STOP unless the user program uses one of the supported defensive access mechanisms.

The PLC and the SPL behave differently with respect to non-valid I/O:

The process image is refreshed at a fixed time in the PLC cycle (after OB1 input image update, before the next OB1 output image write). It only contains data from slaves that successfully completed the last DP cycle. Accessing the PI instead of the direct I/O address is the simplest mitigation: if the slave is offline, the PI simply returns the last known value, and the PLC does not go to STOP. The trade-off is that stale data must be handled by the application logic.

For safety-related I/O, the F-runtime provides two purpose-built functions: _getSafeValue and _setSafeValue. These functions return a boolean validity flag in addition to the value, allowing the SPL to detect that an F-I/O is unavailable and react accordingly. The function signatures and usage are described in detail in Section 6.

4. Configuration: CPU Startup Mode Parameter

The "Startup when target system starts" parameter (sometimes labeled "Startup on target system" or "Remanent startup") controls whether the PLC enters RUN or remains in STOP after a power-on. In SCOUT (or SCOUT TIA), this parameter is set in the CPU properties of the D410 project:

1. Open the D410 project in SCOUT.
2. Navigate to the PLC station (e.g., D410 [PLC 317]) in the project tree.
3. Right-click the CPU and select Properties.
4. Open the Startup tab.
5. Set Startup when target system starts to Warm restart (RUN).
6. Confirm with OK and recompile the project.
7. Download the hardware configuration to the D410.

If the parameter is correctly set and the PLC still drops to STOP, the parameter is not the source of the problem. The PLC firmware obeys the parameter, transitions to RUN, and is then forced back to STOP by a runtime event. Confirming this requires checking the diagnostic buffer (see Section 8) for the event that triggered the second transition.

Note that the "Startup when target system starts" parameter only governs the first transition after power on. Any subsequent transition to STOP is driven by the PLC operating system in response to a runtime fault (e.g., I/O access error, programming error, OB not loaded). The diagnostic buffer is the only place where the second transition is recorded with its triggering event.

5. Front-Panel Mode Selector and DIP Switch Behavior

The D410 front panel includes a mode selector with positions for RUN, STOP, and MRES (memory reset), and a bank of DIP switches that override and augment the mode selector. The DIP switch assignment for the D410 PLC follows the SIMATIC S7-300 convention used by the integrated PLC 317:

The user-reported procedure (DIP 2, or DIP 2+3, OFF→ON transition) is the documented SIMATIC S7 "manual restart" sequence:

1. Set the mode selector to STOP.
2. Toggle DIP 2 from OFF to ON (or DIP 2+3 together, depending on the firmware).
3. Hold for one second; the PLC enters MRES mode briefly, then returns to RUN.
4. Return the mode selector to RUN for normal operation.

This sequence clears the OB1 cycle and re-initializes the PLC scan without a power cycle. It does not fix the underlying I/O validity problem; it just gives the DP bus more time to come online before the next OB1 access. A hardware fix or program change is required for a permanent resolution.

6. Safe I/O Access Functions: _getSafeValue and _setSafeValue

The SINUMERIK D410 SPL runtime provides two purpose-built functions for accessing safe I/O with explicit validity reporting. Both functions are documented in the SINUMERIK 840D sl Safety Integrated programming manual and in the SCOUT help system under "F-runtime library".

6.1 _getSafeValue

Reads a safe input and returns both the value and a boolean validity flag. The function signature is:

BOOL _getSafeValue(
    in     : BOOL,   // safe input address
    bRetVal: BOOL    // validity flag (TRUE = valid, FALSE = invalid)
);

Usage in Structured Text (ST) inside an F-runtime group:

VAR
    bEStopActive   : BOOL;
    bEStopValid    : BOOL;
END_VAR

// Read the emergency-stop safe input
bEStopActive := _getSafeValue(in := E_StopInput, bRetVal := bEStopValid);

// React to validity: treat invalid input as fail-safe
IF NOT bEStopValid THEN
    bEStopActive := TRUE;   // fail-safe default
END_IF;

6.2 _setSafeValue

Writes a safe output and returns a boolean status indicating whether the write was accepted by the F-I/O module. The function signature is:

BOOL _setSafeValue(
    out    : BOOL,   // safe output address
    in     : BOOL,   // value to write
    bRetVal: BOOL    // write status (TRUE = accepted, FALSE = rejected)
);

Usage in ST:

VAR
    bRelayEnable   : BOOL;
    bWriteOK       : BOOL;
END_VAR

// Drive the safety relay only if we have a valid request
bRelayEnable := (sRequestValid AND bRequestSet);
bWriteOK := _setSafeValue(out := SafetyRelayOutput, in := bRelayEnable, bRetVal := bWriteOK);

IF NOT bWriteOK THEN
    // Log safety event; do not retry in tight loop
    SafetyEventLog := SafetyEventLog + 1;
END_IF;

6.3 Why Direct Access Fails

If a standard LAD/FBD/STL instruction such as A I 16.7 or = Q 8.0 is used inside the SPL against a safe I/O address, the F-runtime reports the access as a programming error if the F-I/O is not parameterized. The runtime then calls the configured stop category routine (typically OB82, OB86, or the F-stop OB) and the CPU goes to STOP. The defensive functions _getSafeValue and _setSafeValue allow the safety program to continue execution in a defined safe state (fail-safe value) rather than triggering a stop.

For non-safety I/O, the equivalent defensive pattern is to read from the process image (EW / AW in German notation) instead of the peripheral (PEW / PAW). The PI retains the last valid value across offline periods and does not cause a CPU STOP.

7. Profibus Slave Initialization Race Condition

The most common underlying cause of the reported symptom is a Profibus slave that has a longer power-up time than the D410. Typical examples:

• An external S7-300/S7-400 CPU on the same Profibus-DP segment, which holds the bus during its own OB100/RESTART execution.
• A SINUMERIK HMI (OP/TP) that needs 5-10 seconds to mount its flash filesystem before joining the DP cycle.
• An ET 200S station with F-I/O modules that need extra parameterization rounds after power-up.
• A drive (Sinamics S120, Simodrive 611) on the same Profibus whose Profidrive telegram handler is gated by the drive controller's own boot.

The race condition manifests as follows:

1. D410 powers on, NCK starts.
2. D410 PLC firmware starts OB100 within ~1 second.
3. OB100 completes; OB1 begins.
4. OB1 executes a direct I/O access (e.g., L IW 64). The targeted slave is not yet in data exchange.
5. PLC firmware raises "Peripheral I/O access error" and forces STOP.

7.1 Mitigations

Three mitigations, in order of preference:

1. Use the process image for all non-safety I/O in OB1. PI access does not stop the CPU; it returns the last valid value until the slave comes online.
2. Use _getSafeValue / _setSafeValue for all F-I/O in the SPL. Apply fail-safe defaults when the validity flag is FALSE.
3. Defer direct I/O access to a later OB (e.g., OB35 cyclic interrupt at 100 ms) that begins execution after the typical DP parameterization window. This is a workaround; it does not eliminate the race on cold days or with degraded slaves.

Additional DP-side mitigations include configuring the slaves for "DPV1" parameterization with a longer monitoring time (e.g., increasing the DP watchdog from the default 100 ms to 1000 ms in HW Config), and verifying that the Profibus connector and cable integrity are within spec. Long cables, missing terminators, and excessive stub lengths can extend parameterization time and surface as transient I/O access errors.

8. Diagnostic Buffer Interpretation

The SCOUT diagnostic buffer is the single most valuable tool for diagnosing the reported symptom. To open the buffer, connect to the D410 with SCOUT, right-click the PLC station, and select PLC > Diagnostic Buffer (or press Ctrl+D). The buffer is a chronological list of events; the most recent events are at the top.

Key event IDs to look for in the buffer (in S7-300/400 hex format, applicable to the integrated PLC 317):

For the reported case, the relevant sequence in the buffer is:

1. Power-on event (timestamp 12:07:xx).
2. Startup completed, CPU in RUN (event 0x113F).
3. OB1 begins, scans the user program.
4. Peripheral I/O access error (event 0x39xx with detail "non-valid I/O at byte X").
5. CPU transitions to STOP (event 0x4301).

The event detail field contains the exact I/O byte that failed. Open the detail by double-clicking the event, then record the byte number, slot, and rack. This identifies the user program line that must be rewritten to use the process image or the safe I/O access functions.

9. Sample SPL Program: Defensive I/O Access

The following Structured Text (ST) sample shows the recommended defensive pattern for an F-runtime group in the D410 SPL. It reads an emergency-stop safe input and a safety door switch, with fail-safe defaults when the F-I/O is not yet available.

FUNCTION_BLOCK FB_SafetyInputScan
VAR
    bEStopActive     : BOOL;
    bEStopValid      : BOOL;
    bDoorClosed      : BOOL;
    bDoorValid       : BOOL;
    bAllSafe         : BOOL;
    sDiagBuf         : ARRAY[1..32] OF BYTE;
END_VAR
BEGIN
    // Read safe inputs with validity check
    bEStopActive := _getSafeValue(in := I_F_EStop, bRetVal := bEStopValid);
    bDoorClosed  := _getSafeValue(in := I_F_Door,  bRetVal := bDoorValid);

    // Apply fail-safe defaults if F-I/O is not yet parameterized
    IF NOT bEStopValid THEN
        bEStopActive := TRUE;       // assume E-Stop is pressed
    END_IF;
    IF NOT bDoorValid THEN
        bDoorClosed  := FALSE;      // assume door is open
    END_IF;

    // Aggregate safety condition
    bAllSafe := (bEStopActive = FALSE) AND bDoorClosed;

    // Drive safety relay only if all conditions are met
    _setSafeValue(out := Q_F_SafetyRelay, in := bAllSafe, bRetVal := sDiagBuf[1]);
END_FUNCTION_BLOCK

The corresponding standard PLC pattern (non-safety I/O) uses the process image:

// Standard PLC: read from process image, not peripheral
L     IW    64        // process image word, does not STOP the CPU on missing slave
T     MW    200       // store in flag area for application logic

For the standard PLC version, when the targeted Profibus slave is offline, IW 64 retains the last valid value. The application can detect the staleness by monitoring the DP slave status bits in the system status list (SSL) or by using RD_REC / RD_SINFO calls in OB100 / OB101 to check slave availability before reading.

9.1 OB100 Pattern: Defer I/O Access Until After First DP Cycle

A complementary pattern is to perform the first direct I/O access only after the Profibus has had time to parameterize. OB100 is a one-shot warm-restart OB; place a one-second delay or a slave-status check there:

// OB100: warm restart
// Mark first cycle
SET
S     "FirstCycle"        // set "FirstCycle" flag
// Do not perform I/O access here; let OB1 handle it
// Clear the flag after 5 seconds in OB35 (cyclic interrupt)
BE

Then in OB35 (100 ms cyclic interrupt), clear the flag after 50 cycles (5 seconds) and allow the rest of the program to perform I/O access. This gives the DP bus a 5-second window to parameterize before the application logic starts touching the peripherals.

10. Step-by-Step Resolution Procedure

1. Confirm the symptom. Power-cycle the D410 with the operator panel and all DP slaves energized. Observe the mode-selector LEDs and the 7-segment display. Note the time from power-on to first RUN entry.
2. Connect with SCOUT and go online with the D410 PLC.
3. Open the diagnostic buffer and export the full event list. Identify the first event with ID 0x4301 (STOP due to I/O access error) and record the detail field (byte/bit/slot/rack).
4. Map the failing I/O to a user program location. Open the cross-reference in SCOUT (right-click the I/O address, Go to > Cross-reference) and find the network or line that reads/writes the address directly.
5. Check the F-runtime membership. If the failing I/O is a safe I/O used inside the SPL, it must be accessed via _getSafeValue / _setSafeValue. Direct access (A I, = Q) is not permitted for F-I/O.
6. Refactor the access pattern:
   • For non-safety I/O: change peripheral (PEW / PAW) to process image (EW / AW), or wrap the read in an RD_SINFO / slave-status check.
   • For safety I/O: replace direct access with _getSafeValue / _setSafeValue and apply fail-safe defaults when the validity flag is FALSE.
7. Recompile and download the project to the D410. Verify the download completes and the PLC enters RUN.
8. Power-cycle the system and confirm the PLC remains in RUN without operator intervention. Repeat the power cycle 3-5 times to ensure the fix is robust across the boot window.
9. Document the change in the project's safety case (if F-I/O was involved) and in the operator manual. The operator must understand that the manual mode-selector procedure is no longer the normal startup path.

11. Verification and Commissioning

After applying the fix, perform the following verification steps before returning the system to production:

The "DP fault injection" test is critical: a properly written application must have OB86 (DP slave failure OB) and OB122 (peripheral I/O access error OB) loaded. Without OB86, the CPU goes to STOP on any DP slave failure during RUN, regardless of the cold-start fix.

12. Related Diagnostic Events

Beyond the "non-valid I/O" event, several related events can surface in the diagnostic buffer during a Profibus startup race. Familiarity with these events speeds up diagnosis:

The "OB not loaded" case is a frequent companion to the reported symptom: if OB86 (DP slave failure) or OB122 (peripheral I/O access error) is not in the project, the CPU has no error handler for transient I/O faults and falls through to STOP. Adding these OBs (even as empty blocks) gives the runtime a place to log the error and continue.

13. Frequently Asked Questions