The CIP Motion Peer Connection for
Real-Time Machine to Machine Control
Mark Chaffee
Senior Principal Engineer
Motion Architecture
Rockwell Automation
Steve Zuponcic
Technology Manager
Rockwell Automation
Presented at the ODVA2012 ODVA Industry Conference & 15th Annual Meeting
October 16-18, 2012
Stone Mountain, Georgia, USA

Abstract
This white paper discusses how the Peer Connection enables a highly distributed and modular motion control architecture.
This Peer Connection is un-intrusive in the system and easily layered across multi-vendor implementations - creating aunique, unifying real-time solution for electronic line shafting and camming applications for real-time machine to machinecoordination. Today, no such solution exists in industry at this level of the network topology. The Peer Connection also
allows motion planner execution to move from the controller to the drive, providing a major boost in overall system
performance. Finally, the distribution of motion functions in the form of I/O devices, feedback sensors, and standalone
converters (functionality that is already defined in today’s Motion Device Axis Object,) results in a clean, efficient andmodular control architecture that is easily deployed and easily scaled.

Keywords
Peer Connection, Distributed Motion, Modular Motion, Scaled Architecture, Performance, Machine to Machine Control

2012 ODVA Industry Conference

1©2012 ODVA, Inc.

Introduction
The ODVA Distributed Motion SIG is currently defining a Peer to Peer CIP Motion connection that will allow for the easy
distribution of real-time motion control information among multiple controllers and multiple device types. This capability,
available to a multi-vendor industry, will allow CIP to become the leading technology in the industrial marketplace for peer
to peer motion control for electronic line-shafting and camming applications.
The CIP Motion Architecture has some unique advantages in the market, over and above the competitive technologies thatare currently available. Built on the CIP protocol, the CIP Motion technology can coexist and cohabitate with other Ethernet
protocols and solutions in a harmonized and non-disruptive manner.
Revisiting some of its previous value statements, CIP Motion takes advantage of the fact that it is built on a common,standard, Ethernet stack. (See Figure 1.) This means that in addition to the Physical and Data Link layers defined in theIEEE-802.3 specification, the Common Industrial Protocol also utilizes the standard Network and Transport layers typically
deployed in general Ethernet applications. This allows for all devices in a given system to easily interconnect, using standard
switches, routers, and other standard infrastructure components.

Figure 1
One benefit of this single network solution is that there is no need for a dedicated motion network. Topologically speaking,motion control can be placed anywhere in the infrastructure without the concern of physically isolating the traffic from otherforms of traffic on the wire. Also, by utilizing existing Ethernet infrastructure, motion control can be easily layered intobrownfield installations where hardware already exists. This facilitates expansion to installed systems and allows fulladvantage of well-established and robust management and diagnostic tools.
So what additional benefit does the CIP Motion Peer Connection bring to the motion architecture? Consider that the
distribution of motion control across multiple cells or machine sections occurs at the level in the architecture where the line
control functionality is accomplished. (See Figure 2.) At this level, there is typically integration of machine level HMI, recipe
handling, historian data gathering, and engineering workstation functionality. The existing Ethernet wire that is being used
for these disciplines can now be harnessed for sharing of real-time motion control information for machine to machinecoordination! The Peer Connection is a very simple, homogenous and non-intrusive mechanism; it is easily layered acrossmulti-vendor implementations, creating a unique and unifying real-time solution for electronic line shafting and camming
applications.

2012 ODVA Industry Conference

2©2012 ODVA, Inc.

Figure 2

The Peer Connection Definition
At its core, the CIP Motion Peer connection definition follows the same principles embodied in the existing specification for
the CIP Motion I/O connection. The CIP Motion Peer connection is designed to transmit high speed motion data from a
producing controller or device to multiple consuming controllers or devices over a single multicast connection. (See Figure3.) For example, time stamped master axis position data distributed by the CIP Motion Peer Connection allows consuming

Figure 3
CIP Motion drives to precisely coordinate motion of their motors to the produced master axis position according toprogrammed electronic gearing or camming relationships.

2012 ODVA Industry Conference

3©2012 ODVA, Inc.

CIP Motion Peer Connection Use Cases
The CIP Motion Peer Connection has many use cases. As discussed previously, one application is to communicate produced
axis information for distributed camming and gearing purposes. In this scenario, the position of a motor that is being driven
in a machine cell by Vendor A may be produced as a master axis reference and sent out on the CIP Motion Peer Connection
to be consumed by the other vendor controllers so that their respective axes can follow Vendor A’s positioning information ina coordinated and synchronized manner. (See Figure 4 below.)

HMI

Machine 1

Vendor A

Produced Axis

Machine 1

HistorianEngineering
Workstation

Line Controller

Vendor B

Machine 1

Consumed Axes

Vendor C

Consumed Axes

Machine 1

Vendor D

Consumed Axes

Figure 4
A second application is when the line controller itself generates a virtual axis in order to achieve full line synchronization andcoordination. In this case, all the coordinated axes receive a common reference via the CIP Motion Peer Connection from theline controller in order to maintain coordination and proper phasing from axis to axis. This not only allows for coordinatedcamming and gearing functionality, but also allows for complete line starting and stopping as all sections are brought up to
speed and brought down in speed in a synchronized manner. (See figure 5 below.)2012 ODVA Industry Conference

4©2012 ODVA, Inc.

Produced Virtual Axis
HMI

Machine 1

Vendor A

Consumed Axis

Machine 1

HistorianEngineering
Workstation

Line Controller

Vendor B

Machine 1

Consumed Axes

Machine 1

Vendor C

Consumed Axes

Vendor D

Consumed Axes

Figure 5
A third application for the CIP Motion Peer connection would be in the sharing of axis information for the coordination ofrobotics control. (See Figure 6.) In this case, a master reference could be produced over the CIP Motion Peer connection toallow for proper coordination of the robot as the entire line increases and decreases in speed. For example, the robot may be
managing a “pick and place” application from one conveyor to another and needs to stay fully synchronized as the entire line
is accelerated or decelerated.

Produced Virtual Axis
HMI

Machine 1

Vendor A

Line Controller

Machine 1

Engineering
Workstation

Historian

Vendor B

Figure 6

Distributed Performance via the Peer Connection2012 ODVA Industry Conference

5©2012 ODVA, Inc.

As shown above, the CIP Motion Peer Connection is designed to support controller to controller coordination – but it is also
designed for controller to device, and for device to device motion coordination. This allows the CIP Motion devices to
execute motion functions typically performed by the controller or by full featured servo drives. In short, the advent of the CIP
Motion Peer connection represents a major step toward a Distributed Motion Control architecture, signaling a significant
paradigm shift in the industry.
There are many benefits to moving toward a distributed motion architecture. One of the inherent benefits is its impact onoverall system performance. To date, the Motion Planner has been executed exclusively by a controller as part of thecontroller’s Motion Task. In this arrangement, the controller’s Motion Planner is producing motion reference information tomultiple drives in the system. (See Figure 7.) As a result, the Motion Planner Update Period for this controller needs to be
configured to meet the requirements of the fastest axes on the machine- dictating the Motion Task Update Period for all theaxes on the machine. Since most axes do not need to run at the same, fast rate, processing capability is wasted in this “one-tomany” model.

CIP Motion Drive

Automation Controller
I/O

Count
Scaling

MotionPlanner

I/O
Axis
ObjectUser
Scaling

Drive Task

Drive Core

Axis
ObjectMotor
Control

CIP Motion Drive

Count
Scaling

EtherNet /IP

User
Scaling

EtherNet /IP

Axis
ObjectEtherNet /IP

Motion Task

Drive Task

Drive Core

Axis
ObjectMotor
Control

Figure 7
By moving the Motion Planner function to the CIP Motion devices, the Motion Planner Update Period of these highperformance axes no longer dictates the Motion Task Update Period in the controller. The reduction in Motion Task update
rate translates directly to a reduction in the CIP motion connection update rate, resulting in reduced network loading.
Furthermore, with the distribution of the computationally intensive Motion Planner function to the end devices, Motion Task
execution time in the controller is also significantly reduced. (See Figure 8.) The combined impact of reduced connection
update rates and Motion Task execution time translates to a dramatic increase in motion control system capacity andperformance.

2012 ODVA Industry Conference

6©2012 ODVA, Inc.

CIP Motion Drive

Automation Controller
Motion Task
I/O

User
Scaling

Peer

Count
Scaling

EtherNet /IP

Axis
ObjectDrive Core

Drive Task
Axis
ObjectEtherNet /IP

MotionPlanner

CIP Motion Drive
Drive Core

Drive Task
User
ScalingCount
Scaling

EtherNet /IP

Axis
ObjectMotor
Control

Axis
ObjectMotor
Control

MotionPlanner

Figure 8
In addition to increased motion control system capacity, motion control dynamic performance has a strong dependency on the
Motion Planner Update Period. This determines how frequently the Motion Planner function updates the command position
applied by the drive. The faster the command position update rate, the more points are placed on the motion profile, which
reduces the interpolation error in following the commanded path. The attraction of running the Motion Planner in the drive isthat, since there is typically only 1 planner instance per drive, the planner can be run at a very fast update rate (i.e. 1 msec orless) resulting in outstanding dynamic control. In addition, if the planner were to run at the same rate as the servo update rate,
the need to interpolate data between the planner and the position loop would disappear – reducing command position update
delay and facilitating a simpler design.
To appreciate the impact of the Distributed Motion Control feature, consider a CIP Motion control system running a highperformance packaging machine producing 1000 products per minute using a 1 millisecond Motion Task Update Period. In
this application, one product is being processed every 60 msecs. If there were 30 axes of control required for this machine, acontroller based planner would need to calculate all 30 axes every 1 msec, representing a sizeable load on the controller’s
processing and communications capabilities.
However, if the planner functionality is moved to the device instead, then each drive can execute its own path planning
functionality while the Peer Connection manages the information required for drive to drive coordination. In thisarchitecture, the drive based planners can be run at a sub-millisecond update rate and the controller to drive cycle time period
can be increased to 10 msecs or more without impacting the motion quality. As a result, the estimated system capacity caneasily increase by an order of magnitude by distributing the planner function to the drive.

Distributed Motion Functionality
With CIP Motion, the Distributed Motion Control architecture is more than just distributing the controller’s Motion Planner
function to CIP Motion drives. Other motion functions may be distributed as well, creating new types of CIP Motion devices
as illustrated in the following system diagram. (Figure 9.)2012 ODVA Industry Conference

7©2012 ODVA, Inc.

HMI

HistorianEngineering
Workstation

Line Controller

Distributed Feedback
Time Stamped Position

Input Device
Registration

Output Device
Output Camming

Figure 9
The ability to distribute motion functions across CIP Motion devices and controllers addresses a recent trend in lean drive
design where drive vendors are off-loading certain functions of the traditional full featured servo drive to other devices. The
following object diagram shows some of the functional components that might be separated out from the current CIP Motion
Drive Axis Object to create this distributed architecture. (Figure 10.)
Automation Controller

CIP Motion Servo Drive

Motion Control Axis Object

Motion Drive Axis Object

Converter

Converter

Feedback
Feedback

Motion I/O

Control

Feedback
Feedback
CIP Motion
I/O Connection

Motion I/O

Control

Figure 10

One example of a function that historically, has been packaged with the drive is the auxiliary feedback port. Traditionally,
this function is embedded in every drive on the chance that it will be needed for that given application. In reality, in
camming or line-shafting applications a single encoder on the primary axis can be shared by all through a CIP Motion
multicast connection. Since it is so infrequently used, it can be eliminated in future drive designs, replaced when needed by a
dedicated standalone CIP Motion Encoder device.
2012 ODVA Industry Conference

8©2012 ODVA, Inc.

Figure 11
The object model shown above (Figure 11) illustrates the relationship between the Motion Control Axis Object and the
Motion Drive Axis Object. In this case, the attributes for the CIP Motion Encoder Device already exist in the Motion Device
Axis Object specification and consist of a relatively small subset of axis attributes that are applicable to the feedback
function. These attributes are easily identified in the Motion Device Axis Object implementation table under the ‘E’ Device
Control Code. See the table below, (Figure 12) which is an extract from the CIP Motion specification:
Instance Attribute
Attr. ID
1351
1352
1400 + o1401 + o1402 + o1403 + o1404 + o
42

Acc.
Rule
Set
Set
Get
Get
Get
Get
Get
Set*

Implementation by Device Control Code

Attribute Name
Induction Motor Rotor Leakage ReactanceInduction Motor Rated Slip Speed
Feedback n Catalog Number
Feedback n Serial Number
Feedback n Position
Feedback n Velocity
Feedback n Acceleration
Feedback Mode

Figure 12

E

F

P

V

T

O
O
R
R
R
R

R
O
R

R
O
O
O
R
R
R
R

R
O
O
O
R
R
R
R

R
O
O
O
R
R
R
R

Conditional
Implementation
Induction Motor only
Induction Motor only
E
E
E
E
E

(E = CIP Motion Encoder Device)

Position data produced by the external CIP Motion Encoder can then be consumed by the associated drive via a CIP Motion
Peer Connection to provide auxiliary feedback functionality when needed. Figure 13 below shows how the CIP Motion
Encoder Device would produce the position data to the Peer Connection.

2012 ODVA Industry Conference

9©2012 ODVA, Inc.

Master Encoder Device

Automation Controller
Motion Task

CIP
Axis
Object(Tag 1)

Ethernet

NIC
D2C
Parse

C2D
Assem

Conn
Map
Object

MAC
&
Stack

NIC

D2C

D2C

C2D

C2D

ModuleC-Tag

Encoder Update
Period

D2C
Assem
MAC
&
Stack

NIC
Peer

CIP I/O Connection Tasks

MAC
&
Stack

C2D
Parse

Axis
Object#1

EncoderInterfaceCore

E

CIP Peer Connection Task
Peer
Assem

Axis
Object#1

Slave Drive Device
NIC
Peer

MAC
&
Stack

CIP Peer Connection Task
Peer
Parse

MotionPlannerModule
C-Tag
NIC

CIP
Axis
Object(Tag 2)

D2C
Parse

C2D
Assem

NIC
D2C

Conn
Map
ObjectDrive Update
PeriodAxis
Object
#2

MAC
&
Stack

C2D

C2D

CIP I/O Connection Tasks
D2C
Assem

D2C
MAC
&
Stack

C2D
Parse

Axis
Object#1

Drive
ControlCore

M
E

Figure 13
Another class of CIP Motion devices created by distributing motion functionality are CIP Motion I/O devices. Two very
useful devices of this kind would be the CIP Motion Output Cam device, and the CIP Motion Registration Input device. See
the object relationship model below, (Figure 14.)

Figure 14
Similar to distributed CIP Motion Encoder the Motion Axis Object for this new CIP Motion I/O device would consist of a
relatively small subset of axis attributes that are applicable to the CIP Motion Axis Object’s I/O functionality. These
attributes may be identified in the Motion Device Axis Object implementation table under the ‘IO’ Device Control Code.
See the table below, (Figure 15) an extract from the CIP Motion specification:2012 ODVA Industry Conference

10©2012 ODVA, Inc.

Instance Attribute
Attr. ID
1434 + o1435 + o
60
61
62
63
64
65
66
67
68
69

Acc.
Rule
Set
Set
Set*
Get
Get
Get
Get
Get
Get
Get
Get
Get

Implementation by Device Control Code

Attribute Name

IO

E

F

P

V

T

R
R
O
O
O
O
O
O
O
O

O
O
R
R
O
O
O
O
O
O
O
O

-

O
O
R
R
R
R
O
O
R
R
O
O

O
O
O
O
O
O
O
O
O
O
O
O

O
O
O
O
O
O
O
O
O
O
O
O

Feedback n Velocity Filter Bandwidth
Feedback n Accel Filter Bandwidth
Event Checking Control
Event Checking Status
Registration 1 Positive Edge Position
Registration 1 Negative Edge Position
Registration 2 Positive Edge Position
Registration 2 Negative Edge Position
Registration 1 Positive Edge Time
Registration 1 Negative Edge Time
Registration 2 Positive Edge Time
Registration 2 Negative Edge Time

Figure 15

Conditional
Implementation(IO = CIP Motion I/O attributes)

A CIP Motion Output Cam device would consume real time Position data from a CIP Motion controller or device over the
CIP Motion Peer Connection. (See Figure 16, below.)
Automation Controller

Master Drive Device

Motion Task

CIP
Axis
Object(Tag 1)

Ethernet

NIC
D2C
Parse

C2D
Assem

Conn
Map
Object

MAC
&
Stack

NIC

D2C

D2C

C2D

C2D

ModuleC-Tag

Drive Update
Period

D2C
Assem
MAC
&
Stack

Axis
Object#1

Drive
Control
Core

M

C2D
Parse

NIC
Peer

CIP I/O Connection Tasks

MAC
&
Stack

E

CIP Peer Connection Task
Peer
Assem

MotionPlanner

Axis
Object#1

Output Cam Device
NIC
Peer

MAC
&
Stack

CIP Peer Connection Task
Peer
Parse

OutputCam

Module
C-Tag
NIC

CIP
Axis
Object(Tag 2)

D2C
Parse

C2D
Assem

I/O
Tags

NIC
D2C

Conn
Map
ObjectOutput Update
PeriodAxis
Object
#1

MAC
&
Stack

MAC
&
Stack

C2D

C2D

I/O

I/O

CIP I/O Connection Tasks
D2C
Assem

D2C
MAC
&
Stack

Axis
Object#1

OutputControl
Core

Glue
Gun

C2D
Parse

MAC
&
Stack

Assem
Objects

Figure 16
A CIP Motion Registration Input device would consume real time Position data from a producing CIP Motion controller or
device over the CIP Motion Peer Connection. (See Figure 17 below.)2012 ODVA Industry Conference

11©2012 ODVA, Inc.

Figure 17
Converters (power supplies) previously built into every standalone drive are being eliminated in lean drive designs, replaced
by a single, cost effective, standalone converter module supplying DC bus power to multiple inverter-only drives. (See Figure
18 below.)
Automation Controller

CIP Motion Converter

Motion Control Axis Object

Motion Drive Axis Object

Converter

Converter
CIP Motion
I/O Connection

Figure 18
The Motion Axis Object for this CIP Motion Converter device would consist of a relatively small subset of axis attributes
that are applicable to the converter power supply function. These attributes may be easily identified in the Motion Device
Axis Object implementation table under the ‘B’ Device Control Code. (Reference Figure 19, below.)2012 ODVA Industry Conference

12©2012 ODVA, Inc.

Instance Attribute
Attr. ID
614
615
616
620
621
622
623
624
625

Acc.
Rule
Set
Set
Set
Get
Get
Set
Set
Set
Set

Implementation by Device Control Code

Attribute Name
Mechanical Brake Control
Mechanical Brake Release Delay
Mechanical Brake Engage Delay
DC Bus Voltage
DC Bus Voltage - Nominal
Bus Configuration
Bus Voltage SelectBus Regulator Action
Regenerative Power Limit

B

E

F

P

V

T

R
R
O
R
R

-

O
O
O
R
R
O
R
R
O

O
O
O
R
R
O
R
R
O

O
O
O
R
R
O
R
R
O

O
O
O
R
R
O
R
R
O

Figure 19

Conditional
Implementation(B = CIP Motion Converter device)

When the converter function is distributed to a standalone CIP Motion device, it still needs to communicate with the drives it
is supplying DC bus power to so as to coordinate their operation with the converter’s state. For example, if the converter
becomes overheated, the converter needs to communicate an overload condition to the drives it is supplying power to so they
can stop drawing from the DC Bus. The Distributed Motion architecture provides a solution to this communication problem
by allowing the converter to be a Peer Connection producer and associated power consuming drives to be Peer Connection
consumers of converter data. In this way, the converter can communicate status information to the associated drives, directly
coordinating their behavior with the converter, without controller intervention. (See Figure 20 below.).
Figure 20

2012 ODVA Industry Conference

13©2012 ODVA, Inc.

Conclusion
In this white paper we discussed how the Peer Connection enables a highly distributed and modular motion control
architecture. This Peer Connection is un-intrusive in the system and easily layered across multi-vendor implementations creating a unique, unifying real-time solution for electronic line shafting and camming applications. Today, no such solution
exists in industry at this level of the network topology. The Peer Connection also allows motion planner execution to movefrom the controller to the drive, providing a major boost in overall system performance. Finally, the distribution of motionfunctions in the form of I/O devices, feedback sensors, and standalone converters (functionality that is already defined intoday’s Motion Device Axis Object,) results in a clean, efficient and modular control architecture that is easily deployed andeasily scaled.
In closing, the following table summarizes a few of the capabilities that the CIP Motion Peer Connection might enable in a
motion system:
1.
2.
3.
4.
5.
6.
7.

Master axis produced / consumed information for distributed camming and gearing synchronization.
Line controller machine motion coordination and synchronization via produced virtual axis.
Synchronized robot operation - e.g. synchronized interpolation move execution using a common virtual axis masterDrive torque sharing
Inverter/Converter control synchronization
Distributed drive I/O resources - Auxiliary feedback, registration,
Distributed motion planning (drive based trajectory planner) with produced/consumed axis (master) driven synchronization**************************************************************************************The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the
possible use of CIP Networks and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because CIP
Networks may be applied in many diverse situations and in conjunction with products and systems from multiple vendors,
the reader and those responsible for specifying CIP Networks must determine for themselves the suitability and the suitabilityof ideas, opinions, and recommendations expressed herein for intended use. Copyright ©2012 ODVA, Inc. All rights
reserved. For permission to reproduce excerpts of this material, with appropriate attribution to the author(s), please contact
ODVA on: TEL +1 734-975-8840 FAX +1 734-922-0027 EMAIL odva@odva.org WEB www.odva.org. CIP, Common
Industrial Protocol, CIP Motion, CIP Safety, CIP Sync, CompoNet, CompoNet CONFORMANCE TESTED, ControlNet,
ControlNet CONFORMANCE TESTED, DeviceNet, EtherNet/IP, EtherNet/IP CONFORMANCE TESTED are trademarksof ODVA, Inc. DeviceNet CONFORMANCE TESTED is a registered trademark of ODVA, Inc. All other trademarks areproperty of their respective owners.

2012 ODVA Industry Conference

14©2012 ODVA, Inc.

Appendix A
The proposed data structure for the CIP Motion Peer Connection is as follows: 32-bit Word Peer Connection Format
Connection Header
Instance Header
Instance Data Block

Connection Format-

Connection Header
Format Revision
Update ID
Node Fault/Alarm
Producer Time Stamp
Producer Time Offset

Instance Number

Control Mode
Command Data Set

Instance Data Block
Cyclic Blk Size
Cyclic Data Block
Attribute Data Block

Cyclic Data Block
Feedback Mode
Axis State
Actual Data Set
Status Data Set
UnwindCommand Data 1
Command Data 2…
Actual Data 1
Actual Data 2…
Status Data 1
Status Data 2…

Cyclic Attr 1 ID
Attr 1 Start Index (array only)…

Node Status
Time Data Set

Attr Blk Size

Axis Config
Cyclic Data Control

Attribute Data Block
Attr 1 Dimension
Attr 1 Element Size
Attr 1 Elements (array only)…
Cyclic Attr 1 Data…

The CIP Motion Peer Connection Format consists of a general header followed by a block of data associated with the
produced axis instance. The content of the data block is periodically updated and sent to the consumers via a multicast
connection at the specified Update Period of the producer. This update is synchronized with other peer devices in the motion
control system through use of distributed System Time based on IEEE-1588 PTP. Since a Time Stamp is included in theconnection data, the producer update rate does not need to have any fixed relationship with the update rates of the various
consumers. Note that, unlike the CIP Motion I/O Connection, the CIP Motion Peer Connection is a one-way connection fromproducer to consumer with no return connection from the consumers. The implication of unidirectional data flow fromproducer to consumer is that there is no mechanism to support handshaking. For this reason, the CIP Motion Peer Connection
does not support event notification/acknowledge exchanges or service request/response exchanges. These functions whenneeded can be readily facilitated via a separate CIP I/O connection.

2012 ODVA Industry Conference

15©2012 ODVA, Inc.