CIP Sync Explained: IEEE 1588 PTP for Industrial Networks

When a six-axis servo system has to coordinate moves across drives that may be sitting in different cabinets, on different switches, in different rooms — sub-microsecond timing matters. When a sequence-of-events recorder needs to log which fault tripped first across a network of distributed I/O — microsecond timing matters. When a process control application needs to correlate data from sensors connected to different controllers — millisecond timing might do, but microsecond timing is better.

CIP Sync is how CIP networks deliver that timing. It is the time synchronization mechanism that lets devices across a CIP network maintain a shared concept of time accurate to fractions of a microsecond. CIP Sync is built on top of IEEE 1588 (IEC 61588) — Precision Time Protocol (PTP) — a standard designed specifically for distributed measurement and control systems.

This article explains CIP Sync from ODVA Volume 1, Section 5-47: how it works, what objects implement it, what PTP brings to the table, and what engineers need to know about deploying it. It is the foundational article for CIP Motion (Rockwell’s distributed motion strategy) which uses CIP Sync underneath.

For broader CIP context, see the CIP Protocol Complete Guide and the CIP Object Model Explained article.

What CIP Sync is in one paragraph

CIP Sync is the time synchronization technology for CIP networks, defined in ODVA Volume 1 Section 5-47. It allows accurate real-time synchronization of devices and controllers connected over CIP networks that require time stamping, sequence-of-events recording, distributed motion control, and other applications needing increased control coordination. CIP Sync is based on IEEE 1588 (IEC 61588) — the Precision Time Protocol (PTP) — which provides a standard mechanism to synchronize clocks across distributed devices. CIP Sync defines the Time Sync Object (Class 0x43) as the CIP interface to IEEE 1588 functionality, plus an offset clock model that handles step changes in master clock time without disrupting local cyclic operations. CIP Sync is the foundation for CIP Motion — Rockwell’s distributed motion control strategy.

Why CIP Sync exists

Modern industrial systems often need to do things in coordination across distributed devices:

• Motion control across multiple drives — six-axis robots, multi-axis machines where each axis is a separate drive on the network, all needing to move in synchronized trajectories
• Sequence of events recording — across a plant, when a fault occurs, knowing which event happened first (down to microseconds) tells you which one caused the cascade
• Coordinated process control — process plants where reactions, mixing, and flow control depend on tightly-correlated data from sensors connected to different controllers
• High-speed packaging and converting machines — multiple servo drives synchronized to deliver coordinated motion at production speeds

Without precise time synchronization, “do this at exactly time T” becomes meaningless — every device has a slightly different idea of when “time T” is. With CIP Sync, every device on the network maintains a local clock that is disciplined to a common master clock, accurate to sub-microsecond levels in hardware-assisted implementations.

The challenge is that ordinary network communication has variable latency. Sending a “what time is it?” message and getting back “12:34:56.789” doesn’t tell you the actual time when you read the reply — the message was somewhere in the network for some unknown amount of time. PTP solves this by exchanging multiple timestamped messages and using the differences to compute network delay and clock offset separately. The result: clocks across the network converge to within fractions of a microsecond.

The IEEE 1588 PTP foundation

CIP Sync is built on IEEE 1588 (also published as IEC 61588) — the Precision Time Protocol. The standard was designed for local area networks like Ethernet but is not limited to them. The IEEE 1588 standard text describes its goals:

“The IEEE 1588 standard specifies a protocol to synchronize independent clocks running on separate nodes of a distributed measurement and control system to a high degree of accuracy and precision. The clocks communicate with each other over a communication network. In its basic form, the protocol is intended to be administration free. The protocol generates a master slave relationship among the clocks in the system.”

Key PTP characteristics:

• Master-slave relationship — one clock per subnet serves as the master, others as slaves
• Automatic master selection — the Best Master Clock Algorithm (BMCA) selects masters without user intervention
• Hierarchy via grandmaster clock — one clock at the top serves as the absolute time reference
• Hardware-assist capable — when implemented with timestamp hardware, PTP achieves sub-microsecond accuracy
• Network topology aware — boundary clocks handle multi-segment networks correctly

CIP Sync uses PTP version 1 (the original 2002 spec). Some industrial Ethernet implementations now use PTPv2 (IEEE 1588-2008), which improves accuracy and adds new transport options. CIP Sync deployments increasingly support PTPv2 in modern hardware while remaining compatible with the original.

Clock types: Grandmaster, Boundary, Ordinary

PTP distinguishes between three types of clocks based on their network role:

Ordinary clock

A clock with a single PTP port — meaning it connects to one network segment only. Most field devices implementing CIP Sync are ordinary clocks: simple slaves that receive time from the master without participating in network topology decisions. Examples: a 1734-AENTR Point I/O block, a simple drive, a single-port PLC.

Boundary clock

A clock with multiple PTP ports — meaning it sits between network segments. Boundary clocks are typically network switches that implement PTP on each port. A boundary clock acts as a slave on one side (receiving time from its master) and as a master on the other side (distributing time to downstream slaves). This eliminates the fluctuations that ordinary network elements would introduce.

Industrial Ethernet switches that “support CIP Sync” or “support IEEE 1588” are boundary clocks. Without them, PTP precision degrades as messages traverse multiple network elements.

Grandmaster clock

Within a collection of PTP clocks, one clock — the grandmaster — serves as the primary source of time to which all others ultimately synchronize. The grandmaster is usually:

• A GPS-disciplined time source (most accurate, externally referenced to UTC)
• An NTP-disciplined controller (good accuracy, referenced to internet time)
• A user-designated PLC with HAND-set time (least accurate but doesn’t require external infrastructure)

The grandmaster role can be automatic (selected by BMCA based on clock quality announcements) or fixed (configured to remain grandmaster regardless of better clocks appearing).

Master clock

When a system has boundary clocks, the PTP network divides into regions separated by those boundary clocks. Within each region there is a master clock — the primary time source for that region. Master clocks synchronize to other master clocks, and ultimately to the grandmaster. So in a multi-region network, there’s one grandmaster and several local master clocks (each one is the master within its region but a slave to a higher master).

PTP message types

Per IEEE 1588, PTP defines five message types for synchronization:

The synchronization sequence:

1. Master sends Sync carrying its current time T1 (the timestamp the master made when transmitting)
2. Slave receives Sync at its local time T2; records both T1 and T2
3. For hardware-assist: master also sends Follow-up with the more accurate T1 if Sync didn’t carry it
4. Slave sends Delay_Req at its local time T3
5. Master receives Delay_Req at its local time T4
6. Master sends Delay_Resp with T4
7. Slave computes:
   • Network delay = ((T2 – T1) + (T4 – T3)) / 2
   • Clock offset = ((T2 – T1) – (T4 – T3)) / 2
   • Slave adjusts its clock to remove the offset

This sequence repeats periodically (typically once per second for Sync, less often for Delay_Req). The result: the slave maintains a continuously-corrected view of master time despite variable network delay.

Best Master Clock Algorithm (BMCA)

The BMCA is the algorithm that selects which clock should be the master. Every PTP-capable clock runs the same algorithm. The basic rule:

If a port of a master clock receives a Sync message from a better clock, then that port will cease to claim to be a master and the receiving port will assume the status of a slave. Likewise if a clock with a port acting as a slave determines that it would make a better master than the current master clock (or if there is no current master clock), it assumes the status of master.

“Better clock” is determined by several attributes carried in Sync messages — clock class (how accurate the clock source is), priority values, accuracy estimates, etc. GPS-disciplined clocks beat NTP-disciplined clocks; NTP-disciplined clocks beat HAND-set clocks.

Some devices are configured as slave-only — they never assume the master role regardless of BMCA results. This is appropriate for simple I/O blocks and field devices.

The BMCA’s strength: automatic self-organization. Plug in a new device with a better clock source, and the network reorganizes around it. Disconnect the grandmaster, and the network elects a new one. No manual configuration required.

CIP Sync System Time

Per Volume 1 Section 5-47.4, CIP Sync defines System Time as the shared time concept across the network:

System Time represents the current time at the 0th meridian (Greenwich), adjusted for leap seconds. A timestamp of 1719360000000000000 (in nanoseconds) means a specific moment in 2024 — the same moment everywhere on the network.

PTP’s native time representation is a TimeRepresentation structure: a 32-bit “seconds since epoch” field and a 32-bit “nanoseconds” field. CIP Sync converts this to its LINT System Time format:

SystemTime = PTPTime - LeapSeconds

The current_utc_offset field carries leap second information. As of 2026, the offset is 37 seconds (the last leap second was June 30, 2017; recent international consensus has paused further leap seconds until at least 2035).

The offset clock model (CIP Sync’s innovation)

Per Volume 1 Section 5-47.6, CIP Sync defines an offset clock model that addresses a critical industrial control requirement: stable cyclic operations even when the master clock makes step changes.

Why step changes happen

Step changes in master clock time can occur from:

1. User adjusts the master clock (e.g., manually setting time on a HAND-set master)
2. A new master appears with a more accurate clock (BMCA reselection during system runtime)
3. Master disconnected and reconnected — when reconnected, any time drift becomes a step change

In a naive synchronization model, these step changes would propagate to every slave’s local clock — meaning local cyclic events (like a 1 ms motion update) might suddenly happen at the “wrong” local time relative to other local events. Process control loops would see discontinuities. Motion trajectories could glitch.

The offset clock solution

CIP Sync handles this with a local clock + offset design:

                                    PTP Time Master
                                          │
                                          │ small frequency tuning only
                                          ▼
            ┌─────────────────────────────────────────────────┐
            │  Local Clock (Frequency Disciplined Timer)      │
            │  - Free-running oscillator                      │
            │  - Frequency tuned by PTP to match master rate  │
            └─────────────────────────────────────────────────┘
                                +
            ┌─────────────────────────────────────────────────┐
            │  System-to-Local Clock Offset                   │
            │  - Adjusted to bridge to System Time            │
            │  - Updates absorb step changes                  │
            └─────────────────────────────────────────────────┘
                                -
                            Leap Seconds
                                =
                          System Time

The PTP master frequency is what disciplines the slave’s local clock — it ticks at the same rate as the master. But the slave maintains a separate offset value that, when added to the local clock and adjusted for leap seconds, yields System Time.

When a step change occurs at the master:

• The slave’s local clock keeps ticking at the same rate (no disruption)
• The slave’s offset value updates to reflect the new System Time relationship
• Local cyclic events (scheduled against the local clock) continue uninterrupted
• Code that needs System Time gets the new, corrected value via the offset

This dual-clock design is what makes CIP Sync practical for industrial control. Local motion loops, cyclic I/O, and process control timing operate against the stable local clock. Anything requiring absolute time (logging, scheduling, network-wide coordination) uses System Time through the offset.

Accuracy levels — hardware vs software clocks

Per Volume 1 Section 5-47.5.1:

The difference: hardware-assist clocks timestamp PTP packets at the network interface in hardware, eliminating the unpredictable software stack delay. Software-only clocks must timestamp in the protocol stack, introducing variable latency from CPU scheduling, interrupt handling, and software pipeline depth.

For applications requiring sub-microsecond accuracy (multi-axis motion, high-speed packaging machines), all participating devices and intermediate switches need hardware-assist PTP support. For applications where tens-of-microseconds is acceptable (event recording, slow motion, process control coordination), software PTP may suffice.

When deploying CIP Sync:

• Check device documentation for PTP accuracy claims
• Use industrial managed switches with PTP boundary clock support rather than unmanaged switches
• Avoid daisy-chained unmanaged switches — every hop without PTP support adds jitter

Time Sync Object (Class 0x43)

CIP Sync exposes its functionality through the Time Sync Object (Class Code 0x43) per Volume 1 Section 5-47.11. Every CIP Sync-capable device has one instance of this object at instance 1.

Common attributes of the Time Sync Object

The object exposes attributes covering:

• PTP Enable — whether PTP is enabled on this device
• Is Synchronized — whether the local clock is currently synchronized to a master
• System Time — current System Time value (in microseconds since epoch)
• Offset From Master — current offset between local clock and master
• Local Clock Offset — the system-to-local-clock offset value
• Mean Path Delay — estimated network path delay to the master
• Grandmaster Clock Info — identification of the current grandmaster
• Parent Clock Info — the immediate upstream master
• Sync Interval, Announce Interval — PTP message timing parameters
• Current UTC Offset — leap seconds adjustment in effect
• Time Sync Status — current synchronization state (initializing, faulty, master, slave, etc.)

Engineering tools and PLCs use these attributes to monitor the synchronization state. A PLC reading “Is Synchronized = 0” knows its clock isn’t trusted; reading “Time Sync Status = Slave, Offset From Master = -47 ns” knows it’s tracking the master within 47 nanoseconds.

For broader CIP object coverage, see our CIP Object Model Explained article.

Services

The Time Sync Object supports the standard common services:

A typical diagnostic call: Get_Attribute_Single on Class 0x43, Instance 1, Attribute X (where X varies by what specifically you want to read).

How CIP Motion uses CIP Sync

CIP Motion (Class Code 0x42, defined in Volume 1) is Rockwell’s strategy for distributed motion control over standard EtherNet/IP. Multiple drives can be coordinated across the network instead of via a dedicated motion bus (like SERCOS or EtherCAT).

The critical requirement: every drive must execute its motion update at the same instant relative to a network-wide time reference. CIP Motion uses CIP Sync as that time reference. Each drive maintains its local clock synchronized via PTP, and motion commands include timestamps that all drives interpret against the same System Time.

This is why CIP Sync support is a hard requirement for CIP Motion devices — without sub-microsecond synchronized time across the drives, distributed motion coordination is impossible.

For more on this architecture, see our future “CIP Motion Explained” article (in development).

Quality of Service (QoS) for CIP Sync

Per Volume 1 Section 5-47.9, CIP Sync recommends specific QoS settings to ensure PTP messages get preferential treatment on the network:

When deploying CIP Sync alongside heavy I/O traffic on the same network, configure switches to give PTP traffic priority. Without QoS configuration, congestion can introduce jitter that degrades synchronization accuracy.

For broader IGMP/multicast deployment guidance, see our EtherNet/IP I/O Messaging on UDP Port 2222 article.

Diagnosing CIP Sync issues

Common CIP Sync deployment problems and how to diagnose them:

Reading CIP Sync state via Get_Attribute_Single

Service: 0x0E (Get_Attribute_Single)
Path:    Class 0x43, Instance 1, Attribute X

For X, common useful values:

• Is Synchronized (BOOL)
• System Time (LINT)
• Offset From Master (LINT, signed)
• Mean Path Delay (LINT, signed)
• Current UTC Offset (INT)

Reading these in sequence (or all at once via Get_Attributes_All) gives a complete picture of the device’s synchronization state.

CIP Sync vs other industrial time sync protocols

For context, here’s how CIP Sync compares to other industrial time synchronization mechanisms:

All sub-microsecond protocols share the same fundamental challenge — accurate hardware timestamping at the network interface — but each takes a different approach. CIP Sync leverages the IEEE 1588 standard widely used outside industrial automation as well, which means more options for compatible hardware.

For comparison with PROFINET, see our PROFINET vs EtherNet/IP Comparison article.

Frequently asked questions

What is CIP Sync?

CIP Sync is the time synchronization technology for CIP networks (EtherNet/IP, DeviceNet, ControlNet, etc.). It’s based on IEEE 1588 (IEC 61588) — the Precision Time Protocol (PTP) — and provides sub-microsecond clock synchronization across distributed CIP devices. CIP Sync is defined in ODVA Volume 1 Section 5-47 and exposed through the Time Sync Object (Class 0x43). It is the foundation for CIP Motion (distributed motion control over EtherNet/IP).

What is IEEE 1588 PTP?

IEEE 1588 — also published as IEC 61588 — is the Precision Time Protocol (PTP) standard. It specifies a protocol to synchronize independent clocks across networked devices to high accuracy and precision. PTP uses periodic Sync messages from a master clock and Delay_Req/Delay_Resp exchanges from slaves to compute network delay and clock offset separately, enabling sub-microsecond synchronization on properly equipped hardware.

What is the class code for the Time Sync Object?

The Time Sync Object has Class Code 0x43 (decimal 67). Defined in ODVA Volume 1 Section 5-47, it provides a CIP interface to IEEE 1588 functionality. Every CIP Sync-capable device implements one instance of this object at Instance 1. Engineering tools read its attributes to monitor synchronization status.

What is a grandmaster clock in CIP Sync?

A grandmaster clock is the primary source of time to which all other clocks in a PTP system are ultimately synchronized. It’s usually a GPS-disciplined time source (most accurate), an NTP-disciplined controller, or a user-designated PLC with manually-set time (least accurate). The grandmaster is selected automatically by the Best Master Clock Algorithm (BMCA) or can be configured as a fixed grandmaster. There is one grandmaster per PTP system.

What is a boundary clock?

A boundary clock is a PTP clock with multiple PTP ports — typically an industrial Ethernet switch that implements PTP on each port. It acts as a slave on one side (synchronizing to its upstream master) and as a master on the other side (distributing time to downstream slaves). Boundary clocks eliminate the timing fluctuations that ordinary network elements would introduce, enabling sub-microsecond accuracy across multi-segment networks.

What is the Best Master Clock Algorithm?

The Best Master Clock Algorithm (BMCA) is the procedure PTP uses to automatically select which clock should be the master. Every PTP-capable clock runs the same algorithm independently. When a port hears a Sync message from a “better” clock (based on clock class, priority, and accuracy attributes), it transitions to slave state. When a slave determines it would be a better master than the current one, it transitions to master. This self-organizing approach requires no manual configuration.

What accuracy can CIP Sync achieve?

With hardware-assisted PTP timestamping on all devices and switches in the path, CIP Sync achieves sub-microsecond accuracy (typically < 1 microsecond). With software-only PTP implementations, accuracy degrades to tens of microseconds. For applications requiring high accuracy — multi-axis motion control, high-speed packaging — all participating devices and intermediate switches must have hardware-assist PTP support.

What is CIP Sync System Time?

System Time is the shared time concept CIP Sync distributes across the network. It is a 64-bit signed integer (LINT) representing nanoseconds or microseconds since the epoch (January 1, 1970, 00:00:00). System Time is adjusted for leap seconds but not for time zones or daylight savings — it represents UTC time at the 0th meridian. Every device that has synchronized to the master clock can report System Time as a consistent network-wide timestamp.

Why does CIP Sync use an offset clock model?

The offset clock model separates the local clock frequency (disciplined to master frequency by PTP) from the System Time offset (a separate value that absorbs step changes in master time). This means when the master clock makes a step change — for example, when a new grandmaster joins — the slave’s local clock keeps ticking at the same rate without disruption, and only the offset value updates. Local cyclic operations (motion loops, cyclic I/O) continue uninterrupted while System Time updates correctly.

Do I need special switches for CIP Sync?

For sub-microsecond accuracy, yes — you need industrial managed switches with PTP boundary clock support. Without PTP-aware switches, ordinary network jitter introduces variable delays that PTP cannot completely correct. Switches that simply forward PTP packets without participating in the protocol introduce accumulating timing errors. For applications tolerating tens-of-microseconds accuracy, ordinary switches may suffice.

What is the relationship between CIP Sync and CIP Motion?

CIP Motion (Class Code 0x42) is Rockwell’s distributed motion control strategy over EtherNet/IP. It allows multiple drives to be coordinated across the network instead of via a dedicated motion bus. CIP Motion requires sub-microsecond synchronized time across all participating drives — and that time synchronization is provided by CIP Sync. Without CIP Sync, distributed CIP Motion would be impossible. Every CIP Motion device must implement CIP Sync.