Troubleshooting SIMOTION D410-2 PN Real-Time Clock Retention Failure

The SIMOTION D410-2 PN is a compact, book-size motion controller with an integrated SINAMICS S120 drive section. It is widely deployed on single-axis high-speed machines where footprint and determinism matter more than I/O count. Like all SIMOTION D4xx-2 controllers, the D410-2 PN maintains a hardware real-time clock (RTC) that timestamps diagnostic buffer entries, trace recordings, alarm histories, and quality stamps used by the application. When the RTC loses its buffered state on power-down and resets to an arbitrary future or past date, the controller still runs — but every timestamped artifact becomes useless, and any application that depends on absolute time (shift counters, batch records, scheduled setpoint changes, time-of-day recipes) immediately breaks.

This article documents the field diagnosis of a D410-2 PN (FW V4.4, integrated SINAMICS V4.7) that refused to retain clock state across power cycles, the diagnostic buffer evaluation that was used to confirm the fault, and the hardware replacement procedure that resolved the issue. It also covers the recommended workarounds (NTP, PLC-side time sync) that protect a fleet of machines from the same class of failure.

1. Problem Description

The reported fault pattern is consistent and easy to recognize:

1. Operator or commissioning engineer sets the clock on the D410-2 PN from the engineering station: Online → Set time → PG time in Scout TIA / TIA Portal, followed by Download hardware configuration and Save RAM to ROM.
2. Power is removed from the control cabinet (planned shutdown, E-stop reset, or a brief mains interruption).
3. On the next power-up, the controller returns with a clock value that is not the default SIMOTION epoch (1992-01-01) and not the previously stored value. In the reported case the value landed in 2024, although 2019 and other years have also been observed on defective units.
4. Setting the clock again and re-cycling power reproduces the fault every time.
5. The same firmware, project, and commissioning sequence on a sibling D410-2 PN (or D425-2 / D435-2) at the same site retains time correctly.

That last point is the single most useful diagnostic clue: the symptom is not project-related and not firmware-related. It is a hardware defect on the individual device.

2. Affected Hardware and Software Versions

The fault is not firmware-version-specific. It has been reported on V4.3, V4.4, and V4.5 SIMOTION D4xx-2 units. The same behavior has been observed on D410-2 DP variants and on D425-2 PN/D435-2 PN units, although the latter are far less likely to fail in this way because the larger controllers use a more robust buffering stage.

3. Root Cause Analysis

3.1 SIMOTION D4xx-2 RTC Architecture

The D4xx-2 family does not use a user-replaceable lithium battery for RTC backup. Instead, the RTC is buffered by a maintenance-free gold-cap (supercapacitor) on the controller board. The buffer holds the 32.768 kHz crystal and the RTC SRAM/registers for a finite retention window — typically 3 to 7 days when the unit is fully de-energized, dropping to a few days if the supercap is aged or partially failed.

When the buffered voltage decays below the RTC's hold threshold, the chip loses its time register and on the next power-up falls back to an internal default. For SIMOTION, that internal default is 1992-01-01 00:00:00 (the SIMOTION “day 0” epoch), but a defective or partially-failed RTC can present a non-deterministic value that can read as any year the silicon happens to power up to — which is why the reported unit booted into 2024 or 2019 rather than 1992.

3.2 Why the Symptom Looks Like a Configuration Problem

Because the time is set, downloaded, and the project is Save RAM to ROM'd before the power-down, the most common false conclusion is that the project is not writing the clock to non-volatile storage. In fact the SIMOTION firmware does persist the time to the RTC's battery-backed register on every successful Set time or on a successful NTP/PLC sync. If the value is lost, the buffering stage has failed — not the persistence path.

3.3 Defect Classification

Field experience with the D410-2 PN places the failure in one of three hardware sub-modes:

4. Diagnostic Procedure

Follow this sequence before assuming the controller is defective. It is faster than an RMA, and it rules out configuration, project, and network-time issues.

4.1 Prerequisites

• SCOUT TIA V4.4 or later with the affected project open.
• Ethernet connectivity to the D410-2 PN's PROFINET port (X200).
• An empty, formatted SD card (optional, for diagnostic buffer export).
• Free access to the cabinet for at least one clean power cycle.

4.2 Step-by-Step

1. Set PG/PC interface. In TIA Portal, set the PG/PC interface to the PROFINET network containing the D410-2 PN. Options → Set PG/PC Interface → TCP/IP (your adapter).
2. Go online. In the project tree, right-click the D410-2 → Go online. Confirm the device is reachable and that the firmware version reported matches the label.
3. Read the diagnostic buffer. In SCOUT TIA, open Project → Diagnostics → Diagnostic Buffer. Click Save as and export the full buffer to a .log file. This is the single most valuable artifact for a Siemens support case.
4. Filter for time and boot events. Use the filter to display only Boot, Reset, Time change events. You are looking for an entry such as:
   Event 1: Power-up — RTC invalid, default 1992-01-01
   or
   Event 1: Power-up — RTC read 2024-xx-xx (CRC invalid).
   Either entry confirms the hardware is not retaining state.
5. Set the clock and persist. In SCOUT TIA, Online → Set time → PG time. Then Target system → Save RAM to ROM so the value is committed to the controller's non-volatile memory.
6. Power-cycle cleanly. Remove 24 V logic power to the D410-2 PN for at least 30 seconds. Restore power. Wait for the controller to complete RUN-up.
7. Re-read the clock. In SCOUT TIA, Online → Set time → Read (or read the Device diagnostics → Time panel). If the value is not within seconds of the time you set in step 5, the retention path has failed.
8. Repeat with a longer soak. Repeat steps 5–7 but leave the unit de-energized for 10 minutes, then for 1 hour. A marginal supercap will fail the 1-hour test even when the 30-second test passes.
9. Capture the diagnostic buffer a second time after the failed power-up and append it to the original log. Events 1–14 in the field case showed the controller booting directly to 2024 with no intervening Set time action by the application.

4.3 What the Diagnostic Buffer Will Show

In the reported case the field engineer exported 94 events from one boot cycle. The relevant slices were:

• Events 15–80: post-Set clock + Download HW + Save RAM to ROM, including a clean Power-down event.
• Events 1–14: post power-up, with the first event being RTC read 2024-xx-xx — time not from buffered storage.

No entry indicated an application write to the RTC, no entry indicated an NTP sync, and no entry indicated a PLC-to-SIMOTION time push. The buffer therefore rules out a project-side cause and confirms the fault lies in the controller's buffering stage.

5. Workarounds Before Replacement

If the machine cannot be taken down immediately, push the time to the SIMOTION from an external source on every boot. SIMOTION D4xx-2 supports three practical time sources:

6. Hardware Replacement Procedure

1. Back up the project. In SCOUT TIA, Project → Archive to a .zip file. Also export the technology objects and the Save RAM to ROM image from the failing unit via Target system → Load to file.
2. Take the axis to a safe state. Disable the drive enable, bring the axis to a known position, and confirm the safety circuit is closed.
3. Power down. Remove 24 V logic power and the line voltage to the SINAMICS section. Wait 5 minutes for the DC link to discharge below 50 V (measure at the DC link test points).
4. Remove the D410-2 PN. Release the two top-hat rail clips, disconnect PROFINET, DRIVE-CLiQ, and the 24 V terminal. Pull the module straight out to avoid bending the backplane pins.
5. Record the new unit's serial number and MAC address from the side label. Both are needed for the PROFINET device name and for the RMA paperwork.
6. Install the replacement. Seat the new D410-2 PN on the rail, re-make all connections, and torque the power terminals to 0.6 Nm.
7. Re-power and commission. Apply 24 V, go online in SCOUT TIA, and Download project to target system (HW + program + TO data). Perform a Save RAM to ROM.
8. Validate the new unit. Run the verification procedure in section 7.

7. Verification

1. After the new D410-2 PN is running, Online → Set time → PG time, then Save RAM to ROM.
2. Power down the logic supply for 60 seconds. Restore power.
3. Go online and read the time. It must be within 2 seconds of the time you set in step 1.
4. Repeat the power-down with a 1-hour soak and a 24-hour soak. Both must pass.
5. Check the diagnostic buffer: the first boot event after each cycle must show RTC value retained from buffered storage, not RTC value invalid.
6. Log the verification result in the commissioning report. Include the new unit's serial number and the date of each successful power-cycle test.

8. Diagnostic Buffer Event Reference

Use the table below as a quick decoder for the events you will see in the SCOUT TIA diagnostic buffer when the RTC is failing.

9. Time-Source Configuration Recipes

9.1 NTP Client in SCOUT TIA

1. Open the device configuration for the D410-2 PN.
2. Navigate to Time synchronization.
3. Enable the NTP client and enter the IP address of the NTP server (typically a plant NTP appliance or a Siemens SCALANCE M-800).
4. Set the poll interval to 60 s and the tolerance to ±500 ms.
5. Download the hardware configuration and Save RAM to ROM.

9.2 PLC-Side Time Push (S7-1500 to SIMOTION)

On the S7-1500 side, call WR_SYS_T (or use the Time synchronization function block in the TIA Portal → PLC tags → Time editor) to broadcast time on PROFINET. On the SIMOTION side, the controller will accept the push if the PROFINET interface is configured as a time slave in the device configuration. No application code is required.

9.3 Application-Level Time Push

If neither NTP nor a PLC master is available, write a startup task in ST that reads the time from any reachable device (HMI, second controller, even a Windows share with a known time) and calls:

Call this once in the StartupTask and again in the BackgroundTask on a 60-second cycle as a safety net.

10. Preventive Measures for a Fleet

• Enable NTP on every SIMOTION D4xx-2 at commissioning. The retention capacitor will eventually fail on every unit; NTP converts that event from a quality incident into a logged event.
• Standardize time sources. Use a single plant NTP appliance (Meinberg, Siemens SCALANCE, or equivalent) referenced to GPS. Avoid letting each cabinet set its own PG time.
• Log the diagnostic buffer to a network share on every boot. A simple ST routine in the StartupTask can write the buffer to an SMB share. The buffer will record every failed retention event with its real timestamp from the network source.
• Track RTC age in the HMI. On machines older than 7 years, add an HMI indicator that warns when the controller has been de-energized for more than 24 hours, prompting a controlled power-up to refresh the capacitor.
• Stock spares for high-availability lines. The D410-2 PN is a single-point-of-failure on a single-axis machine; the cost of a spare is trivial compared to a half-day of unplanned downtime.

11. When the Unit Is Not Defective

If the diagnostic buffer shows an Application set RTC event on every boot, the application itself is resetting the time. Common causes:

• A leftover commissioning routine in StartupTask that calls _setRTC with a hard-coded test value.
• A time push from a master clock that is itself unsynchronized (a Windows PC with a dead CMOS battery, for example).
• An HMI recipe that writes the time on every screen change.

Review the ST/LAD/FBD source for any call to _setRTC, SET_RTC, or TIME_SYNC and remove it. The diagnostic buffer will show who wrote the time and when.

12. Frequently Asked Questions