T23 – High Performance Motion Over EtherNet/IP

T23 – High Performance Motion Over EtherNet/IP

Agenda EtherNet/IP “CIP Motion” Technology Review
EtherNet/IP Motion Product Overview Motion Functionality

Integrated Motion on EtherNet/IP
EtherNet/IP Capabilities and Devices Logix Integrated Motion for EtherNet/IP drives Kinetix® and PowerFlex® drives ControlLogix® and CompactLogix™ controllers System benefits High performance drive control on EtherNet/IP with all the features and capability of integrated motion Complete machine control on a single, flexible EtherNet/IP network architecture Deploy drives and any other EtherNet/IP device on a common network Maximum flexibility – topology, control platforms, Servo & AC drives Standard ethernet solution allows use of COTS components and helps ensure compatibility with existing ethernet installations Open and broadly adopted technology PLUS Logix Motion Drive Control

Complete Machine Control on EtherNet/IP
With the addition of Motion drive support on EtherNet/IP it is now possible to support your entire machine with one network – EtheNet/IP. A single network architecture offers significant advantages including… Reduced system life cycle cost – fewer components to purchase, implement, commission and maintain Improved system performance – 100 mbit throughput, with time-synchronized control of multiple devices on a common network Simplified integration – single network infrastructure with catalog number driven automatic configuration, all supported with a single software package – RSLogix 5000. Access to extensive process and control system data with 100 mbit throughput makes control and process system monitoring and optimization easy

Topology Flexibility

CompactLogix™ 5370 with Integrated Motion on EtherNet/IP
JF Compact Logix L36ERM Plant Network Stratix 5700 Kinetix 5500 First, the machine builder could work with the customer to identify a unique subnet of network addresses to use for the machine, the machine could then be isolated with the plant network distribution switch. This will segment the machine from the rest of the network, protecting it from exposure to broadcast storms or other events on the plant network. This approach requires no additional configuration or features in the machine level switch. Layer 3 switches on the plant network will route communications to and from the machine when needed. Configuring the layer 3 switch is a 3 step process (set up VLAN for the machine network, tie that VLAN to a physical port (s) on the switch that is connected to the machine, set up the IP address for that interface (the IP address will be the GW address on your machine network devices that will need to communicate outside of the machine.) Benefits to this approach include: Protection from machine interference from the plant network (and vice versa). security – I often hear arguments that a second Interface for machine control is secure from competitors, but if someone has a tool (or writes their own tool to traverse that connection between the 2 cards, they will have access, (unless they are using an 1756-EN2TSC module that is available for ControlLogix ). Subnet/VLAN isolation allows a user to put security (using a security appliance on the network ie. Cisco ASA for example) around the machine subnet or VLAN to control access using standard security methods like firewall rules and access control lists. For example, a client on a remote user VLAN may be required log in through an authentication process that will track their access on the machine subnet or VLAN. Another benefit is remote access to Diagnostic data for ALL devices on the Machine network. For example if I wanted to use a web client to look at the HMI remotely or a particular device on the machine, it would not be able to traverse the path between the two Ethernet cards in the controller, because HTTP traffic will not traverse that path. A Third benefit would be network resiliency. Communications between the Machine and Plant operations is often critical and the cable’s path between the Machine and plant level switch may be long and treacherous making the risk of cable failure higher. ArmorBlock I/O POINT I/O PV+ EOI PowerFlex 525 6

ControlLogix® L7x with Integrated Motion on EtherNet/IP
PV EOI ControlLogix PowerFlex 525 Kinetix 5500 Kinetix 5500 Kinetix 5500

Separate Connection per Drive
Single coarse update rate throughput Drive attribute write Drive attribute read Registration arming MRP execution Extensive diagnostic information Drive/motor Network connection Time stamped fault/alarms log Device Level Ring (DLR) single fault tolerance Automatic rerouting with drive ride through Network diagnostic information High speed, single coarse update rate throughput for drive read and write attributes Attributes can be used for many high speed application program based functions

Time Synchronization We all rely on and require time synchronization for common, everyday tasks or activities. Almost everything we do in our lives starts or ends based on time or a clock, and as such it is important that are our clocks are synchronized. Time synchronization is equally important in automation and control applications like… Input timestamping Sequence of events recording Motion control Let’s begin by discussing the need for time synchronization… We all rely and require time synchronization for common, everyday tasks or activities. Almost everything we do in our lives starts or ends based on time. If individuals didn’t synchronize their clocks…our world would be chaotic and unpredictable at best. Simple tasks or activities that need to occur at a certain instance of time…would be relative to our own individual clock or concept of time. Attempts to coordinate events between a group of individuals would be difficult, almost impossible. Time synchronization is equally important in automation and control applications like: Input timestamping Sequence of events recording And even motion control, which is the primary focus of this learning series. Basically, time synchronization is required for any application that is highly distributed, requiring improved control coordination. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Applications for Time Synchronization
Sequence of Events Measurements Timestamped Data Logging Coordination with GPS Time Typical Timestamped Input Let’s take a closer look at couple of typical applications that require time synchronization. Imagine we have a controller and a distributed I/O device…and let’s also imagine that some type of sensor is connected to one of the digital inputs on the I/O device. ----CLICK---- Now, if each device contains a clock…and if both clocks are synchronized together, then as the digital input transitions…let’s say from OFF to ON…the distributed I/O device can capture a timestamp for this input event. This timestamp information is now relevant to the controller since both clocks have been synchronized together. This information…data & timestamp…can then be sent across the network and used by the controller. Since both clocks are synchronized, the controller can use the information for sequence of events measurements or timestamped data logging. In the past, these type of measurements were typically performed via local I/O to ensure accurate timestamp information of the event was recorded or to coordinate events between multiple source devices. Now, distributed I/O devices can provide more than just “data”…instead they provide “information” about the process. In addition, both clocks could be synchronized to a GPS receiver, providing an accurate master reference for system time. The same sort of relationship holds true for scheduled outputs as well. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Applications for Time Synchronization
Sequence of Events Measurements Timestamped Data Logging Coordination with GPS Time Scheduled Outputs Synchronized Actuation Motion Control Typical Scheduled Output Again, imagine we have a controller and a distributed I/O device…which is now connected to some sort of output device. ----CLICK---- Again, each device contains a clock and both clocks are synchronized together. The controller can then send information…time & data…across the network to the distributed I/O device. The I/O device can then actuate or turn “on” its output at the scheduled time. Since both clocks are synchronized, the resulting function at the I/O device is scheduled outputs or synchronized actuation. The only requirement is that the data & time information reach the I/O device prior to the time the event is scheduled to occur. Synchronized actuation is essentially the fundamental principle of motion control, position data & time information is sent in advance to the servo drive. If the clocks are synchronized, the drive positions its motor shaft at the target position at the target time. We will speak more about motion control and the importance of time synchronization in another presentation. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Time Synchronization Protocols
Network Time Protocol (NTP) Low 10’s of milliseconds time synchronization over wide area networks (WAN) Sub millisecond time synchronization over local area networks (LAN) Widely used and successful protocol Global Positioning System (GPS) Sub 10 ns time synchronization Controlled by the US Department of Defense Costly to deploy GPS receiver at each node Requires GPS signals CIP Sync Time synchronization down to 100 ns Based on IEEE 1588 Precision Time Protocol (PTP) Synchronization of devices over CIP networks PTP fills niche not properly addressed by NTP or GPS Let’s now take a look at 2 of the dominant time synchronization protocols and see how they compare to Rockwell Automation’s solution…CIP Sync, the focus of this presentation. Network Time Protocol or NTP can achieve time synchronization in the low 10’s of milliseconds range on wide area networks or WANs…over the internet, for example…and sub millisecond over local area networks or LANs. NTP is arguably the most widely used and most successful protocols…however it may not provide the time accuracies required in control applications. Global Positioning System or GPS can achieve sub 10 ns time synchronization. GPS is operated and controlled by the US Department of Defense…and as such, the US government dictates the accuracy of the system and if they choose can restrict or limit the accuracy. GPS systems can be costly to deploy if a receiver is required at each node and also require a GPS signal to be accessible, which in some cases might not be available. Well how does Rockwell Automation’s solution…CIP Sync…compare to both protocols. ----CLICK---- CIP Sync is the name given to the time synchronization technology for the Common Industrial Protocol or CIP. CIP Sync is based on the IEEE 1588 Precision Time Protocol, which provides a standard mechanism to synchronize clocks across a network of distributed devices. CIP Sync is basically the deployment of the Precision Time Protocol over a CIP network which includes but is not limited to EtherNet/IP. The Precision Time Protocol is designed to fill a niche not well served by the NTP and GPS protocols. The precision time protocol is designed for systems requiring very high accuracies beyond those attainable using NTP. It also is designed for applications where full GPS deployment is not feasible…i.e. installing a receiver at each node or lack of a GPS signal. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Built on Open, Global Standards From ODVA

IEEE 1588 Precision Time Protocol
“Precision Clock Synchronization Protocol for Networked Measurement and Control Systems” Commonly referred to as Precision Time Protocol (PTP) Designed for, but not limited to, local area networks like Ethernet Nanosecond level time synchronization ±100 ns  hardware assist clock ±100 µs  software assist clock Advantages: Minimal installation and administration required Wide spectrum of clock accuracy Low cost, high degree of accuracy and precision We will speak more about CIP Sync later in the presentation…let’s first focus on the IEEE 1588 Precision Time Protocol. The formal title for the IEEE 1588 standard is: “Precision Clock Synchronization Protocol for Networked Measurement and Control Systems” or more commonly referred to as the Precision Time protocol or just simply PTP. The IEEE 1588 standard specifies a protocol to synchronize independent clocks running on separate nodes of a distributed measurement and control network to a high degree of accuracy and precision. The Precision Time Protocol has been designed for, but not limited to local area networks like Ethernet. The standard was initially released in 2002, but later revised in 2008. Version 1 introduced ordinary and boundary clocks. Version 2 added support…most notably for transparent clocks and hybrids…which we will discuss later in more detail. In its most basic form, the Precision Time Protocol is intended to be administration free. The clocks communicate with each other over the network and establish a master-slave relationship or hierarchy of clocks in the network. The intent is that the devices manage the synchronization of clocks automatically. Not all devices require the same level of accuracy in PTP…and because of the this, a wide spectrum of clock accuracy is supported to best fit the needs of the end device. The Precision Time Protocol was designed with minimal resource requirements for both network bandwidth and capability in the devices…yet are able to achieve a high degree of accuracy and precision. PTP can use other protocols, like GPS or NTP, to provide a master reference clock. This allows separate PTP networks to be synchronized to a common clock or provide relative synchronization between protocols. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Example System of Clocks
Ordinary clock (Grandmaster) Boundary clock Segments synchronization path Hybrid: Transparent clock & Ordinary clock Transparent clock Ordinary clock (Slave) Let’s now take a closer look at an example of a PTP system of clocks. A system will typically consist of one or more devices capable of becoming a master clock, with other devices serving as slave clocks. Normally one master will be designated as the grandmaster clock. Typically, infrastructure devices like boundary clocks or transparent clocks are used to help distribute the Precision Time Protocol across the network…ensuring accurate time synchronization. ----CLICK---- An ordinary clock consists of a single connection port…or more commonly referred to as PTP port…and can be assigned as either a master, slave, or even grandmaster depending on the best master clock algorithm. Typically, ordinary clocks are devices like a GPS receiver, logic controller, or other devices that are located at the end nodes of the network. Boundary clocks contain multiple PTP ports that establish separate PTP domains by segmenting the synchronization path between Master and Slave clocks. Boundary clocks function as a “boundary” or interface between PTP synchronization segments. Transparent clocks are fundamentally different from boundary clocks. Instead of segmenting the synchronization paths between master and slave clocks, transparent clocks help compensate for the propagation time through the network and hence, appear as a “transparent” or almost non-existent interface between master and slave clocks. Boundary and transparent clocks are typically implemented in network switches. In addition, transparent clocks are found in end devices that are intended to be used in daisy chain or linear topologies. Systems may also contain hybrid devices which include multiple types of clocks, for example, a hybrid may contain both an ordinary clock and a transparent clock. Typically, hybrid devices contain 2 or more ports with embedded switch technology. An example of a hybrid device is the Kinetix 6500 servo drive, which contains both an ordinary and transparent clock. One takeaway from this example is that a system may consist of many different types of PTP clocks. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Best Master Clock Algorithm (BMCA)
Strict arbitration process performed by each node to determine its status i.e. Master or Slave The “best” overall clock in the system is referred to as the Grandmaster The Grandmaster will be the ultimate source of time All other clocks in the system are ultimately synchronized to the Grandmaster Announce messages are sent containing clock information Announce messages are sent periodically from potential Master clocks Each node compares its credentials to those contained in the Announce message The better of the 2 clocks will become a Master, the other will be a Slave The best master clock algorithm performs a strict arbitration process employed by each node to determine its status…i.e. is the node a master or slave. The best master clock algorithm also determines the “best” overall clock in the system. The “best” clock is referred to as the grandmaster clock. All other clocks in the system are ultimately synchronized to the grandmaster. Announce messages are sent periodically by any port claiming to be a master. The announce messages basically contain information about “how good the master clock is.” When a node receives an announce message from another clock…it compares its credentials to those contained in the announce message in order to determine who is the best clock. The better of the 2 clocks will serve as master, while the lesser as a slave. The process is repeated until the status for all clocks has been determined. Factors used in the best master clock algorithm include: Clock class or the relative measure of clock quality. Accuracy or the closeness of the clock to absolute reference. For example, a GPS receiver at 250 ns to absolute reference is better than a hand set device at 10 sec. Variance or the measure of clock stability. And lastly, priority…which can be used as an override mechanism to promote one clock over another. In the event of a tie between equally matched clocks, the clock ID is used as a tie breaker. The clock ID typically includes the MAC address or serial number of the device. Tie situations can also be prevented by setting the clock priority on a device. If changes are made to the system…i.e. clocks are added or removed…the best master clock algorithm will automatically re-evaluate the system and if need be re-assign clock status. For example, if the grandmaster is removed from a system, the best master clock algorithm will attempt to designate a new grandmaster out of the remaining clocks. Conversely if a better clock is added, the best master clock algorithm may designate this new clock as the grandmaster. The best master clock algorithm requires minimal administration as the clocks will determine their status automatically. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Best Master Clock Algorithm (BMCA)
Factors used in the BMCA include: Clock class – relative measure of quality Accuracy – closeness to absolute reference (GPS ~250 ns vs. hand set ~10 sec) Variance – measure of clock stability Priority 1, 2 – used as override mechanism In the event of a tie between equally matched clocks, the clock ID is used as a tie breaker The best master clock algorithm performs a strict arbitration process employed by each node to determine its status…i.e. is the node a master or slave. The best master clock algorithm also determines the “best” overall clock in the system. The “best” clock is referred to as the grandmaster clock. All other clocks in the system are ultimately synchronized to the grandmaster. Announce messages are sent periodically by any port claiming to be a master. The announce messages basically contain information about “how good the master clock is.” When a node receives an announce message from another clock…it compares its credentials to those contained in the announce message in order to determine who is the best clock. The better of the 2 clocks will serve as master, while the lesser as a slave. The process is repeated until the status for all clocks has been determined. Factors used in the best master clock algorithm include: Clock class or the relative measure of clock quality. Accuracy or the closeness of the clock to absolute reference. For example, a GPS receiver at 250 ns to absolute reference is better than a hand set device at 10 sec. Variance or the measure of clock stability. And lastly, priority…which can be used as an override mechanism to promote one clock over another. In the event of a tie between equally matched clocks, the clock ID is used as a tie breaker. The clock ID typically includes the MAC address or serial number of the device. Tie situations can also be prevented by setting the clock priority on a device. If changes are made to the system…i.e. clocks are added or removed…the best master clock algorithm will automatically re-evaluate the system and if need be re-assign clock status. For example, if the grandmaster is removed from a system, the best master clock algorithm will attempt to designate a new grandmaster out of the remaining clocks. Conversely if a better clock is added, the best master clock algorithm may designate this new clock as the grandmaster. The best master clock algorithm requires minimal administration as the clocks will determine their status automatically. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Master-Slave Hierarchy Example
Assume we have a network of ordinary clocks, separated by boundary clocks No hierarchy has been established Grandmaster M S Clocks send out Announce messages to other clocks Clocks use information in the Announce message to determine the Master-Slave hierarchy based on BMCA “Best” overall Master clock  Slave M M Master-Slave Pair S S Let’s now take a look at an example master-slave hierarchy which illustrates the best master clock algorithm. Assume we have a network of ordinary clocks separated by boundary clocks. No hierarchy has yet been established…let’s assume that devices were connected and then powered up for the very first time. Notice that the boundary clocks in this example segment the network. The ordinary clocks are not directly connected to each other, but are instead separated by 1 or even 2 boundary clocks. Boundary clocks typically have one PTP port designated as a slave, while all of the other ports serve as a master. We will discuss boundary clocks in more detail later in the presentation. ----CLICK---- All clocks claiming to be a master begin sending out announce messages to other clocks. The clocks use the announce messages to determine their status as either a master or slave based on the best master clock algorithm. Clocks that receive the announce message compare their credentials to those contained in the announce message. As a result of the arbitration process, the better of the 2 clocks will serve as the master, the lesser clock as a slave. This process continues, determining the “best” overall master clock through to each of the slave clocks. Once the process the has been completed, the “best” overall clock is selected as the grandmaster. Boundary clocks create a collection of master-slave pairings, which separate the grandmaster from its slaves. However, all of the clocks in the system are ultimately synchronized to the grandmaster clock. M M The “best” overall clock is selected as the Grandmaster Boundary clocks create a collection of Master-Slave pairing S S Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

PTP Synchronization Timing Messages
PTP messages Transmitted between Master and Slave clocks Frequency synchronization Sync message Follow_Up message Sync messages sent once every second Phase / Delay measurement Delay_Req message Delay_Resp message Let’s take a look at how time synchronization is achieved between master and slave clocks. Synchronization between clocks is accomplished via a series of PTP timing messages that are transmitted master to slave. The PTP messages help the slave clocks make frequency adjustments or adjust the rate at which local clocks meter time. The messages also allow the slave clocks to measure the phase or delay between the master and slave. Frequency synchronization utilizes the sync and follow up messages. The sync message is sent on a periodic basis, typically once every second. The phase or delay measurement utilizes the delay request and delay response messages. The diagram on the right-hand side illustrates the 4 PTP messages, the sending/receiving relationship, timing information contained, and the order in which the messages are sent. As a result of the PTP messages, the slave clock collects the 4 timestamps: t1 thru t4 Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

PTP Time Synchronization Example
Master sends Sync message to Slave Sent every 1 sec Slave records the time (t2) the message was received t2 = 12 ticks Example: Clocks offset by 10 ticks Transmit delay in each device: 1 tick Propagation delay between devices: 2 ticks Let’s take a look at simple PTP synchronization example to illustrate how the PTP messages and the timestamp information is used to calculate the offset from master. In the following example…assume we have a master and a slave clock. The two clocks are offset by 10 ticks. The transmit delay in each device or the time it takes a message that is ready to be transmitted before it is actually transmitted is 1 tick. The propagation delay or the time it takes a message to pass through the network…which may include multiple network switches…is 2 ticks. Let’s begin… ----CLICK---- The master first sends out the sync message to the slave…typically sent every 1 sec. The slave records the time t2 the sync message was received. In our example…the sync message was ready to be transmitted at 19 master ticks, but wasn’t actually transmitted until 20 master ticks. The slave received the sync message at 12 slave ticks. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Master sends Follow_Up message Contains the time (t1) the message was transmitted t1 = 20 ticks Example: Clocks offset by 10 ticks Transmit delay in each device: 1 tick Propagation delay between devices: 2 ticks The master then sends out the follow up message to the slave which contains time t1 the sync message was transmitted. In our example…the sync message was transmitted at 20 master ticks. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Clocks offset by 10 ticks Transmit delay in each device: 1 tick Propagation delay between devices: 2 ticks Slave sends Delay_Req message to Master Slave records the time (t3) the message was transmitted t3 = 26 ticks Next the slave sends out the delay request message to the master. The slave records the time t3 the delay request message was transmitted. In addition, the master also records the time t4 the delay request message was received. In our example…the delay request message was ready to be transmitted at 25 slave ticks, but wasn’t actually transmitted until 26 slave ticks. Please note the delay request message was received by the master at 38 master ticks. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Clocks offset by 10 ticks Transmit delay in each device: 1 tick Propagation delay between devices: 2 ticks Master responds with Delay_Resp message Contains the time (t4) the Delay_Req message was received t4 = 38 ticks The master then responds to the delay request message and sends out the delay response message to the slave. The delay response message contains time t4 the delay request message was received by the master. In our example…the delay request message was received at 38 master ticks. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Measured Timestamps: t1 = 20 ticks t2 = 12 ticks t3 = 26 ticks t4 = 38 ticks Calculations: Calculate the Master-to-Slave & Slave-to-Master Delays dm-s= t2 – t1= 12 – 20 = –8 ticks ds-m = t4 – t3 = 38 – 26 = 12 ticks Calculate the One-Way (Propagation) Delay dprop= ½ × (dm-s + ds-m) dprop = ½ × [(t2 – t1) + (t4 – t3 )] dprop = ½ × [(12 – 20) + (38 – 26)] = 2 ticks Calculate the Offset From Master. toffset= dm-s– dprop toffset = ½ × [(t2 – t1) – (t4 – t3 )] toffset = ½ × [(12 – 20) – (38 – 26)] = –10 ticks Frequency and system offset adjustments are made to the Slave Clock Now that all of timestamp information…t1 through t4…have been collected by the slave, the offset from master calculation can be made. ----CLICK---- The master-to-slave and slave-to-master delays are first calculated. The master-to-slave delay is -8 ticks, while the slave-to-master delay is 12 ticks. Notice that both results do not account for the propagation delay through the network. Next the one-way or propagation delay is calculated. The one-way delay is 2 ticks. Lastly, the offset from master is calculated. The offset from master is -10 ticks, which means the slave is 10 ticks behind the master clock. Notice that the offset from master correctly accounts for the propagation delay through the network. Now that all of the calculations have been completed, frequency and system offset adjustments can then be made to the slave clock. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Open Loop Comparison of Master and Slave Clocks with Different
Tunable Clock Simply resetting the slave clock’s value to the master’s on a periodic basis will not resolve the problem of differing frequencies Tuneable clocks allow for the frequency of the individual clocks to be synchronized against the master so that time is metered the same The natural frequency of any two crystals prevents two clocks from metering time precisely the same way Master Clock Slave Clock Time Device Measurement Open Loop Comparison of Master and Slave Clocks with Different Natural Frequencies Value Adjustment Frequency Adjustment Let’s look at why it is important to employ a tunable clock to achieve proper time synchronization. For our example…take 2 clocks, a master and a slave, and start them at the very same instance in time. No 2 clocks will meter time at exactly the same rate, the natural frequencies of the individual clock crystals will differ. As a result, the clocks eventually begin to diverge and will no longer remain synchronized. ----CLICK---- One approach to correct this is to periodically reset the slave clock’s value to the master’s. However, this will not address the issue of the differing frequencies or the rate at which the clocks meter time. This approach will only bring the clocks into precise synchronization for a moment, after which they will begin to diverge once again. To properly synchronize the clocks, a tunable clock is needed. Tunable clock allow the frequencies of the individual clocks to be synchronized to the master, so that time is metered at the same rate. Now, in addition to adjusting the frequency, the value or offset is also adjusted so that both master and slave clocks are truly synchronized. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Boundary Clocks Boundary clocks function as an interface between PTP synchronization segments Consists of multiple PTP ports Typically 1 PTP port is designated as a Slave Remaining ports as Masters Upstream PTP messages are not passed through a boundary clock Instead new PTP messages are generated at each master PTP ports and passed to the downstream Slave ports ClockClockClock… time synchronization Let’s now return to discussing the PTP clocks in more detail. Boundary clocks are typically employed in network switches and act as in interface or “boundary” between PTP synchronization segments. A boundary clock consists of multiple PTP ports. Typically 1 PTP port is designated as a slave, while all of the remaining ports serve as masters. In some instances, the boundary clock may be selected as the grandmaster clock. PTP messages sent from the upstream master are intercepted by the slave PTP port in the boundary clock, hence the term “boundary”. The PTP messages received by the slave PTP port are not allowed to pass through the switch…instead, each master PTP port will generate new PTP messages and then pass these messages to the downstream slaves. Due to the inherent segmented nature of boundary clocks, it is not necessary to compensate for communication path delay as time is synchronized from one clock to the next. Because of the cascaded clock to clock time synchronization, boundary clocks are most effective when deployed in networks where the ordinary clocks are not separated by more than a few cascaded boundary clocks from the grandmaster. Long cascades of boundary clocks can lead to degradation of timing accuracy. Hence, boundary clocks are not well suited for long linear or daisy-chained topologies. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Transparent Clock – Correction Field
Measures delay through the switch Residence Time = Egress Timestamp – Ingress Timestamp Adds delay to Correction Field of PTP event messages Correction Field = Correction + Residence Time Sync & Delay_Req messages Slave nodes use the Correction Field to adjust timestamps To address long linear network topologies, the transparent clock was introduced. Transparent clocks are fundamentally different from boundary clocks. Instead of segmenting the synchronization paths between master and slave clocks, transparent clocks help compensate for the propagation time through the network and hence, appear as a “transparent” or almost non-existent interface between master and slave clocks. Transparent clocks, like boundary clocks, are typically employed in network switches…but are also common in hybrid devices. A transparent clock measures the residence time or the transit time between when a message is received and then transmitted. Transparent clocks contain a free running clock which is used to record timestamp information as PTP event messages enter or leave the switch. As the PTP event message first enters the ingress port, a timestamp is recorded. Similarly, as the PTP event message is ready to leave the egress port, another timestamp is recorded. Based on these 2 timestamps, the residence time or transit time is calculated. The residence time is then added to the correction field of the network protocol header and sent as a part of the PTP event message. The PTP event messages include only the sync and delay request messages. The correction field ensures that downstream clocks will be able to properly compensate for switch latency. As mentioned during our discussion of boundary clocks, transparent clocks are effective in long linear or daisy-chained topologies. Let’s examine a simple example which will help illustrate why transparent clocks are so well suited for long linear topologies… Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Transparent Clock Linear Topology Example
Adjustments made to the each correction field in PTP messages Correction field at the end slave node = ∑ (Residence Times) The result is an end-to-end propagation delay measurement The inherent nature of a transparent clock allows cascaded connections to properly compensate for end-to-end propagation delay caused by variable switch latency. As PTP event messages pass through cascaded transparent clocks, the correction field is summed with the residence time at each node and then passed onto the next. ----CLICK---- The result is that the node at the end of the line…node n+1 in our example…can compensate for communication path delay with minimal impact to timing accuracy. Transparent clocks allow for multiple slaves to be synchronized directly to one master. The one downfall of this relationship is the master clock is required to process additional PTP delay request messages from each individual slave. Now that we have discussed both boundary and transparent clocks in detail…let’s briefly summarize PTP clocks. ∑ (ΔT) ΔTtotal = ΔTtotal + ΔT1 ΔTtotal = ΔTtotal + ΔT2 ΔTtotal = ΔTtotal + ΔTn Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

PTP Clock Summary Ordinary clock 1 PTP port Grandmaster or Slave
Boundary clock Typically a network switch – multiple PTP ports, can serve as Grandmaster Segments the synchronization path between Master and Slave clocks Appear as a “boundary” or interface between Grandmaster and Slaves Not well suited for large linear or daisy-chain network topologies An ordinary clock consists of a single PTP port…and can be assigned as either a master, slave, or even grandmaster depending on the best master clock algorithm. Typically, ordinary clocks are devices like a GPS receiver, logic controller, or other devices that are located at the end nodes of the network. Boundary clocks are typically implemented in network switches. Boundary clocks contain multiple PTP ports that establish separate PTP domains by segmenting the synchronization path between master and slave clocks. Typically 1 PTP port is designated as a slave, while all of the remaining ports serve as masters. In some instances, the boundary clock may be selected as the grandmaster clock. Boundary clocks function as a “boundary” or interface between PTP synchronization segments. Remember, boundary clocks are not well suited for large linear or daisy-chained network topologies. Like boundary clocks, transparent clocks are typically implemented in network switches. Transparent clocks are fundamentally different from boundary clocks. Instead of segmenting the synchronization paths between master and slave clocks, transparent clocks help compensate for the propagation time through the network and hence, appear as a “transparent” or almost non-existent interface between master and slave clocks. Transparent clocks allow for multiple slaves to be synchronized directly to one master or a “1-to-N” master to slave ratio. Transparent clocks were designed for long linear or daisy-chained network topologies. Hybrid devices include multiple types of clocks, for example, a hybrid may contain both an ordinary clock and a transparent clock. Typically, hybrid devices contain 2 or more ports with embedded switch technology. An excellent example of a hybrid device is the Kinetix 6500 servo drive, which contains both an ordinary and transparent clock. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

PTP Clock Summary Transparent clock
Typically a network switch – multiple PTP ports Compensates for propagation delay in the network Appear as a “transparent” or almost non-existent interface between Master and Slave clocks Allow for multiple Slaves to be synchronized directly to one Master (1:N) Designed for large linear or daisy-chain network topologies Hybrid Can consist of multiple clocks types Example, device may contain both an ordinary & transparent clock An ordinary clock consists of a single PTP port…and can be assigned as either a master, slave, or even grandmaster depending on the best master clock algorithm. Typically, ordinary clocks are devices like a GPS receiver, logic controller, or other devices that are located at the end nodes of the network. Boundary clocks are typically implemented in network switches. Boundary clocks contain multiple PTP ports that establish separate PTP domains by segmenting the synchronization path between master and slave clocks. Typically 1 PTP port is designated as a slave, while all of the remaining ports serve as masters. In some instances, the boundary clock may be selected as the grandmaster clock. Boundary clocks function as a “boundary” or interface between PTP synchronization segments. Remember, boundary clocks are not well suited for large linear or daisy-chained network topologies. Like boundary clocks, transparent clocks are typically implemented in network switches. Transparent clocks are fundamentally different from boundary clocks. Instead of segmenting the synchronization paths between master and slave clocks, transparent clocks help compensate for the propagation time through the network and hence, appear as a “transparent” or almost non-existent interface between master and slave clocks. Transparent clocks allow for multiple slaves to be synchronized directly to one master or a “1-to-N” master to slave ratio. Transparent clocks were designed for long linear or daisy-chained network topologies. Hybrid devices include multiple types of clocks, for example, a hybrid may contain both an ordinary clock and a transparent clock. Typically, hybrid devices contain 2 or more ports with embedded switch technology. An excellent example of a hybrid device is the Kinetix 6500 servo drive, which contains both an ordinary and transparent clock. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

CIP Sync Offset Clock Model
Now that we have discussed the Precision Time Protocol, let’s move our focus back to CIP Sync and its implementation of time synchronization. CIP Sync defines an offset clock model to address the requirements for industrial control applications. This model is needed, because even though the Precision Time Protocol defines a mechanism for distributing and synchronizing time, it does not define a mechanism to compensate for step changes in time that may occur at the grandmaster clock source. The local clock is synchronized to the master clock’s frequency or tick rate…not the master’s absolute time value. In this model, the Precision Time Protocol is used to discipline the local clock such that it ticks at the same rate as the master. The device then maintains an offset between the local clock time and system time. A small delta change in time will cause the device to make a small adjustment to the offset and to continue to “tune” its clock. A large change in time will cause the device to update its offset but not “tune” its clock. Cyclic events can be scheduled based on the local clock and will not be affected by large step changes in time. Synchronized time between clocks Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

CIP Sync System of Clocks
Local time independent from other devices Provides offset between local & system time System time is shared amongst all devices Let’s now take a look at the relationship between the local clock, system time offset, and the system time for a system of clocks. In this example, each device is a part of a network of devices that share the same concept of system time. Each device also has a local clock value based on a frequency-disciplined timer and is related to system time via the system time offset. This type of system allows each device to maintain a local time independent from all other devices, but yet share a common notion of system time. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

CIP Sync System Time Representation
64-bit value (LINT) Expressed in either nanoseconds or microseconds Starting January 1, 1970 at 12:00am Includes leap seconds Does not include time zones or daylight savings time Referenced to GMT Converted from IEEE 1588 PTP time System Time = PTP Time + Leap Seconds Let’s examine how CIP Sync represents system time. CIP Sync represents System time as a 64-bit LINT or long-integer value that is expressed in either nano or microseconds. The starting date/time for CIP Sync system time is January 1, 1970 at 12:00am. System time is adjusted for leap seconds, but not local time zones or daylight savings time…it however represents time at the 0th meridian or Greenwich Mean Time. System time can be related to PTP time by adjusting for leap seconds. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Quality of Service Quality of Service prioritizes the order in which traffic is sent Utilizes the Differential Services Code Point (DSCP) field in IP header Ensures timely data delivery of high priority traffic – i.e. PTP messages, Motion, etc 1588 PTP Messages Ethernet Switch Traffic Type DSCP (Priority) Time Sync 59, 47 (Highest) Motion I/O 31, 43, 47 Other 27 (Lowest) Motion Control Messages Distributed I/O Messages We have spent a majority of this presentation discussing many of the components behind how the CIP Sync and PTP maintain time synchronization, let’s briefly discuss one additional topic that helps ensure that all of those time critical PTP messages are delivered in a timely manner. Quality of service or QoS prioritizes the order in which traffic is processed in network switches. QoS helps reduce or minimize network delay. QoS is important as PTP messages are time critical and need to be transmitted with minimal delay. Priority is assigned based on the differential services code point or DSCP field located in the IP header. Let’s take our example above. Let’s say PTP, motion control, distributed I/O, and other device message frames arrive at a switch at the same instance of time. The pink PTP frames have the highest priority or DSCP value and as such will be processed by the switch first. The green motion frames are next, followed by the red I/O and blue other device frames. The main concept of QoS is…whenever possible…to process the highest priority data first. This ensures time critical data is delivered in a timely manner. We will speak more about QoS in another presentation. Other Devices Messages Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

Summary CIP Sync is the technology that synchronizes time over CIP Networks Precise time synchronization is critical in automation & control applications, including Motion control CIP Sync is based on the IEEE 1588 Precision Time Protocol (PTP) PTP synchronizes independent clocks running on separates nodes to a high degree of accuracy with minimal cost & administration PTP achieves synchronization through mechanisms like Boundary & Transparent clocks, constructing a hierarchy of clocks CIP Sync also utilizes Quality of Service (QoS) to prioritize traffic, ensuring time critical data is delivered in a timely manner We’ve covered a number of concepts in this presentation regarding CIP Sync & PTP…let’s briefly recap some of the more important points. CIP Sync is the technology that synchronizes time over CIP Networks. Precise time synchronization is critical in automation & control applications…especially for Motion control…which we will discuss in another presentation. CIP Sync is based on the IEEE 1588 Precision Time Protocol. PTP synchronizes independent clocks running on separates nodes to a high degree of accuracy with minimal cost & administration. PTP achieves synchronization through mechanisms like Boundary & Transparent clocks, constructing a hierarchy of clocks. Lastly…CIP Sync utilizes Quality of Service to prioritize traffic, ensuring time critical data…like PTP or Motion control messages…are delivered in a timely manner. Integrated Motion on EtherNet/IP Learning Series Copyright © 2010 Rockwell Automation, Inc. All rights reserved.

EtherNet/IP Motion Product Overview Future Motion Functionality

Integrated Motion on EtherNet/IP Product Suite (V21)
ControlLogix L7x, & GuardLogix controllers Up to 100 drives per controller Multiple Controllers > 100 axes CompactLogix 5370 controllers Up to 16 drives per controller Stratix switches (Stratix 2000™, 6000, 5700, 8000) Logix Designer, Motion Analyzer, Integrated Architecture Builder (IAB) Design, simulation, configure, program, commission, maintain PowerFlex and Kinetix drives Kinetix 6500, Kinetix 350, Kinetix 5500, PF 755 600W – 1500 KW High performance Motion I/O 1756 SOE and Scheduled output (PLS) ArmorBlock® SOE and Scheduled output (PLS) Integreated Motion on EtherNet/IP Encoder Kinetix® Kinetix® 350 Servo Drive Servo Drive A broad range of drive/motor solutions with support from 1 to 700 HP with common configuration, programming, commissioning, diagnostics, and device maintenance Position, velocity, and torque control options ADR support provides automatic drive flashing and reconfiguration on drive replacement – plug and run, no software or manual intervention needed Advanced safety from improved machine uptime Safe off, safe speed, safe direction -> drive based safety EtherNet/IP CIP Safety – future Kinetix® PowerFlex® 755 Servo Drive AC Drive

Logix Controller Portfolio
1756-L73S 1756-L74 1756-L73XT 1756-L72S 1756-L73 1756-L72 1756-L71S 2012 2012 1756-L71 2012 2012 1756-L65 1756-L64 1756-L63XT 1756-L63 / L63S 1769-L36ERM 1756-L62 / L62S 1756-L61 / L61S 2012 Application Size\Capability 1768-L45 1769-L2ER 1768-L4xS 1768-L43 2012 1769-L35E 1769-L35CR 2012 1769-L32E 1769-L1ER 1769-L32C 1769-L31 Price 1769-L23x 38

CompactLogix 5370 Controllers without Integrated Motion
Controllers with Integrated Motion L30ER/L30ER-NSE L33ER L30ERM L33ERM L36ERM 4 axis 8 axis 16 axis L27ERM-QBFC1B L24ER-QB1B L24ER-QBFC1B L18ERM-BB1B 2 axis L16ER-BB1B L18ER-BB1B General Purpose Machine Controller Small Stand-Alone & Ancillary Equipment Controller Small Machine Controller Enhanced platform with 12 new additions to provide better features and faster return of investment

Logix Designer Motion Support

Configuration Kineitx 6500 Conveyor = PowerFlex 755 Vhz
Kinetix Conveyor = PowerFlex 755 Vhz Feed 1 = PowerFlex 755 position Feed 2 = Kinetix 6500 position PowerFlex 755 1 configured for Vhz PowerFlex 755 2 configured for Position Kineitx 6500 AC drive (PowerFlex) and Servo drive (KInetix) integrated motion support RSLogix 5000 integrated motion configuration, programming, commissioning, device support for PowerFlex and Kinetix PowerFlex 755 is now supported with the full integrated motion instruction set Motion Automatic Device Replacement (ADR features) – controlflash, firmware supervisor, plug and play device replacement are now support on PowerFlex 755 This screen snapshot shows integration of two PowerFlex 755 drives and a Kinetix drive…….configuration and commissioning PowerFlex 1 configured for Vhz mode of operation PowerFlex 2 and Kinetix configured for position mode operation

Programming Start PF 755 2 conveyor, ramp to speed
PowerFlex 755 1, 2 Kinetix Conveyor = PowerFlex 755 Vhz Feed 1 = PowerFlex 755 position Feed 2 = Kinetix 6500 position PowerFlex 755 1 configured for Vhz PowerFlex 755 2 configured for Position Kineitx 6500 PCAM Profile for PowerFlex 755 1 Start PF conveyor, ramp to speed PCAM’s for Kinetix 6500 and PowerFlex 755 1 This screen snapshot shows common programming using the motion instructions for PowerFlex 755 and Kinetix 6500 PCAM created using the graphical PCAM profile editor and run by a Kinetix 6500 drive and a PowerFlex 755 drive (configured for position mode operation) Both are cammed to a PowerFlex 755 running constant speed in Vhz mode

Broad Range of Motion Functions

Supported Robot Geometry Examples

Integrated Architecture Builder (IAB) - Tools

Motion Analyzer– Tools

Kinetix 5500 Servo Drive and VPL motor
VP Low Interia Servo Motor Kinetix 5500 Servo Drive Frame 165 Frame 130 Frame 115 Frame 100 Frame 1 Frame 2 Frame 3 Frame 75 Frame 63 Studio 5000 Software Single Cable Interface

Kinetix 5500 Servo Drive 50% smaller reduces cabinet & footprint cost
Supports 195 – 528 VAC input, reducing inventory Innovative Common AC/DC bus eliminates hardware, reduces installation time and lowers costs 24 VDC control power, reduces overall power consumption of the drive. Provides safer commissioning and troubleshooting Zero stacked drives, no backplane or power rail required reduces cabinet & footprint cost Clamp design enforces 360° bonding for noise immunity which eases installation Induction motor (V/Hz) support simplifies inventory and maintenance Single cable reduces installation errors

Integrated Motion on EtherNet/IP Encoder
EtherNet/IP Device Level Ring support 18 bit resolution Single-turn and multi-turn absolute 842EM-S 842EM-M IP67 Packaging, M12 connectors Solid and Hollow shaft options CIP Motion Feedback Only axis support Use as master axis for… Gear PCAM MDSC mode moves MAOC General logic Provides a master axis solution when using the Kinetix 350 drive or Kinetix 5500 drive

Distributed PLS and SOE
CIP Sync 1732E Slim ArmorBlock Digital Modules 1732E-IB8M8SOER 8 CIP Sync Sequence-of-Events input module Inputs are time-stamped 2048 buffer memories per block Max jitter of 25 microseconds 1732E-OB8M8SR 8 CIP Sync Scheduled Output sourcing module Outputs are updated at a specific schedule time High accuracy scheduling increments of 1 microseconds Ability to fire multiple outputs at high speed interval of 100 microseconds Support 16 schedules per coarse update period

Distributed PLS Control discrete outputs based on motion axis position & velocity MAOC motion instruction with Logix Designer graphical profile editor Multiple output module options Boolean outputs “Standard” output modules Output modules with CIP Sync technology 1756-OB16IS (8 point) 1756-OB16IEFS (16 point) 1732E-OB8M8SR (8 point) Compact Logix can now utilize the MAOC with the Armor Block module. MAOC – Motion Arm Output CAM - (High Performance Programmable Limit Switch) 1756-OB16IFS is a higher performance than OB16IS (<50us), * now have support for all 16 outputs with MAOC (could only use 8 of the 16 on the OB16IS.) The MAOC has been enhanced to include the Armor Block support and in addition to that the Point IO Scheduled Output module. Can now be used as a registration input for Axes (Located more closely to the process and can reside on-machine and not having to route registration wires back through to the Axis Module) We now have a PLS solution for Ly CompactLogix! SO, Whether it be 1756, Armor or Point I/O we are providing ultimate flexibility REGARDLESS of your IO platform. We realize the power of the MAOC and are aligning the HW to allow everyone to use it. BIG TAKE AWAYS: Same operation for 1756-OB16S as before (No Change here) 1756-OB16IFS can utilize ALL 16 outputs versus the 8 with the OB16S Compact Logix can fully utilize the MAOC now with the 1732 Armor Module.

Output CAM Definition Logix Designer Graphical editor and programmatic runtime configuration Actuator delay compensation Latch Unlatch Position, Position Position, Time Enable input

Distributed Position Registration
Determine “event position” of any axis using “time stamps” CIP Sync technology SSV/GSV instruction support for converting time stamp to axis position Multiple module options Drive registration inputs 1756-SOE 1732E-IB8M8SOER AOI for CIP Motion axes/IBM8M8SOER module Axis Input event type Windowed registration option Time stamp returned for cascading - one to many Compact Logix can now utilize the MAOC with the Armor Block module. MAOC – Motion Arm Output CAM - (High Performance Programmable Limit Switch) 1756-OB16IFS is a higher performance than OB16IS (<50us), * now have support for all 16 outputs with MAOC (could only use 8 of the 16 on the OB16IS.) The MAOC has been enhanced to include the Armor Block support and in addition to that the Point IO Scheduled Output module. Can now be used as a registration input for Axes (Located more closely to the process and can reside on-machine and not having to route registration wires back through to the Axis Module) We now have a PLS solution for Ly CompactLogix! SO, Whether it be 1756, Armor or Point I/O we are providing ultimate flexibility REGARDLESS of your IO platform. We realize the power of the MAOC and are aligning the HW to allow everyone to use it. BIG TAKE AWAYS: Same operation for 1756-OB16S as before (No Change here) 1756-OB16IFS can utilize ALL 16 outputs versus the 8 with the OB16S Compact Logix can fully utilize the MAOC now with the 1732 Armor Module.

EtherNet/IP Motion Product Overview Future Motion Functionality

Drive Multiplexing Support for three coarse update periods (CUP)
Available for Integrated Motion with EtherNet/IP drives and Virtual axes Synchronized Gear, PCAM, MDSC motion (interpolated axes must all be in the base rate) Optimize controller, network, and drive performance Use base rate for high performance drives and alternate rates for lower performance drives Example: L7x with 15 CIP Motion drives Estimated and actual utilization metrics Information on important system performance metrics – calculated and runtime actual Manage/predict system performance during design, programming, and commissioning Rate Selection Rate Selection Rate Selection Estimated and Actual Utilization Estimated and Actual Utilization

Compact Market The Next Generation of Compact Drives
Connected Components Offering Mid-Range Offering CIP Motion Offering Launch Scheduled AFC: March 1, 2013 Under Development AFC: Q3FY14 Under Development AFC: Sept 2013 Connected Components Workbench bundle Simple drive applications (Pumps, fans, conveyors) Globally competitive cost point Premier Integration to Logix EtherNet/IP solutions including optional dual port EtherNet/IP card Embedded hard wired safe torque off CIP Motion compact drive Embedded dual port Ethernet/IP CIP Safety (SIL3/Ple) PowerFlex 520 Series Next Generation Compact Drive PowerFlex 520 Series designed to move Rockwell Automation to #1 position in Compact Drives

PowerFlex 527 Multiple Voltage Classes Multiple Frame Sizes
110V, 200V, 400V, 600V Multiple Frame Sizes 0.2 to 22kW at 400V Multiple package options IP20, IP31/NEMA 1, Full On-Machine Hardwired and CIP Safety STO Motor control support

CIP Safety Drives – EtherNet/IP
Kinetix 5500, PF527 (V22) PF755 (V23) EN safety functions (phased release) Stop functions STO (V22) SS1, SS2, SOS, SBC (V23) Limit functions SLS, SSM, SDI (V23) Programmable safety -> “Safety task”

CIP Safety Drive Instructions
Drive Safety AOI Library – safety functions Safety task execution using “safe feedback” data (centralized) Pass processed parameters to drive for local execution (decentralized) Library of safety Add-On Instructions (SAOI’s)

Drives CIP Safety Flexibility
SIL3, PLe CIP safety core Controller options ….. GuardLogix L7xS - PLe L36ERMS – Ple (Oct 2015) Drive Options PowerFlex 755 (Future) PowerFlex 527 Kinetix 5500 Architecture Common and separate standard/safety controller

Thank You

T23 – High Performance Motion Over EtherNet/IP

Similar presentations

Presentation on theme: "T23 – High Performance Motion Over EtherNet/IP"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

T23 – High Performance Motion Over EtherNet/IP

Similar presentations

Presentation on theme: "T23 – High Performance Motion Over EtherNet/IP"— Presentation transcript:

Similar presentations

About project

Feedback