Resolving S7-1500 Time Drift After WinCC Runtime Restart

Problem Description

On a SIMATIC IPC 477E running WinCC Runtime Advanced V17, an S7-1500 CPU (variant identified by the operator as 2FN03) loses the configured date/time every time the WinCC Runtime is stopped and the PC is rebooted. After the restart, the CPU clock reads one or more hours behind the value previously written by the controller application.

Symptoms reported in the field:

• The controller's time is correct while the Runtime is running.
• As soon as the PC is restarted (or WinCC Runtime is stopped/started), the S7-1500 clock reverts to a value that is typically one or two hours in the past.
• The drift persists even though the application uses WR_SYS_T (write system time) and RD_SYS_T (read system time) in the PLC program.
• No NTP client, no area pointer, and no HMI time synchronization had been configured by the operator.

Root Cause Analysis

The S7-1500 stores and processes time in two parallel representations. Mixing them is the most common source of the drift described above.

System time versus local time on S7-1500

From the S7-1500 System Manual (section "Time functions" in the basic/advanced controller manuals):

"The CPU always operates internally in UTC. The current local time is derived from UTC and the configured timezone rule. WR_SYS_T writes a UTC timestamp; WR_LOC_T writes a local timestamp that the CPU then converts to UTC before storing it."

Two conditions have to be true for the runtime clock to stay aligned with wall time across a Runtime/PC restart:

1. The value the application writes must be in the same time base (UTC or local) that the application later reads back.
2. For local-time operations, the timezone rule on the CPU (and on the Windows side that feeds it) must match the geographic zone, including the active DST state at the moment of write.

What actually drifts on the IPC 477E

The IPC 477E uses Windows IoT / Windows 10 IoT Enterprise as the operating system. WinCC Runtime Advanced uses the Windows system clock as its source of time and, depending on configuration, may also push or pull time into the connected PLC. When the Runtime is stopped and the PC is restarted, the Windows clock is resynchronized with whatever time source is reachable. On an isolated machine with no NTP and no CMOS battery-backed RTC update, the Windows clock can:

• Lose the RTC value (CMOS battery discharged on the IPC's motherboard).
• Fall back to an older time value if the Windows Time service (w32time) reverts to a previously persisted time after a forced resync. See the Microsoft troubleshooting note Computer clock resets to a previous date and time for the documented mechanism.
• Apply a different DST offset than the S7-1500, producing a one or two-hour delta at every Runtime start.

The PLC program only writes once per session with WR_SYS_T. Once the Runtime shuts down, the controller no longer has any way to refresh its clock, so it free-runs on its own hardware RTC. The RTC is reasonably accurate (typically ±20 ppm on the S7-1500), but if it was initialized with a UTC value, the local time that the HMI displays can be off by exactly the timezone offset at the moment of read.

Solution: Switch to Local-Time Functions and Reconcile the Two Clocks

The confirmed fix reported in the field is to replace the time read/write functions in the S7-1500 program with the local-time variants and to keep the timezone configuration in sync between the CPU and the IPC.

Step 1 – Use RD_LOC_T and WR_LOC_T in the PLC program

Inside TIA Portal, locate the blocks that call WR_SYS_T and RD_SYS_T and replace them with their local-time counterparts. The function blocks are in the same library path (Basic Instructions → Date and Time).

Both calls return a RET_VAL word. A non-zero value is an error code (for example W#16#0001 = invalid LOCTIME input, W#16#0002 = parameter error). The ladder snippet below shows the corrected pattern in FBD/GRAPH-friendly form:

// Acquire local time once per scan (or on demand)
"RD_LOC_T_DB".RET_VAL    := ;  // status output
"RD_LOC_T_DB".LOCTIME    := #dtl_local;

IF #btn_set_time THEN
    // #dtl_local is built from a WinCC tag or from an HMI input
    // whose value already represents local time
    "WR_LOC_T_DB".LOCTIME  := #dtl_local;
    "WR_LOC_T_DB".RET_VAL  := ;  // status output
    #btn_set_time := FALSE;
END_IF;

Step 2 – Verify the S7-1500 timezone configuration

Open Device configuration → Properties → General → Time of day for the S7-1500 in TIA Portal and confirm:

1. Time zone is set to the operating site's local zone (for example "(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna").
2. Daylight saving time / standard time conversion is enabled if the country observes DST.
3. The Time zone entry actually downloads to the CPU (TIA Portal writes the rule on every download; you can read it back under Online & Diagnostics → Time of day).

For an S7-1500, the timezone rule is held in the CPU's non-volatile memory; however, after a firmware update or an MRES (memory reset) the rule is restored to UTC. Always re-check after an MRES.

Step 3 – Align the Windows timezone on the IPC 477E

The WinCC Runtime reads time from the Windows system clock, so the Windows timezone must match the PLC timezone. On the IPC 477E:

1. Open Control Panel → Clock and Region → Date and Time → Change time zone.
2. Set the same time zone as the PLC and enable Automatically adjust clock for Daylight Saving Time.
3. Disable any Set time automatically Internet time toggle while troubleshooting so the Windows clock is not being pulled from a public NTP source that disagrees with the PLC's rule.
4. If the IPC's CMOS battery is end-of-life, replace it; otherwise the Windows clock loses the time when the IPC is unpowered. The Microsoft knowledge base article Computer clock resets to a previous date and time describes how w32time can re-apply an old time value when the registry is in a bad state; clear the W32Time parameters under HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters and force a resync with w32tm /resync /force.

Step 4 – Confirm no conflicting time sync is active

Before declaring the fix complete, rule out any of the mechanisms that can also push the S7-1500 clock without your knowledge:

• Area pointer "Date/Time PLC" in the WinCC RT Advanced connection. If it is enabled, the Runtime writes the Windows clock into the PLC at every Runtime start. Open Connections → [your HMI connection] → Area pointer and disable it unless you want that behavior.
• Time synchronization mode in the HMI connection. Master means the HMI pushes time to the PLC; Slave means the HMI reads time from the PLC. Set the role explicitly and document it.
• NTP client on the PLC (S7-1500 supports NTP from firmware V2.0 onward). If an NTP server is configured in the CPU's PROFINET interface and that server disagrees with the Windows time, the PLC will free-run on the NTP value at the next resync.
• NTP client on Windows. The w32time service can be configured as an NTP client; if the source time differs from the PLC's timezone rule, you will see the exact one- or two-hour drift described above.

Alternative Solutions

If, for any reason, you cannot modify the PLC program (brownfield machine, validated code base), there are three alternative approaches. Each has trade-offs.

Alternative A – NTP for the S7-1500 only

Configure the CPU as an NTP client and point it at a local NTP server that the operator controls. NTP keeps the CPU's UTC clock aligned at all times, so the drift after a Runtime restart disappears. This is the cleanest solution if you can put a stable NTP source on the plant network. The CPU's NTP configuration lives under Device configuration → PROFINET interface → Time-of-day synchronization and requires that the CPUs NTP client be enabled and that the firewall allow UDP port 123.

Alternative B – NTP for the IPC only

Configure the IPC's w32time service as an NTP client to a local server, leave the area pointer and time sync mode at their defaults, and accept that WinCC pushes the Windows time into the PLC on every Runtime start. This gives you a single source of truth (the NTP server) without touching the PLC program.

Alternative C – Keep the area pointer, fix the Windows side

If business rules require that the PLC is always slaved to the panel clock, enable the area pointer and set the connection time synchronization mode to Master on the HMI side. The PLC then never holds an independent time, eliminating the drift entirely. The catch is that the panel must always be running, so any PLC-side logging in the gap between Runtime restarts will be wrong.

Verification

After applying the local-time function block change and aligning the timezones, perform the following checks. The expected result for every step is a PLC time within ±1 second of the IPC's local time immediately after a Runtime start.

1. Online readback of CPU time. In TIA Portal, go to Online → Online & Diagnostics → Time of day. Note the displayed local time.
2. PLC tag readback. Monitor the DTL tag fed by RD_LOC_T in the HMI. The value must match the CPU's online view, including DST offset.
3. Windows clock readback. Open the Windows clock applet on the IPC. The value must match the PLC to the second.
4. Restart test. Stop the WinCC Runtime, restart the IPC, log in, and re-read all three values. They must still match.
5. DST boundary test (optional but recommended for plants in DST zones). Set the IPC and PLC clock to a date 5 minutes before the next DST transition. Restart the Runtime. After the transition, the local-time tags must advance by exactly one hour with no manual intervention.
6. Drift test. Leave the Runtime running for 24 hours. The PLC's local time, the IPC's Windows time, and a reference NTP-displaying client must all agree within ±2 seconds. A deviation larger than ±5 seconds points to a hardware RTC issue on the IPC, not a function-block issue.

Field-Proven Diagnostic Procedure

When a customer reports that "the PLC clock goes back after Runtime restart", walk through this decision tree in order.

Why the Drift Can Be Exactly One or Two Hours

The "two hours back" symptom is not random. It is almost always a UTC/local mismatch combined with a DST state that is different on the two devices. The most common combinations on a European plant are:

That is why the operator sees the time "go back two hours" when the Runtime is restarted after a DST transition has occurred on the Windows side but not yet on the PLC side (or vice versa).

Safety and Data Integrity Notes

• Time jumps of exactly one hour near a DST boundary are expected and are not a defect. Audit logs that require monotonic timestamps must store UTC, not local time.
• Do not enable both the area pointer and an NTP client that point at different sources. The two writers will race, and the CPU will free-run on whichever wrote last.
• When validating pharmaceutical or food-and-beverage lines, the time base used for batch records must be documented. Mixing UTC and local in a single recipe is a common 21 CFR Part 11 finding.
• After any PLC firmware update, re-verify the timezone rule. Some firmware versions reset the rule on first boot.

FAQ