Fixing PLC Alarm Timestamp Mismatch on TP1500 Comfort with S7-400

Fixing PLC Alarm Timestamp Mismatch on TP1500 Comfort with S7-400

Siemens S7-400 CPUs (including the F-variant CPU 416F-3 PN/DP) stamp every alarm, diagnostic buffer entry, and SFB/SFC message with a time value. When a SIMATIC TP1500 Comfort panel receives that alarm, the stamp is re-rendered in the HMI's local time zone. If the two devices do not share a common time base, the alarm view shows times that drift, jump, or are simply wrong relative to wall-clock reality. This article documents the root cause, the standard Siemens remedies (NTP, area pointer, master/slave), and a verification procedure that an automation engineer can execute in a live plant.

1. Problem Description

The reported installation has the following behavior:

• Several HMI screens show different system times, none of which match the current time.
• PLC error alerts on those screens inherit the wrong time, so the alarm log cannot be trusted for incident review.
• The operator must manually correct the time on each screen to get a sensible alarm history.

This is a classic symptom of an HMI that has never been told where the correct time comes from. The panel's onboard RTC (real-time clock) drifts at roughly ±20 ppm, which is about ±1.7 seconds per day, and accumulates to several minutes per month without a correction source.

2. Root Cause Analysis

Comfort Panels receive a UTC time stamp with every PLC alarm. The panel then converts the UTC value into the configured local time zone for display. Two failure modes are possible:

From the case, the S7-400 has its clock synchronization type set to Slave in the hardware configuration, but no master (NTP server, master clock, or another CPU) has been bound to it. The HMI connection has HMI time synchronization disabled. The panel therefore relies entirely on its own RTC, which has not been set or has drifted.

3. System Identification

4. Reference Architectures

Siemens supports three viable time-synchronization paths between an S7-400 and a Comfort Panel. Pick one; do not mix them.

4.1 External NTP master (preferred for plants)

Figure 1 — Both devices take NTP from the same master, eliminating drift and offset.

4.2 PLC as NTP server (no plant NTP available)

Figure 2 — The S7-400 acts as the NTP source for the Comfort Panel. Documented in Siemens support entry ID 82203451.

4.3 Area pointer time master/slave (no NTP at all)

Figure 3 — The CPU pushes time to the panel via the Date/Time or Coordination area pointer. No NTP required.

5. Solution Path 1 — NTP on Both Devices (recommended)

This is the standard Siemens-recommended path. See Siemens support entry ID 82203451 for the canonical S7-400-as-NTP-server procedure and the complementary entry ID 69864408 for the overall time-synchronization concept.

5.1 Configure the S7-400 as NTP client

1. Open the S7-400 station in TIA Portal V16.
2. Select the CPU 416F-3 PN/DP, then open Properties → Time of day.
3. Set Time synchronization type to NTP.
4. Under NTP server, add up to four IPv4 addresses (plant master clock, GPS receiver, or stratum-2/3 server). Use a server reachable on the PN subnet.
5. Set Update interval to a value appropriate for accuracy needs:

   Use Case	Recommended Interval	Notes
   Sub-second audit trail	10 s	Highest load; reserved for safety event recording
   Standard plant use	60 s	Default choice; well within S7-400 RTC accuracy
   Office / low-priority	3600 s	Minimizes network traffic; drifts up to ±1 s between syncs

6. Compile (Hardware) and download to the CPU.

5.2 Configure the S7-400 as NTP server (optional, when no plant NTP exists)

If the S7-400 has no upstream NTP source but is set to an accurate time manually (or from a GPS serial feed), it can serve time on its PROFINET interface. The procedure is documented in entry 82203451. Typical parameter values:

5.3 Configure the TP1500 Comfort as NTP client

Two parallel configuration paths are needed: the project side (TIA Portal) and the runtime side (Control Panel on the panel).

Project side (TIA Portal V16)

1. Open the HMI device → Connections.
2. Select the S7 connection to the S7-400.
3. Confirm the connection is on the same PROFINET subnet as the CPU 416F-3 PN/DP.
4. The HMI time-synchronization role of the panel is set to Slave by default when the PLC is the NTP source. Do not enable Master on the HMI side; the PLC must remain the authoritative time source.

Runtime side (Windows Embedded CE 8.0)

1. Open Control Panel on the panel.
2. Set Date/Time — verify the current values, then set Time Zone to the plant zone and enable Automatically adjust clock for daylight saving.
3. Open Network and Dial-up Connections → select the PROFINET adapter → Internet Protocol v4 properties → tab Name Servers (or Time Server on newer CE 8.0 builds): enter the NTP server IP, check Synchronize with time server.
4. Apply, then Start → Programs → Command Prompt on the panel and run ping <NTP IP> to confirm reachability.

6. Solution Path 2 — HMI-to-PLC Time Sync via Area Pointer

Use this when no NTP infrastructure exists at all. The PLC acts as the time master and pushes its time to the HMI every synchronization cycle.

6.1 Enable PLC-side master

1. In Devices and Networks, select the HMI connection between the CPU 416F-3 PN/DP and the TP1500 Comfort.
2. Open the connection properties → HMI time synchronization section.
3. Select Master. This binds the S7-400 as the time authority for this HMI connection.
4. Compile and download.

6.2 Confirm the HMI-side slave

1. On the HMI connection, the panel role should be Slave (default when the CPU is Master).
2. The HMI automatically accepts the time update and re-stamps any queued alarm events on the next refresh.

6.3 Why the "Slave" radio is sometimes greyed out

If the Slave option cannot be selected in the connection editor, the most common causes are:

• The HMI is on a different subnet than the CPU, and the connection is routed through a gateway or another CPU. Recreate the connection directly on the PROFINET subnet.
• The connection type is set to a routed S7 connection that traverses an F-proxy. PROFINET IO between the F-CPU and the HMI must be enabled, even if no I/O data is exchanged; the time sync uses the same PN channel.
• Older TIA Portal versions had the option hidden if both Master and Slave were unchecked; setting the CPU side to Master automatically fixes the panel side to Slave on the next compile.

When in doubt, fall back to Solution Path 1 (NTP). NTP does not require the Master/Slave area pointer and works across routed subnets.

7. Solution Path 3 — HMI Pushes Time to the PLC

Used only when the panel has a better time source (GPS, mobile NTP) and the PLC must follow. Set the HMI connection's HMI time synchronization to Master on the panel side. The panel writes its time into the PLC's clock every cycle. This is not appropriate for the reported installation, where multiple panels exist and the CPU is the natural time source.

8. Time Zone, UTC, and Daylight Saving Time

Comfort Panels send and receive PLC alarm timestamps in UTC. Configure both devices for one of the two consistent strategies:

Pick one strategy and apply it identically to every CPU and panel in the project. Mixing strategies is the most common cause of one-hour offsets and double DST jumps.

9. Battery and Power-Cycle Behavior

The TP1500 Comfort V2 retains time across power cycles only if:

• The RTC backup battery (CR2032-style, on the back of the unit) is installed and healthy (typical life 5–10 years).
• WinCC Comfort is configured with Use time of day from the device and not Use project time (Runtime Settings → General).

If the battery is dead, the panel reverts to a default epoch (often 2008-01-01 00:00:00) on every boot. This alone will produce the exact symptom described in the case: a stale time on every screen. Replace the battery before re-architecting the time sync.

10. Verification Procedure

1. From a laptop synchronized to the same NTP source, generate a PLC alarm (set a tag wired to a configured alarm at a known wall-clock time).
2. On the panel, open the alarm view and confirm the timestamp matches the laptop time within ±1 s.
3. Cycle power on the panel. After the next NTP sync cycle, confirm the time is restored automatically (no manual correction).
4. Trigger a second alarm 5 minutes later. Confirm the new timestamp is 5 minutes after the first.
5. Read the CPU 416F-3 PN/DP diagnostic buffer (online → Online & Diagnostics → Diagnostic buffer) and confirm each entry matches the panel display within ±1 s.
6. Force a DST transition (or use a controlled test by changing the time zone offset) and verify the panel shifts by exactly 1 h.

11. Troubleshooting Matrix

12. Safety Considerations on the F-CPU

The CPU 416F-3 PN/DP is a fail-safe CPU. The safety program should never derive safety actions from the wall-clock time, because a faulty time source (drift, manipulated NTP, dead RTC) is not part of the F-IE/Profisafe safety case. If a time-based safety function is genuinely required, the time source must be:

• Part of the safety integrity calculation, or
• Provided by a safety-qualified source (e.g., a hard-wired watchdog) instead of NTP.

Time stamping of safety events is fine; safety decisions on time are not.

13. Field-Proven Recommendations

• Always deploy NTP (Solution Path 1). Area pointer time sync (Path 2) is a fallback only; it is silent when the link drops, so a panel can drift for hours before anyone notices.
• If the plant has more than one HMI, all panels must point to the same NTP server. Do not let panels self-elect as master.
• Document the NTP server IP, update interval, and time zone in the project functional specification. The time configuration is part of the safety and quality case, not an afterthought.
• Schedule an annual check: confirm the panel time matches a reference clock at 12:00 local, ±2 s.
• Replace the RTC battery on a fixed schedule (every 5 years) rather than waiting for failure.
• When the panel image is upgraded from V15.1 to V16, re-test all time behavior; the regional settings DLL differs between images.

14. Frequently Asked Questions