Resolving S7-1200 NTP Time Sync Failure in TIA Portal V19

When a SIMATIC S7-1200 CPU is configured to act as an NTP client against a local network time server, the engineer typically expects the standard Siemens behavior: a polling cycle, a successful SNTP/NTP frame exchange over UDP/123, and an updated CPU time-of-day. On firmware 4.5.1 CPUs programmed with TIA Portal V19, a distinct failure mode has been reported where the CPU appears to make no NTP request at all. No diagnostic buffer entry is written, the MAINT LED does not illuminate, and the online time of day remains stale. This reference documents the root cause, the affected configurations, and the field-verified remediation steps.

1. Problem Details

1.1 Reported Configuration

The failure manifests under the following conditions, each of which has been reproduced on multiple identical S7-1200 CPUs:

• CPU family: SIMATIC S7-1200 (any DC/DC/DC or AC/DC/RLY variant that supports PROFINET, e.g. CPU 1214C, CPU 1215C, CPU 1217C).
• Firmware version: V4.5.1 (also reported on V4.4.x and V4.5.0 where the project was last compiled against TIA Portal V17/V18 libraries and re-opened in V19).
• Engineering tool: TIA Portal V19 (Build 19.0.0.x) with the matching S7-1200 HSP if a non-default CPU type is used.
• NTP server: Windows Server 2019/2022 workstation configured per the Siemens Application Example at Siemens Support Entry 22144502. The server is reachable on the same subnet (verified by ping and w32tm /monitor from a separate engineering station).
• Network: Direct connection or shared L2 segment; no firewall between PLC and NTP server in the test bench.

1.2 Observed Behavior

After a power cycle of the CPU, the diagnostic buffer does not contain the time-synchronization-related entries that an S7-1500 produces when the time master is unreachable. Specifically, the following IDs are absent:

The Online & diagnostics > Time view shows the configured NTP server IPs, the synchronization interval, and the last attempt timestamp, but the Last synchronization field never advances. The CPU clock continues to free-run from the RTC drift.

2. Root Cause Analysis

The S7-1200 NTP client is an opt-in feature. According to the S7-1200 manual collection - Configuring NTP synchronization, the NTP client is disabled by default and only becomes active once the user enables a time-master role and enters at least one valid IPv4 address. With TIA Portal V19, Siemens introduced a default NTP security policy that, when left at the default value, silently rejects the SNTP/NTP request before it leaves the PROFINET interface.

Two distinct root-cause layers can produce the silent failure. Both must be ruled out sequentially.

2.1 Layer A - NTP Security Policy Mismatch

TIA Portal V19 ships with the NTP security parameter on the CPU's Properties > Time of day > NTP tab set to Security enabled (default). In this state, the S7-1200 expects the server to support authenticated NTP (RFC 5905 with symmetric key or NTS-KE). A standard Windows w32time server configured per Siemens Application Example 22144502 does not implement authenticated NTP; it offers plain SNTPv4 over UDP/123. The S7-1200 firmware parses the option flags, determines the server's response is non-conformant, drops the packet, and does not log a diagnostic event - this is by design to avoid buffer flooding in plant networks with multiple NTP candidates.

2.2 Layer B - Configuration Download Hash Match (No-Op)

A second, more subtle issue arises when the project was originally compiled with a TIA Portal version older than V19 and then re-opened. The Go online > Download to device wizard compares the configured NTP block against the runtime image; if the new V19 NTP block is binary-compatible at the PLC tag level but has different default attributes (the new NTP security default), the wizard may report Configuration is identical - no download required. The NTP block on the CPU is therefore never refreshed, and the project in the engineering station and the runtime diverge. The user must force a hardware re-download.

2.3 Layer C - Firewall on the NTP Server

If the NTP server is a Windows host with the Windows Defender Firewall enabled, the default profile permits NTP on the Domain profile only. On a control-network interface that is Private or Public, the inbound UDP/123 rule must be created explicitly. The lack of a rule produces the same silent failure on the PLC side because the kernel drops the return packet at the server before it ever reaches the wire.

3. Affected Versions and Compatibility

4. Solution Procedure

4.1 Prerequisites

• Windows administrator account on the engineering station (required to run TIA Portal V19 with elevated rights when modifying security attributes).
• Source project file (.ap19) or TIA Portal V19 live connection to the affected CPU.
• Network access between the engineering station, the S7-1200, and the NTP server. ping to the NTP server IP must succeed from the CPU's PROFINET interface - verify with Online & diagnostics > Functions > Assign IP address (do not actually assign; just observe the ping response in the trace).
• If using a Windows NTP server: w32tm /query /status on the server to confirm Source: is Local CMOS Clock and Stratum: is below 4.

4.2 Step-by-Step Remediation

1. Open the device configuration of the S7-1200 CPU in the project tree (double-click Device & networks > CPU).
2. Navigate to Properties > Time of day > NTP in the inspector window.
3. Enable NTP synchronization: tick the Enable NTP checkbox. The four server slots (Server 1 - Server 4) become editable.
4. Configure the primary NTP server: enter the IPv4 address of the Windows w32time server (e.g. 192.168.0.50) into the Server 1 field. Configure Server 2 - Server 4 only if redundant time masters are available; leaving them blank is permitted.
5. Set the synchronization interval: the default is 10 s. For plant-floor S7-1200s, the recommended value is 60 s to 600 s to keep CPU utilization low. For the lab bench, leave at 10 s to accelerate verification.
6. Configure the NTP security policy (critical): in the NTP security dropdown, select No security. This is the field-proven setting that allows the S7-1200 to interoperate with a Windows w32time server configured per Siemens Support Entry 22144502. The alternative Security enabled option requires the server to support authenticated NTP, which is not provided by the standard Windows time service.
7. Confirm the time zone: set Time zone to the local zone and verify Daylight saving time is enabled if applicable. The CPU time-of-day tag LOCTIME reflects local time, while the time transmitted over NTP is always UTC; the local-to-UTC conversion is handled by the CPU firmware and is independent of the NTP frame exchange.
8. Compile and download the hardware configuration: select the CPU in the project tree, click Download to device in the toolbar. If the dialog reports The configuration in the target device is identical to the offline configuration, tick Overwrite all under Download options to force a refresh of the NTP block. Confirm the prompt with the assignment name.
9. Cycle power on the S7-1200 (or trigger an MRES to be sure). The NTP client only initializes on a cold start. A warm restart (RUN -> STOP -> RUN) is sufficient to re-evaluate the NTP block on most firmware loads, but a power cycle is the only guaranteed trigger across all 4.5.x revisions.
10. Verify: proceed to Section 5.

4.3 Windows NTP Server Firewall Configuration

If the Windows NTP server is the time master, apply the following rules on the server (PowerShell, run as Administrator):

New-NetFirewallRule -DisplayName "NTP - Private" -Direction Inbound -Protocol UDP -LocalPort 123 -Action Allow -Profile Private
New-NetFirewallRule -DisplayName "NTP - Public" -Direction Inbound -Protocol UDP -LocalPort 123 -Action Allow -Profile Public
New-NetFirewallRule -DisplayName "Block NTP - Domain" -Direction Inbound -Protocol UDP -LocalPort 123 -Action Block -Profile Domain

The third rule prevents the server from being coerced into serving NTP to corporate clients on the domain profile. Replace the values with the actual profile of your control-network interface.

4.4 Hardware Configuration Hash Mismatch Recovery

If TIA Portal V19 reports Configuration is identical after you have changed the NTP security setting, force a clean download:

1. Right-click the CPU > Download to device > Software (all).
2. In the Download options dialog, tick Overwrite all and Reset to factory defaults (only if no other retain data must be preserved).
3. Confirm and download.

For retain data, use Online & diagnostics > Functions > Format MRES only if the offline project is the source of truth; otherwise, write a small script to back up DBs to the engineering station's TIA Portal Project history first.

5. Verification

After the remediation steps, perform the following verification on the S7-1200:

1. Online & diagnostics > Time: confirm the Last synchronization timestamp advances at the configured interval.
2. Online & diagnostics > Diagnostic buffer: confirm the presence of a new entry with ID 0xE802 ("Time synchronization successful") after the first successful poll. If only 0xE801 ("Time synchronization started") is present, the response is still being rejected by the security policy.
3. Time drift test: disconnect the NTP server (block UDP/123 at the switch with an ACL or simply power down the server). After one full interval, the diagnostic buffer should record 0xE805 ("Time synchronization failed"), and the MAINT LED should begin flashing. This confirms the failure path is active and the original symptom (silent failure) is resolved.
4. Cross-check with Wireshark: span the port between the S7-1200 and the NTP server. Filter on udp.port == 123. With No security set, the CPU should issue an NTP client request within the first 10 s of the cycle, and the server should reply with a mode-4 response. With Security enabled set and an unauthenticated server, the CPU may issue a request and ignore the response - the symptom described in this article.
5. Cross-check from a third-party SNTP client: from a Linux workstation on the same subnet, run ntpdate -q 192.168.0.50 (or sntp -t 5 192.168.0.50 with ntpsec installed). If the third-party client succeeds and the S7-1200 does not, the issue is definitively on the PLC side, not the network.

6. Diagnostic Buffer Event Reference

The S7-1200 writes NTP-related events to the diagnostic buffer with the following IDs (firmware 4.4 and later). Use this as a quick reference when triaging:

7. NTP Configuration Parameter Reference

8. Troubleshooting Matrix

9. Alternative Time Synchronization Methods

If the NTP path remains problematic in a given plant, the S7-1200 supports two additional time-of-day propagation methods that can be used as a fallback or in combination:

9.1 SIMATIC Time-of-Day via PROFINET (RT class)

A PROFINET IO controller with IRT or RT configuration can transmit a synchronization frame. The S7-1200 acts as a sync slave in this mode and the time is updated at the start of each PROFINET cycle. This path is independent of NTP and the firewall considerations above, but requires a PROFINET controller that is itself synchronized (typically to a GPS source).

9.2 HMI / SCADA Tag Write

An HMI panel or SCADA can write the local time into a clock-DB tag, and a cyclic OB can call WR_SYS_T (SFC 100) to push the value into the CPU's time-of-day. This is a manual workaround, not a true NTP path, and the drift between syncs is the responsibility of the calling logic. Reserve this for legacy migrations where NTP cannot be enabled in the project.

10. Firmware Update Recommendation

When the NTP security default cannot be relaxed in the project (e.g. a corporate security policy mandates authenticated NTP), update the S7-1200 firmware to a revision that ships a NTP client supporting NTS-KE (Network Time Security - Key Establishment, RFC 8915) or symmetric-key authentication per RFC 5905. Check the latest available firmware and the corresponding release notes on the Siemens Industry Online Support portal; the firmware update is delivered as a .upd file and applied via the SIMATIC Automation Tool or the CPU's online Update firmware function.

11. FAQ