The guard door opens once and gets recorded twice: 06:41:12.310 in the Logix log, 06:41:12.650 in the S7-1500’s diagnostics buffer. The two controllers are eight metres apart on the same machine, both nominally synchronised, and the gap is a third of a second every time you look.
Neither clock is broken. The Logix side is taking its time of day from CIP Sync, which is IEEE 1588 PTP, and the S7-1500 is taking its from NTP, whose honest working accuracy is tens to hundreds of milliseconds and occasionally seconds. Three hundred and forty milliseconds is inside the specification of the slower protocol. You cannot argue it down; you can only decide which timestamps you are going to believe, and put both halves on one reference so the answer is at least consistent.
What makes this confusing is that IEEE 1588 is present on both networks and is doing a different job on each.
Why 1588 on both networks is not the same thing
On EtherNet/IP, 1588 distributes the time of day. On PROFINET, its descendant distributes the transmit cycle.
CIP Sync is the EtherNet/IP application of the IEEE 1588 standard, and the thing it moves around the network is the time itself: a grandmaster holds it, boundary and transparent clocks pass it on with the transit delay corrected out, and ordinary clocks in controllers and I/O modules discipline themselves to it. PROFINET’s version is PTCP, the Precision Transparent Clock Protocol, also based on IEEE 1588, and what Siemens says it provides is a time delay measurement between RJ45 ports and, from that, the send clock and time synchronisation for isochronous traffic. That is the cycle on which the IO system transmits. It is a real and demanding piece of synchronisation and it has nothing to do with the date and time on a diagnostic entry, which on an S7-1500 comes from somewhere else entirely: the PN/IE interface makes the CPU an NTP client. Two protocols, one ancestor, and the one you need for a fault record is only on one of the two networks.
So the question “is 1588 running?” has a different answer on each side of the cell, and neither answer tells you what you wanted to know.
One reference at the top, two entirely separate paths down. The red lines are the two settings that ship switched off.
Both halves ship with their clocks switched off
This is the part worth checking before anything else, because it is true far more often than it should be.
On the Siemens side the NTP client is deactivated by default and is enabled in the CPU properties, under Time of day, then Time synchronization, then NTP mode. You can give the CPU up to four servers, and if you would rather not hard-code them, there is a setting that takes the server addresses from DHCP instead — useful on a fleet of identical machines, awkward on a machine that has to run when the DHCP server does not. On the Rockwell side the Logix controller has an Enable Time Synchronization checkbox on the Date/Time tab of Controller Properties, and if it is not ticked the controller has a real-time clock and nothing disciplining it. The switches are the same story: the Stratix manual says PTP is disabled on the Fast Ethernet and Gigabit Ethernet ports by default and that you enable it per port, and it also says that in Forward mode and End to End Transparent mode all ports are PTP-enabled. Do not resolve that from memory. Open the switch’s PTP page and read what the mode actually is before you assume anything about which ports carry it.
A cell where both sides are set up correctly and nobody ticked two checkboxes looks exactly like a cell with a timing problem.
The switch mode almost nobody changes
Forward is the default, and Forward means the switch is not participating at all.
In Forward mode the switch passes PTP packets as ordinary multicast traffic, which is fine as a pass-through and useless as a clock: the packet crosses the switch, picks up whatever queueing delay it picks up, and nothing corrects for it. Boundary mode makes the switch a real participant — it joins the best master clock election, becomes a child of the best clock it can see and a parent to everything on its other ports, and it removes a layer of jitter as it goes. The limit on Boundary mode is worth knowing before you design a topology around it: jitter and errors accumulate in cascaded topologies, and the manual says to choose Boundary mode only for networks with fewer than four layers of cascaded devices. End to End Transparent mode corrects for the residence time of every packet that passes through and accumulates less error than Boundary, but it does not work with redundant gateways in a DLR. Peer to Peer Transparent mode exists, is not compatible with End to End, and is explicitly not used in CIP Sync applications, so on a Rockwell cell it is the one to leave alone. Ring topologies cascade boundary clocks and will cost you accuracy — the CPwE time work tested rings with six switches plus two distribution switches and said plainly that this reduces clock accuracy compared with a redundant star.
There is one more limitation that catches people who bond uplinks: Stratix switches and Cisco Catalyst switches do not support PTP over EtherChannels.
The row that settles most arguments is the second one. The same standard is doing two different jobs.
Who becomes the master, and why you should decide rather than let it happen
The election runs continuously and it will pick something whether you have an opinion or not.
The best master clock algorithm compares candidates on an ordered list of attributes: priority1 first, then clock class, clock accuracy, clock variance, priority2, clock identity and finally steps removed. The first and the fifth of those are yours to set, and that is the whole point of them — the algorithm will always pick the best clock it can see, but the clock you want as grandmaster and the clock the algorithm thinks is best are not automatically the same device. Set priority1 on the module you intend to be the reference, set it again on the one you intend to take over, and now the failover is something you chose. A 1756-TIME with its internal GPS receiver as the source is the obvious primary: it is disciplined to the satellites, it outputs CIP Sync time, and its priority values are there to make it the primary or the secondary grandmaster as you please.
Leave the priorities at their defaults and the grandmaster is whichever device happened to win on clock identity. That is a serial number deciding your time reference.
The one place the two halves can actually meet
A single module can feed both networks, and that is the cleanest answer to the 340 ms.
The 1756-TIME will, optionally, run as an NTP server as well, at which point it is a stratum 1 source for anything that can only speak NTP — including the S7-1500. Point the CPU’s NTP mode at it and both halves of the cell are now referenced to the same GPS-disciplined clock, and the residual disagreement is the difference between what PTP can hold and what NTP can hold rather than the difference between two unrelated clocks. The other route is a Stratix 5400 or 5410 in NTP-PTP Clock mode, where the switch is the grandmaster for the PTP domain and takes its own time of day from NTP; the manual’s prerequisites are to configure NTP first, with two or more time sources as a practice rather than the bare minimum of one, to make sure the NTP clock is stable before you start, and to know the priority settings of the other PTP devices so that the switch ends up as grandmaster and not a runner-up. If the Siemens side is behind a CP 1543-1 rather than the CPU’s own port, that module does its own NTP — up to four servers, secure or non-secure but never mixed — and hands the synchronised time to the CPU across the backplane.
None of that makes NTP as good as PTP. It makes both logs wrong in the same direction, which is what you need to line up a sequence of events.
A constant offset across all four events is the signature of two references, not of a slow network. A varying offset would be a different problem.
The failover nobody tests
PTP does not run on UTC, and the day you find that out is the day the grandmaster fails.
The PTP timescale uses TAI, and the grandmaster is responsible for sending the offset between TAI and UTC so that everything downstream can present a sensible wall-clock time. If the grandmaster drops out and the device that takes over runs a different timescale, or carries a different UTC offset, the time visible to the application shifts during the transition — and the CPwE time guide warns that this can be a significant disruption. That is why the advice is to configure the secondary grandmaster with the same timescale and the same UTC offset as the primary, and it is why a failover is a thing to test deliberately on a quiet shift rather than discover on a busy one. Pull the primary, watch what the controllers’ clocks do, and put it back.
What to do before you trust the next timestamp
Go and look at four things, in this order. Is Enable Time Synchronization ticked in the Logix controller, and is the NTP client actually enabled in the S7-1500’s properties. What mode is the Stratix in — if it says Forward, nothing on that switch is correcting anything. Which device is grandmaster right now, and did anybody choose it. And what are the two halves referenced to: one source, or two. Once those are settled, the residual difference between the logs is a real number you can quote instead of an argument, and the data logging and monitoring setup downstream of it becomes worth something. If your timing requirement is tighter than a cell-wide fault record — a motion axis rather than a log — that is a different mechanism again, closer to the distributed clock approach than to anything here, and the network layout itself starts to matter as much as the protocol.