S7-1200 Retain Memory Erased: Root Cause and Diagnostic Procedure

• LostRetentive is TRUE for exactly one cycle at the end of the Startup OB if retentive memory was corrupted or lost during the last power-down.
• If no Startup OB is programmed, the bit cannot be evaluated. The CPU still sets the internal diagnostic buffer entry Retentive data lost regardless.
• To capture and latch the state, copy the bit to a non-retentive M or DB tag at the end of OB100 and use it in OB1 to drive a fault indicator.

Example latch in OB100 (SCL):

IF "OB100".StartupInfo.LostRetentive THEN
  "diag".retainLost := TRUE;
  "diag".retainLostTimestamp := DT_TO_DATE(IN := "OB100".StartupInfo.StartupTime);
END_IF;

6. Diagnostic Tree for an In-RUN Retentive Wipe

When retentive memory clears while the CPU is in RUN, the only credible causes are:

1. Internal NV failure. The NVRAM cell block on the CPU has aged or experienced a write-cycle overrun. Diagnostic buffer entry: Internal error, retentive data inconsistent. Resolution: replace CPU; export project first via TIA Portal online snapshot.
2. Brownout below hold-up threshold. 24 V supply dipped under 19.2 V for longer than the PLC hold-up. Diagnostic buffer: Power failure and a corresponding STOP / POWER-ON pair. This wipes non-retentive only — not retentive — so it should be ruled out.
3. Unintended MRES via selector. The selector was toggled to MRES (or held past the position). Visible in diagnostic buffer as Memory reset performed.
4. Online project download with "Reset PLC" flag. Only relevant if TIA Portal was attached. Diagnostic buffer: Download of program to CPU with subsequent STOP → RUN.
5. EMC-induced reset on communication modules. A long cable tied to a live AC feeder can couple transients into the 24 V bus. The CPU may enter a defensive stop. This does not erase retentive memory; it may, however, trigger an event that appears as a memory wipe if the application reads initialization values that overwrite the DB on first scan and the designer was unaware of the difference between non-retentive DB instance and the HMI-supplied defaults.

Step-by-step isolation procedure:

1. Open Online → Diagnostics → Diagnostic Buffer in TIA Portal. Filter on the date/time of the event. Note all entries between the last successful cycle and the recovery.
2. Confirm whether a STOP entry exists. If yes, read the cause; if no, the CPU never stopped — the wipe must be logical, not physical.
3. Inspect all OB1 code paths that write to the affected tags. Search for MOVE or assignment blocks at the start of cycle, particularly conditional on first-scan flags.
4. Add a Startup OB (OB100) if missing. Latch LostRetentive to a non-retentive flag and a HMI-visible bit. Recreate the fault; if the bit never latches, the wipe is application-driven, not CPU-driven.
5. Check 24 V rail with a memory oscilloscope. A 2 ms sag below 19.2 V on the CPU terminals will trigger a STOP but is not retentive-fatal. A sag exceeding 50 ms or repeated events can corrupt the NVRAM backup on early firmware loads.
6. Replace the CPU with a known-good unit of the same MLFB. If the fault disappears, the NVRAM is the cause. If it persists, the cause is in the application or supply.

7. Cable Work and Electromagnetic Coupling

The field report states cable connections were being made to other parts of the panel during the wipe. Possible mechanisms:

• Shared 24 V return path. Routing an unshielded cable into the same duct as a 24 V supply that powers an inductive load creates a momentary ground shift when the new connection is made. This is rare on the 1215C but not impossible if the new load draws high inrush.
• Conducted transient on a long run. If the new cable runs in parallel with a 400 V feeder for more than 5 m, capacitive coupling can inject a sub-millisecond spike on the 24 V bus. The 1215C's input filter will absorb the spike, but a 1 ms undervoltage at 21 V is on the edge of the hold-up. Verify with a buffered scope.
• Static discharge to an open terminal. If the operator touched a live terminal while statically charged, the discharge can propagate to the backplane. The CPU enters a hardware interrupt and resets the communication subsystem; retentive memory is preserved, but the I/O image is re-initialized. This is the most likely benign cause for an apparent wipe combined with HMI comms loss.

8. HMI Date Anomaly: Year Boundary in Historical Logs

The symptom — "data from 2019 is renamed to 2020 when the clock crosses midnight on 31 December" — is a documented interaction between the HMI runtime time base and the historical log file format. The HMI's data logging to USB uses a filename pattern tied to the system clock, and the timestamp inside each record is written at flush time, not at acquisition time.

For SIMATIC Comfort Panels (TP700, TP1200, KTP1200) and Unified Comfort Panels, the historical data is stored in CSV or proprietary .dblg files on the storage medium. The runtime's "Time synchronization" master must be configured:

1. In the HMI project: Connections → Area pointer → Date/Time synchronization. Mark the PLC as the master.
2. In the PLC: CPU Properties → Time of day → Time synchronization. Enable the PLC as NTP client or as a time master if no NTP is available.
3. Verify the HMI receives a time update by reading the panel's local time after one hour of operation.

9. Verification Procedure

After applying any corrective change, perform the following verification sequence:

1. Connect TIA Portal online. Read the diagnostic buffer; confirm no Retentive data lost entries are generated during a forced power cycle.
2. Set a known value in a retentive DB tag. Stop the CPU. Wait 30 s. Power-cycle. Read the tag — it must equal the last value.
3. With OB100 in place, trigger a power cycle. Confirm the latched retainLost bit is FALSE for a healthy CPU.
4. Validate the HMI date sync by changing the PLC clock forward by 1 minute; the HMI must follow within one cycle.
5. Create a historical log with 1-second acquisition; cross a year boundary (use the HMI simulator) and verify the file rotation respects the original timestamps.

10. Prevention and Best Practices

• Always program OB100. Even a 3-line block that latches LostRetentive and sets a firstScan bit eliminates the worst class of ghost-wipe investigations.
• Reserve retentive memory explicitly per tag in TIA Portal. Do not rely on range-based reservation alone.
• Use a buffered 24 V power supply sized for 2× the worst-case inrush. A Phoenix Contact QUINT or Siemens SITOP 6EP1334 is appropriate for 1215C installations.
• Keep signal and power cables in separate ducts, crossing only at 90°. Maintain 200 mm separation on parallel runs.
• Enable HMI time-master = PLC and verify with a known good NTP server on the PLC if the network is available.
• Document the firmware version in the project. CPU 1215C firmware 4.2, 4.3, 4.4, and 4.5 have different NVRAM hold-up margins; refer to the Siemens Industry Online Support release notes for each version before drawing conclusions.
• Replace the PLC backup battery (if present on the variant) every 5 years. Loss of the buffer capacitor is silent and not always flagged in the diagnostic buffer.

11. Related Parameters and Tag Addresses

12. FAQ