S7-319-3 PN/DP NTP Time-of-Day Synchronization: Setup, Errors, and Field Diagnostics

The Siemens SIMATIC S7-319-3 PN/DP (order number 6ES7 318-3EL00-0AB0) supports NTP-based time-of-day synchronization on its integrated PROFINET interface. When correctly configured in STEP 7 / HW Config, the CPU acts as an NTP client and polls a configured NTP server at a fixed interval, keeping the internal real-time clock (RTC) within milliseconds of the upstream time source. In practice, engineers frequently encounter situations where the time-of-day (ToD) sync either fails silently, fails to compile, or — more dangerously — silently goes active in a broken state and later drives the CPU clock into an unrecoverable runaway condition. This reference consolidates the configuration, the underlying Siemens behavior, the Windows w32time prerequisites, and the field recovery procedure.

1. Problem Summary and Field Symptoms

The S7-319-3 PN/DP CPU does not update its internal clock from the configured NTP server. Typical symptoms observed by commissioning engineers:

• Time-of-day (ToD) synchronization is enabled in HW Config on the PROFINET port, IP address and interval are correct, but the CPU clock does not change.
• STEP 7 refuses to save and compile the hardware configuration with errors 1230:3000 "The system data could not be generated because the configuration is inconsistent" and 13:5371 "The CPU may only be configured once as a time slave for time synchronization".
• SIMATIC NCM Diagnostic (NetPro / NCM S7) reports: "No diagnostics possible for the module with module ID 6ES7 318-3EL00-0AB0". The PN port does not expose a live NTP diagnostic buffer for this CPU firmware.
• Module Information > Diagnostics and Online > Accessible Nodes do not reveal whether the NTP poll succeeded, is in progress, or has been rejected.

The most critical symptom is the long-tail failure: the configuration is left active but non-functional, and months later the CPU clock begins changing within seconds of any attempt to set it. This is a real-time-clock (RTC) runaway caused by a corrupt or rejected NTP poll being applied without filtering. Recovery requires a 4-hour drive to the customer site in the documented case. The remainder of this article prevents that outcome.

2. Affected Hardware, Firmware, and Software

3. Underlying NTP Model Used by S7-300/S7-400

Time-of-day synchronization in NTP mode for S7-300 and S7-400 CPUs is described in the Siemens function manual "S7-300/S7-400 CPUs - Time-of-day functions". The relevant principles for the S7-319-3 PN/DP are:

• The CPU is an NTP client, not an NTP server or peer. It will not accept sync requests from other devices and will not serve time to panels, drives, or other CPUs.
• The CPU uses the NTP/SNTP protocol on UDP/123 to poll the configured IPv4 address of the NTP server at the configured interval (1 s minimum, 16 h maximum, in 1-s steps; STEP 7 allows 10 s as a practical default).
• The CPU expects the upstream server to be stratum 1 or stratum 2. Stratum values higher than this — for example, a workstation that has never been synchronized — are silently rejected. The CPU gives no diagnostic indication of the rejection.
• Synchronization is performed in UTC. Local time zone and daylight-saving rules are applied by the CPU's clock parameters; the NTP payload itself is timezone-free.
• If the CPU cannot reach the server, the existing clock continues to run from its own oscillator. Drift accumulates at the CPU's RTC accuracy spec (typically ± a few seconds per day, depending on firmware revision and temperature).

Source: Siemens TIA Documentation Cloud — Time-of-day synchronization in NTP mode (S7-300/S7-400).

4. Root Cause Analysis of the Silent Failure

Three independent root causes combine to produce the "I configured it but it does not work" symptom reported on the S7-319-3 PN/DP:

4.1 Windows w32time is a client by default

Out of the box, the Windows Time service (w32time) on Windows XP SP3, Windows 7, and Windows Server 2003/2008 is configured as a time client. It will synchronize itself to a domain hierarchy or to time.windows.com, but it will not answer NTP polls from a PLC. The PLC's NTP request arrives on UDP/123, w32time drops it, the CPU receives no reply, and the PLC does not retry visibly. There is no STEP 7 or CPU-side error for this case.

Setting the registry value

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
"LocalNTP"=dword:00000001

alone is not sufficient on most Windows builds. The full set of changes to promote w32time to an NTP server role is required (see Section 6).

4.2 Stratum rejection on the CPU

Per the Siemens function manual, the S7-300/S7-400 NTP client only accepts time from a server that is itself synchronized to a higher-stratum source. If the PC has never been synchronized to a real time source, its w32time reports as stratum 3 (unsynchronized) or higher, and the CPU ignores the packet. This is the behavior the second responder in the field case identified.

4.3 Single-slave policy (error 13:5371)

The S7-319-3 PN/DP allows the CPU to be a time slave to exactly one source. If the engineer has also enabled Synchronize CPU via MPI/DP slave in the CPU's clock properties (set the CPU "as slave" in HW Config > CPU > Properties > Diagnostics/Clock), the configuration is internally inconsistent. STEP 7 rejects compilation with:

Save and Compile (1230:3000) The system data could not be generated because the configuration is inconsistent.
Save and Compile (13:5371)  The CPU may only be configured once as a time slave for time synchronization.

Both forms of clock-slave configuration must not coexist. The fix is to clear the CPU-side "as slave" checkbox and rely on the PN-side NTP mode, or vice versa.

5. Pre-Configuration Checklist

1. CPU is an S7-319-3 PN/DP (6ES7 318-3EL00-0AB0). Older S7-300 PN CPUs require a CP 343-1 with NTP capability instead of integrated PN support.
2. STEP 7 V5.5 (or compatible) is installed; the hardware catalog shows the CPU at firmware version matching the actual module.
3. The PC acting as NTP server has a static IP address (the S7-319-3 does not use DHCP for its NTP source).
4. The PC's system time is set, even if approximate. w32time requires a valid local time before it will advertise itself as a server.
5. UDP/123 is open inbound and outbound on the Windows firewall between the PC and the CPU's PN subnet.
6. No other NTP server, CP, or MPI/DP time master is configured in the same S7 station (Section 4.3).

6. STEP 7 Configuration Procedure (NTP Mode)

6.1 Enable NTP on the PROFINET port

1. Open SIMATIC Manager > open the project > HW Config.
2. Double-click the PN-IO port of the CPU (the X150 PROFINET interface on the S7-319-3 PN/DP).
3. Switch to the Time-of-day Synchronization tab.
4. Check "Enable time synchronization via NTP server".
5. Enter the NTP server IP address (e.g., 10.26.20.116).
6. Set the synchronization interval. STEP 7 accepts 1 s to 16 h; 10 s is the documented practical default for a workstation-based server.
7. Save and compile the HW Config.

6.2 Clear the redundant CPU-side slave setting

1. Double-click the CPU in HW Config.
2. Open the Diagnostics/Clock tab.
3. In the Clock group, uncheck "Synchronize CPU via MPI/DP slave" if the PN-side NTP mode is the chosen source. Alternatively, leave CPU as master and disable PN NTP — never enable both.
4. Recompile HW Config. Error 13:5371 must be gone.

6.3 Download hardware configuration

1. Select the CPU in HW Config > PLC > Download to Target System.
2. Select the PN interface as the download channel (the PN port that hosts NTP must be reachable; routing through MPI/DP will not work for NTP itself).
3. After STOP → RUN, allow one full interval (10 s default) for the first NTP poll to complete.

7. Configuring the Windows w32time NTP Server

The w32time service must be promoted from a default client to an authoritative NTP server. On Windows XP SP3 the procedure differs slightly from Windows 7/Server 2008; the canonical Microsoft reference is the "Windows Time Service" technical reference. The essential registry values are listed below.

7.1 Registry values for a standalone NTP server

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
"Type"="NTP"
"NtpServer"=""
"LocalNTP"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer]
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"AnnounceFlags"=dword:00000005
"MaxPosPhaseCorrection"=dword:ffffffff
"MaxNegPhaseCorrection"=dword:ffffffff

Notes on each value:

• Type = "NTP" — sets the role to a peer/server rather than NT5DS domain client.
• NtpServer = "" — empty when this PC is the upstream; populated only if it should also pull from a higher source.
• LocalNTP = 1 — required. Without this, w32time still will not respond on UDP/123 to LAN clients.
• NtpServer provider Enabled = 1 — turns the listening socket on.
• AnnounceFlags = 5 — declares the machine as a reliable time source (0x1 = always time server, 0x4 = local CMOS clock as source).
• MaxPosPhaseCorrection / MaxNegPhaseCorrection = 0xFFFFFFFF — disables the "big jump" guard, required so that the first NTP sync with a CPU that has drifted several minutes is not rejected as too large.

After applying the values, restart the service:

net stop w32time && net start w32time

Verify the service is listening:

netstat -ano | findstr :123

The output must show UDP 0.0.0.0:123 *:*. If only 127.0.0.1:123 appears, w32time is bound to loopback only and will not be reachable from the PLC.

7.2 Stratum considerations

Once the PC announces itself as a time source, w32time reports stratum 1 if the LocalNTP/CMOS configuration above is in place. With a working configuration, the S7-319-3 will accept the packets. If the S7-300 still rejects the sync, confirm the PC's effective stratum with:

w32tm /query /status

Look for the Stratum line. Stratum 1 or 2 is required.

8. Diagnostics — What the S7-319-3 PN/DP Will and Will Not Tell You

A significant pain point in the field is the absence of useful NTP diagnostics on the integrated PN port. The following matrix summarizes what is actually available and what the engineer must infer.

Recommended diagnostic sequence when sync does not work:

1. On the PC, run wireshark -k -f "udp port 123" for 30 s.
2. Look for NTP client packets with source IP = CPU PN address. If none appear, the CPU is not polling — check the HW Config download.
3. If requests appear but no replies are seen, the PC is not yet in NTP server role — re-check Section 7.
4. If requests and replies appear, the CPU should sync within the next interval. If the clock still does not change, the reply is being rejected — check stratum and MaxPhaseCorrection on the PC.

9. Verification Procedure

1. In STEP 7, go Online & Diagnostics > Time for the CPU and note the displayed time.
2. Wait one full interval (10 s by default) plus a margin of 5 s.
3. Refresh the Time view. If the displayed time now matches the PC's wall-clock time within 1 s, NTP sync is working.
4. Cross-check by manually setting the CPU clock to a deliberately wrong value (e.g., 5 minutes fast), waiting one interval, and confirming the value snaps back to the correct time.
5. Reboot the CPU. The RTC must retain the synchronized time across a power cycle; this proves the value was written to the hardware clock, not just the OB1 date-and-time variable.

If the time does not snap back, NTP is either not polling or not being accepted. Go to Section 8 diagnostics and re-check the Wireshark trace and PC stratum.

10. Safety Warning — Disabling a Broken Time Sync

Symptoms of the runaway-clock failure:

• Any attempt to set the CPU clock with SET_CLKS / SET_TIME / Online > Set Time is immediately overwritten within a few seconds.
• Time-jump events appear in the CPU diagnostics buffer as repeated "Time-of-day synchronization via NTP" entries with the time delta increasing.
• Driven applications (shift logs, batch records, scheduled OB10 interrupts) execute at wrong times.

Recovery procedure:

1. Connect to the CPU with STEP 7 over the PN interface.
2. Open HW Config online.
3. Double-click the PN port > Time-of-day Synchronization tab > uncheck "Enable time synchronization via NTP server".
4. Compile and download the corrected HW Config to the CPU.
5. Set the clock manually via Online & Diagnostics > Set Time and verify the value persists across one full polling interval of the previously broken NTP config (no longer in service) and one full CPU restart.
6. If the clock continues to drift back to a wrong value, the CPU's battery is weak — replace the backup battery (order number 6ES7 971-1AA00-0AA0 for the S7-300 family) before re-enabling any time sync.

11. Troubleshooting Matrix

12. Best Practices for Production Deployment

1. Use a dedicated NTP appliance or domain controller rather than a Windows workstation. The PLC's stratum requirement and the w32time quirks on XP SP3 / Windows 7 are eliminated by a hardware NTP server (e.g., a Meinberg LANTIME or any GPS-disciplined NTP appliance on UDP/123).
2. Document the NTP source IP and stratum in the project documentation. If the PC is replaced, the engineer needs to know what w32time configuration to apply on the new machine.
3. Set the synchronization interval to 60 s or longer for stable installations. The 10 s default in STEP 7 is fine for commissioning but generates unnecessary load on w32time.
4. Disable NTP sync during firmware updates on the S7-319-3. A firmware upgrade momentarily removes the PN interface; the CPU will mark the NTP source as unreachable, which is benign but pollutes the diagnostic buffer.
5. Add a CPU diagnostic OB82 / OB86 handler that pages on PN-IO faults. A loss of the NTP server is not a CPU STOP cause, but it is a process event worth logging.
6. Validate with a script after download. A simple PowerShell or Python NTP query against the same server confirms the upstream is healthy before commissioning the PLC.

13. Sizing and Timing Reference

For a typical installation with a 10 s poll interval and a 100 Mbit/s PROFINET network, the bandwidth cost of NTP is negligible. The NTP packet is 48 bytes for IPv4 client mode. The S7-300 NTP client opens one UDP/123 socket per CPU and sends one packet per interval.

14. Frequently Asked Questions