EtherNet/IP™ for
Real-Time, Machine-to-Machine Control
With its huge commercial base and wide bandwidth, EtherNet/IP offers
the potential to combine the required performance of a motion control
network with the wider demands of a control network. This white paper
describes an approach to EtherNet/IP that enables highly distributed andmodular machine control architecture for motion control applications. This
un-intrusive approach is easily layered across multi-vendor
implementations – including purpose-built networks optimized forcontroller-to-drive communication.
This approach is the first of its kind to offer high performance, real-timemachine-to-machine control over standard TCP/IP. As a result, it
provides a unique, unifying real-time solution for many applications
requiring multi-machine and multi-axis coordination, such as electronicline shafting, camming and transfer lines. The audience for this paper
includes product managers at device vendors who are seeking to map out
the product roadmaps to support high performance, motion-centricmachine applications as well as users who apply machines to solve
applications such as electronic line shafting, camming and transfer lines,
among others.

Introduction
ODVA is currently defining extensions
to EtherNet/IP that will enable apeer-to-peer connection and allow for
the distribution of real-time motion
control information among multiple
controllers and device types. This
capability will make the Common
Industrial Protocol (CIP) the unifying
technology
intheindustrial
marketplace for machine-to-machine
applications
thatrequirehighperformance motion control. The
approach adapts the architecture of
CIP Motion™, proven for controllerto-drive control, to new applications
at the machine-to-machine and line
controllevelsthatcanbeindependentoftheunderlying
controller-to-drive technology.

The CIP Motion architecture itself has
some unique advantages which havebeen extended to the approachdescribed herein. As a part of the
CIP protocol, the CIP Motion objects
andservices
cancoexistandcohabitate with services on otherstandard Ethernet solutions – and do
so in a harmonized and nondisruptive manner.

Figure 1: CIP Motion is built on a standard,
Ethernet implementation

PUB00279R0

Page 1 of 7

EtherNet/IP™ for Real-Time, Machine-to-Machine Control

CIP Motion, as a part of CIP, takes
advantage of the fact that it is built
on a common, standard Ethernet
stack.
This means that in addition to the
Physical and Data Link layers definedin the IEEE-802.3 specification, CIP
uses the standard Network andTransport layers typically deployed ingeneral Ethernet applications. This
allowsfordevicestoeasilyinterconnect using standard switches,routers and other infrastructurecomponents.
One benefit of this single network
solution is that there is no need for a
dedicatedmotionnetwork.
Topologicallyspeaking,
motioncontrol can be placed anywhere in
the infrastructure without physicallyisolating the traffic from other formsof traffic on the wire. Also, by using
the existing Ethernet infrastructure,
motion control can be easily layered
into brownfield installations where
hardwarealready
exists.
Thisfacilitates expansion to installedsystems and takes full advantage ofwell-establishedandrobustmanagement and diagnostic tools.
So, what additional benefits does the
CIP Motion peer-to-peer connection
bring to multi-axis applications?

used for these disciplines can now beharnessed to share real-time motion
control information for machine-tomachine coordination.

Figure 2: Harness existing Ethernet wire forsharing of real-time motion control

The
CIP
Motionpeer-to-peer
connection
is
a
very
simple,homogenous
andnon-intrusive
mechanism. It is easily layered
across multi-vendor implementations,creating a unifying real-time solution
for electronic line shafting andcamming applications.
The CIP Motion Peer-to-Peer
Connection Definition
The
CIP
Motionpeer-to-peer
connection is designed to transmit
high-speed motion data from a
producing controller or device tomultiple consuming controllers ordevices over a single multicast
connection.

The distribution of motion control
across multiple cells or machine
sections occurs at the level in thearchitecture where the line control
functionalityisalready
being
accomplished.
At this level, there is typicallyintegration of machine-level HMI,
recipehandling,
historiandata
gathering,andengineering
workstation
functionality.
The
existing Ethernet wire that is being

PUB00279R0

Figure 3: The CIP Motion peer-to-peer
connection transmits motion data to devices

Page 2 of 8

EtherNet/IP™ for Real-Time, Machine-to-Machine Control

For example, time-stamped masteraxis position data distributed by the
CIP Motion peer-to-peer connection
allows consuming CIP Motion drives
to precisely coordinate the motion of
their motors to the produced masteraxis
position
accordingtoprogrammed electronic gearing or
camming relationships.

from the line controller to maintain
coordination and proper phasing fromaxis to axis. This allows for
coordinated camming and gearing
functionality, and complete line
starting and stopping as all sections
are brought up and down to speed ina synchronized manner.
Produced Virtual Axis
HMI

Use Cases
Machine 1

The
CIP
Motionpeer-to-peer
connection has many use cases. As
discussed previously, one application
is to communicate produced axis
information for distributed cammingand gearing purposes.
HMI

Machine 1

Vendor A

Produced Axis

Machine 1

Vendor B

Consumed Axes

HistorianEngineering
Workstation

Line Controller

Machine 1

Vendor C

Consumed Axes

Machine 1

Vendor D

Consumed Axes

Figure 4: CIP Motion peer-to-peer
connection allows motors to communicate
axis information for distributed cammingand gearing purposes

In this scenario, the position of a
motor being driven in a machine cellby Vendor A may be produced as amaster axis reference and sent out
on the CIP Motion peer-to-peer
connection. There it will be consumed
by the other vendor controllers sothat their respective axes can follow
Vendor A’s positioning information ina coordinated and synchronizedmanner.
A second use case is when the line
controller itself generates a virtualaxis
toachievefull
line
synchronization and coordination. In
this case, all the coordinated axes
receive a common reference via the
CIP Motion peer-to-peer connection
PUB00279R0

Vendor A

Consumed Axis

Machine 1

Vendor B

Consumed Axes

HistorianEngineering
Workstation

Line Controller

Machine 1

Vendor C

Machine 1

Consumed Axes

Vendor D

Consumed Axes

Figure 5: All the coordinated axes canreceive a common reference via the CIP
Motion peer-to-peer connection from theline controller

A third use case for the CIP Motion
peer-to-peer
connectionisthesharing of axis information for thecoordination of robotics control. In
this case, a master reference could
be produced over the CIP Motion
peer-to-peer connection to properly
coordinate 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 toanother and needs to stay fully
synchronized as the entire line isaccelerated or decelerated.
Produced Virtual Axis
HMI

Machine 1

Vendor A

Line Controller

Machine 1

Engineering
Workstation

Historian

Vendor B

Figure 6: CIP Motion connection shares axis
information to coordinate robotic control

Page 3 of 8

EtherNet/IP™ for Real-Time, Machine-to-Machine Control

Drives and other devices are now
able to execute motion functions
typically performed by the controller
or by full-featured servo drives. In
short, the CIP Motion peer-to-peer
connection represents a major step
towards a distributed Motion Control
architecture – signaling a noteworthy paradigm shift in the industry.

CIP Motion Drive

Automation Controller
Motion Task
Axis
ObjectDrive Core

Drive Task
I/O

User
Scaling

Peer

Axis
ObjectCount
Scaling

EtherNet /IP

As shown above, the CIP Motion
peer-to-peer connection is designed
to support controller-to-controller
coordination. But it can also be used
for controller-to-drive, controller-todevice,andfordrive/device-todrive/device coordination.

Update Periods at rates that arealigned with the response needed in
the application. Furthermore, by
eliminating the “one to many”
relationship between the automation
controller and the drives, real-timecommunications is greatly minimized
due to reduced connection update
rates. This model is much more
flexible and translates to a dramaticincrease in motion control system
capacity and performance.

CIP Motion Drive
Drive Core

Drive Task

CIP Motion Drive

Automation Controller
I/O

Count
Scaling

MotionPlanner

I/O
Axis
ObjectUser
ScalingCount
Scaling

Drive Task

Drive Core

Axis
ObjectMotor
Control

CIP Motion Drive
EtherNet /IP

User
Scaling

EtherNet /IP

Axis
ObjectEtherNet /IP

Motion Task

Drive Task

Drive Core

Axis
ObjectMotor
Control

Figure 7: The Motion Planner is traditionally
executed as part of a controller’s tasks

By distributing the Motion Planner
function to the end devices, theautomation controller Motion Task
executiontime
issignificantly
reduced, and the end drives are able
to run their unique Motion Planner

PUB00279R0

User
ScalingCount
Scaling

EtherNet /IP

There are many benefits to moving
toward a distributed Motion Control
architecture. One is its impact onoverallsystemperformance.
Traditionally, a centralized controller
executes the Motion Planner as partof
its
Motion
Task.
In
this
arrangement, the controller’s Motion
Planner is producing motion reference
information to multiple drives in thesystem.

Axis
ObjectMotor
Control

MotionPlanner

EtherNet /IP

Distributed Performance

Axis
ObjectMotor
Control

MotionPlanner

Figure 8: CIP Motion peer-to-peer
connection can off-load the Motion Planner
function to the devices

Motion control dynamic performanceis also dependent on the Motion
Planner update period, determining
how frequently the Motion Planner
function
updatesthecommandposition applied by the drive.
The faster the command position
update rate, the more points that areplaced on the motion profile –reducing the interpolation error infollowing the commanded path.
The benefit of running the Motion
Planner in the drive is that, since
there is typically one planner instanceper drive, the planner can be run at avery fast update rate, resulting inoutstanding dynamic control. To
appreciatetheimpactoftheDistributed Motion Control feature,
consider a control system running ahigh performance packaging machine
producing 1,000 products per minutePage 4 of 8

EtherNet/IP™ for Real-Time, Machine-to-Machine Control

using a 1 millisecond Motion Task
Update Period.
In this application, one product is
being
processed
every
60
milliseconds. If there are 30 axes ofcontrol required for this machine, acontroller-based planner would needto calculate all 30 axes every
millisecond.
However, if the planner functionality
is moved to the device instead, theneach drive can execute its own path
planning functionality while the peerto-peer connection manages theinformation required for drive-todrive coordination.
In this architecture, the drive-basedplanners can be run at a submillisecond update rate and thecontroller-to-drive cycle period canbe increased to 10 milliseconds ormore without impacting the motion
quality. As a result, the estimatedsystem capacity is easily increased.
Distributed Motion Functionality
and Lean Device Design
With CIP Motion, the Distributed
MotionControlarchitecture
distributes the controller’s Motion
Planner function to CIP Motion drives.
But that’s not all it does – othermotion functions may be distributed
as well.

HMILine Controller

Engineering
Workstation

The ability to distribute motionfunctions across CIP Motion devices
and controllers addresses a recent
trend in lean drive design in which
drive vendors are off-loading certain
functions of the traditional fullfeatured servo drive to other devices.
Automation Controller

CIP Motion Servo Drive

Motion Control Axis Object

Motion Drive Axis Object

Converter

Feedback
Feedback

Converter

Feedback
Feedback

Motion I/O

Control

CIP Motion
I/O Connection

Motion I/O

Control

Figure 10: Functional components can beseparated from the CIP Motion Drive Axis
Object to create a distributed architecture

One function that has been packaged
with the drive is the auxiliary
feedback port.
Traditionally,
thisfunctionisembedded in every drive on the
chance that it will be needed. But incammingorline-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 neededby a dedicated standalone CIP Motion
Encoder device.

HistorianDistributed Feedback
Time Stamped Position

Input Device
Registration

Output Device
Output Camming

Figure 11: Illustrates the relationshipbetween the Motion Control Axis
Object and the Motion Drive Axis Object

Figure 9: CIP Motion distributes moremotion functions, creating new types ofdevices

PUB00279R0

Page 5 of 8

EtherNet/IP™ for Real-Time, Machine-to-Machine Control

In this case, the attributes for the CIP
Motion Encoder Device already exist
in the Motion Device Axis Object
specification
andconsistofarelatively small subset of axis
attributes that are applicable to the
feedback function. These attributes
are easily identified in the Motion
Device Axis Object implementationtable under the ‘E’ Device Control
Code.

Similar to the distributed CIP Motion
Encoder, the Motion Axis Object forthis new CIP Motion I/O device would
consist of a relatively small subset ofaxis attributes that are applicable to
the CIP Motion Axis Object’s I/Ofunctionality.

Figure 12: This extract from the CIP Motion
specification shows how attributes are
identified in the device. E = CIP Motion
Encoder device

Position data produced by theexternal CIP Motion Encoder can thenbe consumed by the associated drive
via a CIP Motion peer-to-peer
connection that provides auxiliary
feedback functionality when needed.
Automation Controller
Ethernet

NIC
D2C
Parse

C2D
Assem

D2C
Conn
Map
Object

MAC
&
Stack

C2D

NIC

C2D

MAC
&
Stack

NIC
Peer

CIP I/O Connection Tasks

Encoder Update
Period

D2C
Assem

D2C

Module
C-Tag

MAC
&
Stack

C2D
Parse

Axis
Object#1

EncoderInterfaceCore

E

CIP Peer Connection Task
Peer
Assem

Axis
Object#1

Figure 15: This extract from the CIP Motion
specification shows how attributes are
identified in the device. IO = CIP Motion I/O
attributes.

Slave Drive Device
NIC
Peer

MAC
&
Stack

CIP Peer Connection Task
Peer
Parse

MotionPlanner
NIC

D2C
Parse

C2D
Assem

Conn
Map
ObjectDrive Update
PeriodAxis
Object#2

Module
C-Tag

CIP
Axis
Object(Tag 2)

These attributes are identified in the
MotionDeviceAxis
Objectimplementation table under the ‘IO’
Device Control Code.

Master Encoder Device

Motion Task

CIP
Axis
Object(Tag 1)Figure 14: I/O devices are created by
distributing motion functionality. Thisgraphic depicts the object relationshipmodel.

MAC
&
Stack

NIC
D2C

D2C

C2D

C2D

CIP I/O Connection Tasks
D2C
Assem

MAC
&
Stack

C2D
Parse

Axis
Object#1

Drive
ControlCore

M
E

Figure 13: CIP Motion Encoder Device canproduce position data to the Peer
Connection

A CIP Motion Output Cam device
would consume real-time position
data from a CIP Motion controller or
device over the CIP Motion peer-topeer connection.

Another class of devices created by
distributing
motionfunctionality
includes CIP Motion I/O devices -including the CIP Motion Output Cam
deviceandthe
CIP
MotionRegistration Input device.

PUB00279R0

Page 6 of 8

EtherNet/IP™ for Real-Time, Machine-to-Machine Control

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

MAC
&
Stack

CIP Peer Connection Task
Peer
Assem

Automation Controller

CIP Motion Converter

Motion Control Axis Object

Motion Drive Axis Object

M

Converter

C2D
Parse

NIC
Peer

CIP I/O Connection Tasks

Converter
CIP Motion
I/O Connection

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

D2C
Assem

D2C

C2D

C2D

I/O

I/O

CIP I/O Connection Tasks

MAC
&
Stack

Axis
Object#1

OutputControl
Core

C2D
Parse

MAC
&
Stack

Glu
Gu

Figure 18: Converters (power supplies)
previously built into drives are being
replaced by standalone converter modules

Assem
Objects

Figure 16: CIP Motion Output Cam device
can consume real-time Position data from acontroller or device

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-to-peer connection.

The Motion Axis Object for this CIP
MotionConverter
devicewould
consist of a relatively small subset ofaxis attributes that are applicable tothe converter power supply function.
These attributes may be easily
identified in the Motion Device Axis
Object implementation table underthe ‘B’ Device Control Code.

Figure 19. This shows how device attributes
are identified in the specification.
B = Device Control Code

Figure 17: CIP Motion Registration Input
device can consume real-time Position datafrom a CIP Motion controller or device

Converters(powersupplies)
previously built into every standalone
drive are being eliminated in leandrive designs, replaced by a single,
cost effective, standalone converter
module supplying DC bus power tomultiple inverter-only drives.

PUB00279R0

When the converter function is
distributed to a standalone CIP
Motion device, it still needs tocommunicate with the drives it
supplies DC bus power to so as tocoordinate their operation with theconverter’s state.
For example, if the converter
becomes overheated, it needs tocommunicate an overload condition
to the drives it is supplying power toso they can stop drawing from the DC
Bus.

Page 7 of 8

EtherNet/IP™ for Real-Time, Machine-to-Machine Control

The Distributed Motion architecture
providesasolutiontothiscommunication problem by allowing
the converter to be a Peer Connection
producerandassociatedpower
consuming
drivestobe
PeerConnection consumers of converter
data. In this way, the converter cancommunicate status information totheassociateddrives,directly
coordinating their behavior with theconverter,
without
controllerintervention.

Figure 20: A converter can communicate
status information to the associated drives

Conclusion
The CIP Motion Peer Connection
enables a highly distributed andmodular motion control architecture.
This Peer Connection is un-intrusive
in the system and easily layered
across multi-vendor implementations- creating a unique, unifying realtime solution for electronic line
shafting and camming applications.
Today, no such solution exists inindustry at this level of the network
topology. The Peer Connection also
allows motion planner execution tomove from the controller to the drive,
providing a major boost in overallsystem performance. Finally, thedistribution of motion functions in theform of I/O devices, feedback
sensors, and standalone converters

PUB00279R0

results in a clean, efficient andmodular control architecture that is
easily deployed and easily scaled.
In closing, here are a few of thecapabilities that the CIP Motion peerto-peer connection might enable in a
motion system: Master axis produced/consumed information for
distributed camming andgearing synchronization
 Line controller machine motion
coordination andsynchronization via produced
virtual axis
 Coordinated robot operation e.g. synchronized interpolated
move following a common
virtual master axis
 Inverter/Converter control
synchronization
 Distributed drive I/O resources- auxiliary feedback andregistration
 Distributed motion planning
About the author
Steve Zuponcic chairs ODVA’s Special
Interest Group on Distributed Motion(SIG). Currently the SIG is engaged
in working on enhancements to the
ODVA specification for the technology
described herein. Mr. Zuponcic is
employed by ODVA principal andfounding member Rockwell
Automation, where he is an
Applications Engineering Manager.
For more information
Contact ODVA via email at odva@odva.org or visit
its web site at www.odva.org.
Copyright ©2012 ODVA, Inc. All rights reserved. For
permission to reproduce excerpts of this material,with appropriate attribution to the author, pleasecontact ODVA on:
TEL +1 734-975-8840
FAX +1 734-922-0027
EMAIL odva@odva.org
WEB www.odva.org
CIP, CIP Motion, and EtherNet/IP are trademarks of
ODVA, Inc. Other trademarks are property of theirrespective owners.

Page 8 of 8