S7-1200 NTP Time Sync: Resolving 10s Backward Time Skew Issues

S7-1200 NTP Time Sync: Resolving 10s Backward Time Skew Issues

The S7-1200 CPU 1214 DC/DC/RLY running firmware V2.2 or V3.0 displays a characteristic asymmetry when synchronized against an NTP server. When the server clock is set ahead of the PLC clock, the CPU slews its internal time-of-day forward smoothly. When the server clock is set behind, the CPU only steps the time backward by approximately ten seconds per NTP polling cycle. Over a one-minute backward offset the catch-up takes 6 minutes; over a one-day offset it can take 144 minutes. The behavior is not a bug in the strict sense, it is a deterministic design choice implemented in the CPU firmware that engineers must understand before commissioning time-stamped archives, batch records, or event logs.

This reference covers the underlying NTP algorithm, the S7-1200 synchronization architecture, the precise configuration steps in TIA Portal, the Meinberg NTP server prerequisites, the recommended workarounds, and the verification procedures you should run before signing off on a time-synchronized system.

Problem Description: Forward Slew vs Backward Step

Engineers first encounter the issue when a S7-1200 CPU clock is allowed to drift freely and the NTP source is later corrected:

• Forward offset (server ahead of PLC): CPU slews the internal clock at approximately 5 ms/s above nominal tick rate. A 1 second offset corrects in about 200 seconds. No log entries are skipped, no timestamps are duplicated.
• Backward offset (server behind PLC): CPU applies a single step of roughly 10 seconds per NTP poll cycle. A 60 second offset requires 6 poll cycles. A 1 hour offset requires 360 cycles, which at the default 10 s update interval is one hour of catch-up time. A 24 hour backward offset takes 24 hours to fully reconcile.

The 10 second quantum corresponds to the default NTP update interval configured in TIA Portal. The S7-1200 firmware refuses to apply a step larger than the update interval to avoid producing duplicate wall-clock timestamps in the local data logs and process image archives that the PLC maintains for recipe management, alarm logging, and motion profiling.

NTP Algorithm Fundamentals: Slew vs Step

The Network Time Protocol described in RFC 5905 defines two clock-adjustment primitives: slew and step. A slew adjustment modifies the local oscillator frequency by a small amount so the wall clock advances faster or slower than nominal until the offset converges. A step adjustment sets the local wall clock directly to the new value in a single atomic write. NTP implementations choose between these two based on the offset magnitude and the configured step threshold.

The classical NTP algorithm, summarized on the NTP FAQ and the Network Time Protocol Wikipedia page, applies the following rules:

• Offset < 128 ms: slew the clock (rate adjust)
• Offset 128 ms to 1000 ms: slew, but treat as a panic if persistent
• Offset > 1000 ms: step the clock

The S7-1200 firmware uses a much more conservative policy. Even at multi-second or multi-minute offsets it refuses to perform a single full step backward, and instead issues a series of partial steps gated by the NTP poll interval. This protects the integrity of any in-progress recipe, batch, or audit-trail record on the PLC.

Public NTP services such as Google Public NTP and the NIST Authenticated NTP Service provide high-availability time references, but the asymmetry is enforced on the client (the PLC), not the server, so the choice of upstream NTP source does not change the catch-up rate.

S7-1200 Time Synchronization Architecture

The S7-1200 family supports two primary time-of-day synchronization paths and one auxiliary path:

For most greenfield installations the NTP path is preferred because it does not require a SIMATIC master, scales across plant networks, and tolerates server failover. The SIMATIC time-of-day path remains in use where deterministic, cell-local synchronization is required.

Internally the CPU maintains a 64-bit system time referenced to the Unix epoch (1970-01-01 00:00:00 UTC). The user-visible DTL (Date_And_Time_Long) format breaks this into year, month, day, hour, minute, second, and nanosecond fields. NTP packets carry the offset between the CPU time and the server time, and the firmware applies the asymmetric adjustment described above directly to the 64-bit counter.

Root Cause: Asymmetric Forward/Backward Adjustment

The firmware implements a deliberate split:

• Forward correction uses a programmable tick-rate adjustment. The internal 1 ms tick is stretched or compressed by up to a few parts per thousand. No wall-clock discontinuity is produced, so no log entry is skipped.
• Backward correction uses a guarded step. The step magnitude is capped at the NTP update interval to guarantee that no two logged events ever share a timestamp. Each subsequent poll repeats the step until the offset is fully absorbed.

Mathematically, for a backward offset of T_off seconds and an NTP update interval of I seconds, the convergence time is T_off × (1 second per I seconds) when I is in seconds, or simply:

T_catchup = T_off × I / I_step

where I_step is the step quantum the firmware applies per poll (in practice equal to the configured update interval). With the default I = I_step = 10 s, the ratio is 1:1, so backward catch-up takes wall-clock time equal to the magnitude of the offset.

The firmware does not expose a "full step backward" mode and does not accept a configuration change that would alter the asymmetric behavior. The mitigation is to prevent the asymmetric scenario in the first place by holding the NTP server time as close as possible to the PLC time, and by aligning the PLC time to the server before the PLC enters production logging.

Prerequisites for NTP Configuration

Confirm the following before opening TIA Portal:

• TIA Portal V13 SP1 or later installed (V16 or later recommended for CPU firmware V4.x)
• S7-1200 CPU with part number matching the firmware in use. The CPU 1214 DC/DC/RLY ships in part-number families: 6ES7214-1AD23-0XB0 (firmware V2.2), 6ES7214-1AE30-0XB0 (firmware V3.0), 6ES7214-1AG40-0XB0 (firmware V4.4), 6ES7214-1BH50-0XB0 (firmware V4.5). The asymmetric NTP behavior has been observed across V2.2, V3.0, and remains in V4.x firmware.
• CPU is online reachable via PROFINET or Ethernet and the IP address is known
• At least one NTP server is online reachable from the CPU on UDP 123. Meinberg NTP server on Windows, Google Public NTP at time.google.com, or a local Meinberg LANTIME appliance are all compatible.
• Any firewall between the CPU and the NTP server must allow outbound UDP 123. Stateful inspection on industrial firewalls is preferred over stateless ACLs.

Configuring NTP in TIA Portal

1. Open the TIA Portal project that contains the S7-1200 station.
2. Expand Devices & Networks in the project tree and double-click the S7-1200 CPU device icon to open the device view.
3. Select the CPU in the device view, then open Properties > General > Time of day in the inspector pane.
4. Set Time synchronization to Enable NTP. Older TIA Portal versions (V13 SP1 through V15) use a checkbox labeled Activate time synchronization via NTP server.
5. Configure up to four NTP servers in priority order. The CPU polls server 1 every update interval, falls over to server 2 after three unanswered polls, and so on. Enter either the IP address (recommended) or the fully qualified domain name. Domain name resolution requires a DNS server IP to be set in the PROFINET interface properties.
6. Set the Update interval. The default is 10 s. Acceptable range is 1 s to 16 hours. The interval directly controls the backward step quantum, so a 5 s interval halves the catch-up time for backward offsets, while a 30 s interval doubles it.
7. Set the Time zone and Daylight saving time rules to match the plant location. The CPU stores UTC internally and applies the local offset when reading the time-of-day clock for user programs.
8. Click Project > Compile > Hardware (rebuild all) and download the configuration to the CPU. Confirm the prompt for STOP-to-RUN transition; S7-1200 applies the new NTP settings on the next STOP-to-RUN transition without losing retain data.

Parameter Mapping

The CPU accepts only unsecured NTP packets by default. To enable authenticated NTP, supply a symmetric key in the S7-1200 user program through the system function block RD_NTP (extended library in TIA Portal V15.1 and later). The NIST Authenticated NTP Service is a useful reference for the symmetric-key protocol.

Meinberg NTP Server Reference Setup

The Meinberg NTP server on Windows is a common reference time source. It uses the standard ntpd engine and exposes the same configuration surface as the open-source package. To prepare the server for the S7-1200 CPU 1214:

1. Install Meinberg NTP for Windows from the official Meinberg distribution. Confirm the ntpd service is running and the system tray icon shows a green status.
2. Open the Meinberg configuration console and confirm the server's local time source. If the host is synced to Google Public NTP (time.google.com) the upstream stratum will be 2.
3. Open Windows Defender Firewall with Advanced Security and create an inbound rule allowing UDP 123 from the S7-1200 CPU IP address only. Do not expose the Meinberg NTP service to the plant network without restriction.
4. From the S7-1200 CPU or a TIA Portal online session, run a reachability test. In the device properties Time of day tab, set the server address and wait one update interval. The CPU will display the latest offset and round-trip delay. A round-trip delay under 50 ms on a plant LAN is healthy.

The Meinberg server itself does not enforce the asymmetric step policy. That policy is implemented in the S7-1200 firmware, so the Meinberg server can be replaced with any RFC 5905 compliant NTP source and the behavior of the PLC will not change.

Workarounds for Backward Time Correction

Engineers have five practical options for the backward skew scenario. Choose the one that matches the operational constraint.

Workaround 1: Prevent the Skew in the First Place

Do not allow the NTP server time to deviate from the PLC time in production. Lock the NTP server's local time against a trusted upstream source (Google Public NTP, Meinberg reference clock, GPS-disciplined Meinberg LANTIME) and monitor offset alarms. This is the recommended baseline for any 21 CFR Part 11, GAMP 5, or ISA-95 regulated environment.

Workaround 2: Reduce the Update Interval

Setting the NTP update interval to 1 s reduces the per-poll step quantum to 1 s, so a 1 minute backward offset catches up in 60 seconds instead of 6 minutes. The trade-off is increased NTP traffic: at 1 s interval the CPU sends one packet per second continuously, which is approximately 80 bytes per second. On a plant LAN this is negligible, but on a WAN or cellular link it may matter.

Workaround 3: Set PLC Time to Server Time at Commissioning

Use WR_SYS_T (set time-of-day) at the start of commissioning to align the PLC clock to the server clock to within 1 second. Once aligned, normal drift between server and PLC is below the slew threshold and the asymmetric path is never taken.

Workaround 4: Manual Set Time to Match Server

From TIA Portal online, right-click the CPU and select Set time of day > Set to PG/PC time. This forces an immediate step adjustment. Use only during commissioning or maintenance windows because the step will be the larger of the current offset and the firmware's step guard, not the 10 s quantum.

Workaround 5: Apply a Clock-Leap Override at Next STOP/RUN

Some plant standards allow a brief STOP-to-RUN transition to force a clean resync. While the CPU is in STOP, set the time of day through TIA Portal or through an SSMT telegram from a SIMATIC master. The resync on RUN transition will be treated as the initial alignment and the asymmetric path will not apply.

Verification Procedures

Run the following checks after configuration download to confirm the asymmetric behavior is within the expected envelope:

1. Open TIA Portal online, select the CPU, and open Online & Diagnostics > Time of day. The display shows the local time, the time source (NTP server IP), the offset, and the round-trip delay.
2. Set the NTP server clock 30 seconds ahead of the PLC clock. Wait 10 minutes. The PLC should converge smoothly. The offset display should monotonically decrease toward zero.
3. Set the NTP server clock 30 seconds behind the PLC clock. Wait 5 minutes. The PLC offset display should step down in 10 s increments at 10 s intervals. If the update interval has been changed to 5 s, the steps will be 5 s.
4. Force a 5 minute backward offset. Confirm the catch-up time matches the formula T_catchup = T_off at default 10 s interval. A 5 minute offset must catch up in 5 minutes. If it does not, the update interval has been misread from the project; re-check the value in the device properties.
5. Monitor the CPU diagnostic buffer for entries with ID 0xE500 (time jump) and ID 0xE501 (time set). These are the firmware-generated entries for step adjustments. A high rate of 0xE500 entries during a short window confirms the backward step path is active.

Best Practices for Industrial Time Sync

• Use a GPS-disciplined NTP server as the plant stratum-1 source. Meinberg LANTIME, Trimble Thunderbolt, and Symmetricom NTS are common choices. The S7-1200 then operates as a stratum-2 client. This isolates the PLC from internet connectivity changes.
• Configure at least two NTP servers. S7-1200 supports up to four. The firmware polls the highest-priority server and falls over on three consecutive unanswered polls.
• Lock the update interval to 10 s for archival systems, 1 s for motion systems. Motion and high-speed event recording benefit from the faster catch-up; archive and recipe systems do not need the 1 s interval and save network bandwidth at 10 s.
• Avoid mixing time zones across plant cells. Configure all CPUs in the same cell to the same local time zone. The CPU stores UTC internally; the local offset is applied at read time, and a mismatch produces off-by-one-hour events in shared logs.
• Document the asymmetric behavior in the system FRS. Operators and validation engineers must know that backward corrections of any magnitude will produce a catch-up period equal to the magnitude. A 4 hour backward offset after a power outage takes 4 hours to fully reconcile.
• Test the sync after every firmware update. Siemens has not changed the asymmetric behavior across V2.2, V3.0, and V4.x as of this writing, but firmware updates occasionally change step-guard parameters. Re-run the 30 s backward offset test after every CPU firmware upgrade.

Troubleshooting Matrix

Interaction with Recipe and Batch Logging

The S7-1200 maintains internal logs for recipe changes, alarm acknowledgements, and (where configured) audit-trail events. Each entry carries a DTL timestamp. When a backward step is applied, the firmware guarantees that no two existing entries share the new timestamp, but only if the step quantum is at most the update interval. A 10 s quantum is sufficient to keep entries unique in the recipe and alarm logs because the smallest logged event spacing on S7-1200 is 100 ms in recipe state transitions and 1 s in alarm acknowledgement. A 1 s quantum (from the 1 s update interval workaround) is also sufficient.

What the firmware does not protect is the user's external logging system. If the PLC pushes events to a SCADA or historian, and the SCADA system performs a step on its own clock, the events in the SCADA buffer may have non-monotonic timestamps. The fix is to keep the SCADA clock synchronized to the same NTP source as the PLC, and to disable any local SCADA time-master role.

Compatibility with V4.x Firmware and S7-1200 G2

The asymmetric behavior has been carried forward into CPU firmware V4.4, V4.5, and V4.6. The S7-1200 G2 generation (6ES7214-1..50-..B0, 6ES7215-1..50-..B0, 6ES7216-1..50-..B0) preserves the same NTP client logic. The maximum supported NTP server count remains 4, and the update interval range is unchanged at 1 s to 16 hours. No firmware toggle exists to switch between symmetric and asymmetric step behavior in current releases.

The S7-1500 family exhibits the same asymmetric policy but with an additional option exposed in the device properties: Accept time from non-secured NTP and a Maximum time jump parameter that can be raised to allow a single full step when the offset is detected at CPU startup. S7-1200 firmware does not expose the Maximum time jump parameter, so the per-cycle cap remains in effect.