CIP Motion Explained (Class 0x42 Motion Axis Object)

Twenty years ago, synchronized motion across multiple servo drives required a dedicated motion bus — SERCOS, MACRO, FireWire, or a proprietary fieldbus. The motion network ran separately from the control network because standard Ethernet couldn’t deliver the deterministic microsecond timing motion needs. Today, with CIP Motion running over standard EtherNet/IP, the motion bus and the control network are the same network. Six-axis servo coordination, multi-axis packaging machines, distributed robotics — all run over the same Ethernet wire that carries discrete I/O and HMI traffic.

This article explains how CIP Motion works: the Motion Axis Object (Class 0x42) that exposes every drive’s behavior, the control hierarchy from position down to current, the CIP Sync dependency that makes the whole thing possible, and the architectural trade-offs versus dedicated motion buses. Built from ODVA Volume 1, Section 5-46.

For broader CIP context, see the CIP Protocol Complete Guide and the CIP Sync Explained article (since CIP Sync is the foundation CIP Motion runs on).

What CIP Motion is in one paragraph

CIP Motion is the ODVA-defined technology for distributed motion control over standard CIP networks — primarily EtherNet/IP. It is implemented through the Motion Axis Object (Class Code 0x42) defined in Volume 1 Section 5-46. Per the spec, the Motion Axis Object is “the main functional component of CIP Motion device profiles” — its instances appear on every CIP Motion-capable device (servo drives, stepper drives, variable-frequency drives, motion controllers). CIP Motion runs alongside ordinary I/O and explicit messaging on the same network, with CIP Sync (IEEE 1588 PTP) providing the sub-microsecond timing needed for synchronized multi-axis coordination. The result: high-performance motion control without a dedicated motion bus.

Why CIP Motion exists

For decades, machine builders faced a hardware split between two networks:

• Control network — for I/O, HMI, drives at the V/Hz level: standard fieldbus like DeviceNet, ControlNet, EtherNet/IP
• Motion network — for synchronized servo control: dedicated motion bus like SERCOS, MACRO, or FireWire

The split existed because standard Ethernet couldn’t deliver deterministic motion timing. Motion needs:

• Sub-microsecond synchronization across drives so they can execute commands “at the same instant”
• Cyclic data exchange every 1 ms or faster
• Bounded jitter — variable delay corrupts servo control loops
• Bandwidth guarantees — motion traffic must not be starved by other traffic

Standard 100 Mbps Ethernet with unmanaged switches couldn’t deliver any of these. The result: every motion-heavy machine had two physical networks, two sets of cabling, two engineering tools, two skill sets to maintain.

Two technologies changed this:

1. IEEE 1588 PTP (Precision Time Protocol) — provides the microsecond-level time synchronization. CIP networks adopted this as CIP Sync.
2. Industrial managed switches with PTP boundary clock support — eliminate jitter at network boundaries while maintaining time accuracy.

With these foundations, CIP Motion delivers motion control over standard EtherNet/IP. The same network that carries Point I/O traffic and HMI screens also carries six-axis servo coordination at production rates. From the wiring side: one network. From the engineering side: one tool (Studio 5000). From the maintenance side: one skill set.

This is the central value proposition of CIP Motion — architecture simplification through network convergence.

Motion Axis Object (Class 0x42)

Per Volume 1 Section 5-46, the Motion Axis Object is the CIP object that defines the behavior of a motion-controlled axis. Class Code 0x42 (decimal 66).

Every CIP Motion device (drive, motion-capable controller) implements one or more instances of this object — typically one instance per controllable axis. A four-axis servo drive exposes four Motion Axis Object instances; a single-axis VFD exposes one instance; a multi-axis motion controller exposes instances corresponding to each axis it commands.

The Motion Axis Object has hundreds of attributes covering:

• Configuration (gains, limits, scaling, units)
• Real-time control data (commanded position, velocity, acceleration, torque)
• Feedback (actual position, velocity, torque from sensors)
• Status (axis state, faults, alarms)
• Statistics (counters, error rates, performance metrics)
• Initialization fault status
• Start inhibit conditions
• Visualization (homing, jogging, manual operation)
• Event capture (registration, marker pulse handling)

Engineering tools like Studio 5000 expose subsets of these attributes through their motion configuration UI. Application programs (ladder, structured text, function blocks) interact with the axis through high-level instructions (MAM, MAJ, MAS, MAH, etc.) that internally translate to Motion Axis Object attribute reads and writes.

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

The motion control hierarchy

Per Volume 1 Section 5-46.2.1, the Motion Axis Object is organized around a control hierarchy that reflects the physics of motion:

        Position Control
              ↓ (requires)
        Velocity Control
              ↓ (requires)
        Acceleration Control
              ↓ (relates via inertia/mass)
        Torque/Force Control
              ↓ (relates via torque constant)
        Current Control

The spec explains the principle: position control implies velocity control, which implies acceleration control, which relates to torque via inertia, which relates to current via the torque constant. Each layer above depends on the layer below. A pure position-loop drive has all four control loops cascaded inside it: an outer position loop, a velocity loop, an acceleration loop, and a current/torque loop.

This hierarchy matters because:

1. You can address motion at any level. Need precise position? Use Position Control. Need precise speed with no position requirement? Use Velocity Control. Need direct torque application (tension control, force control)? Use Torque Control.
2. The relationship between layers is not always linear. Inertia changes with position (a robot arm has different inertia depending on extension). Torque constant changes with motor flux and temperature. CIP Motion lets the controller and drive negotiate these relationships dynamically.
3. Different drives implement different subsets. A simple VFD does V/Hz frequency control only. A stepper drive does open-loop position control. A vector drive includes a torque/current loop. A servo drive includes all four loops with feedback at the position layer.

Control modes

The Motion Axis Object exposes these primary control modes:

Position Control

Either the application program (command execution function) or the motion planner (move trajectory function) provides a position set-point to the drive cyclically. The drive matches commanded position via its internal control loops.

Position control can be:

• Open loop (stepper drives) — no feedback; drive estimates actual position based on step commands
• Closed loop (position servo drives, vector drives with position feedback) — feedback sensor (encoder, resolver) drives the actual position to match commanded position

Velocity Control

The application provides a velocity set-point. The drive matches commanded velocity. Common for:

• Spindle speed control
• Conveyor speed control
• Mixer/pump speed control where exact position doesn’t matter

Acceleration Control

The application provides an acceleration set-point. Less common in field equipment but used in some specialized applications.

Torque Control

The application provides a torque set-point. The drive matches commanded torque. Common for:

• Tension control (web handling, wire winding)
• Force control (press operations)
• Coordinated tension among multiple driven rolls

No Control (Frequency Control)

The application provides a frequency set-point (V/Hz operation). The drive runs the motor at the commanded frequency without closed-loop velocity feedback. This is the traditional V/Hz mode for simple AC drives.

Switching between modes

CIP Motion allows the application to switch control modes at runtime — e.g., position control during a coordinated move, then switch to torque control to apply a controlled clamp force at the end of the move. The Motion Axis Object exposes the current mode through specific attributes, and the application transitions modes through service requests.

Open loop vs closed loop control

Per Volume 1 Section 5-46.2.2:

Closed loop drives can also operate in sensorless mode, where feedback is derived from motor excitation signals rather than a physical sensor. Sensorless vector control gives some closed-loop benefits without an encoder/resolver. Position-loop drives almost always have a physical feedback sensor.

Drive types CIP Motion supports

Per Volume 1 Section 5-46.2, the Motion Axis Object is designed to cover a wide range of drive types:

The spec notes that “rotary applications speak of Torque and Inertia while linear applications speak of Force and Mass” — the same Motion Axis Object handles both, with the application substituting terminology as appropriate.

Many drive products are configurable to operate in multiple modes. A vector drive with feedback can be configured as a position servo for one application, velocity servo for another, torque servo for a third. CIP Motion exposes these capabilities through the Motion Axis Object’s mode-selection attributes.

How CIP Motion uses CIP Sync

This is the foundation everything else stands on. Per the spec, CIP Motion devices require synchronized time across the network to sub-microsecond accuracy. Without that, distributed multi-axis coordination is impossible.

The reason: a multi-axis coordinated move requires every drive to execute its commanded position at the same instant. If one drive’s clock is 100 microseconds ahead of another’s, position commands that should arrive simultaneously instead arrive at different times — and the coordinated motion glitches.

CIP Sync solves this by maintaining synchronized System Time across the network using IEEE 1588 PTP. Every CIP Motion device runs:

1. A PTP master or slave clock (Time Sync Object, Class 0x43) — synchronized to within fractions of a microsecond of the network’s grandmaster
2. A Motion Axis Object instance (Class 0x42) — using System Time to schedule motion updates

When the controller sends a position command tagged “execute at System Time T,” every drive on the network knows precisely when T is and executes the command at that exact moment. Coordinated motion across multiple drives works because all drives share the same time reference.

For full CIP Sync mechanics — PTP message types, Best Master Clock Algorithm, the offset clock model, and the hardware-vs-software accuracy trade-off — see our CIP Sync Explained article.

The cyclic data connection

CIP Motion uses a standard CIP Class 1 cyclic I/O connection between the controller and each drive — opened via Forward_Open (service code 0x54), like any other EtherNet/IP I/O. The connection carries:

• Outputs (controller → drive) — commanded position, velocity, acceleration, torque, plus control words
• Inputs (drive → controller) — actual position, velocity, torque, plus status and fault information

The RPI (Requested Packet Interval) for CIP Motion is typically:

These RPIs are aggressive compared to typical I/O (often 10-100 ms). They require:

• Fast networks (Gigabit Ethernet preferred)
• Managed switches with QoS for motion traffic
• CIP Sync hardware-assisted PTP for sub-microsecond timing

The connection structure follows standard CIP Forward_Open mechanics. The Connection Path references Assembly Object instances inside the drive — the motion command assembly (outputs) and the motion feedback assembly (inputs). Connection sizes can be substantial (256+ bytes per direction) for drives with rich command/feedback data, often requiring Large_Forward_Open (service 0x5B) instead of standard Forward_Open.

For details on the connection establishment mechanics, see our CIP Forward_Open Service Explained article. For the cyclic data flow over UDP port 2222, see our EtherNet/IP I/O Messaging on UDP Port 2222 article.

Multi-axis coordination

This is what CIP Motion makes possible that’s hard or impossible with non-synchronized networks.

Coordinated moves require multiple axes to execute trajectories together — a CNC milling machine with X/Y/Z axes that must follow a contour, a robot arm with 6 joints that must follow a path, a packaging machine where multiple servo axes must hand off product between stations.

In a CIP Motion system, the motion controller generates the coordinated trajectory and sends synchronized position commands to all participating drives. Each drive:

1. Receives its position command with a System Time execution timestamp
2. Schedules the command for the specified System Time
3. Executes at exactly that time (because CIP Sync keeps every drive’s clock aligned)

The result: every axis executes its commanded position at the same instant. Across an entire 6-axis robot, the position error between commanded and actual trajectory stays within encoder resolution — even when the network has multiple switch hops between controller and drives.

This is the same capability that SERCOS, EtherCAT, and PROFINET IRT offer through their respective protocols, but CIP Motion achieves it over standard EtherNet/IP without a dedicated motion bus.

CIP Motion vs other motion protocols

How CIP Motion compares to alternative industrial motion solutions:

CIP Motion’s distinguishing characteristics:

1. True standard Ethernet — CIP Motion runs on commercial-off-the-shelf Gigabit Ethernet switches with IEEE 1588 boundary clock support. No protocol-specific physical layer.
2. Same network as ordinary I/O — motion and I/O traffic coexist on the same wire (with proper QoS)
3. CIP-native — same object model, same services, same engineering tools as any other CIP traffic
4. Wide third-party support — multiple drive vendors (Rockwell, Yaskawa, ABB, others) ship CIP Motion drives

The trade-off: CIP Motion’s performance depends heavily on the network infrastructure. Use unmanaged switches without PTP support and accuracy degrades to tens of microseconds. SERCOS III and EtherCAT, by contrast, are less sensitive to switch choice because their synchronization is built into the protocol itself.

For broader cross-protocol comparison, see our PROFINET vs EtherNet/IP article.

Application setup requirements

Deploying CIP Motion in a real machine requires:

Network infrastructure

• Gigabit Ethernet preferred (100 Mbps acceptable for limited axis counts)
• Industrial managed switches with IEEE 1588 PTP boundary clock support
• DLR ring topology for redundancy where required (see our DLR Device Level Ring article)
• QoS configured to prioritize motion traffic
• VLAN isolation when motion traffic shares the network with other plant traffic

Drive requirements

• CIP Motion device profile compliance (most modern servo drives from major vendors)
• Hardware-assisted IEEE 1588 PTP (sub-microsecond synchronization)
• Adequate connection capacity for the RPI you need

Controller

• CIP Motion-capable controller (Rockwell ControlLogix with MotionStart enabled, or compatible third-party)
• Sufficient axis count licensed
• Studio 5000 or equivalent engineering tool for configuration

Engineering considerations

• Determine RPI based on motion performance requirements (faster = better motion fidelity but more network load)
• Configure Time Sync Object on every motion device
• Set up the Best Master Clock Algorithm with a designated grandmaster
• Test synchronization accuracy before deploying motion programs
• Use Ethernet Link Object diagnostics (see our CIP Ethernet Link Object Explained) to monitor link quality

Common CIP Motion problems

For broader CIP error coverage, see our CIP General Status Codes Reference.

Frequently asked questions