01 February 2005

Cars and robots are one

Develop motion control solutions over standard networks such as Ethernet

By Kendal Harris, Sivaram Balasubramanian, and Anatoly Moldovansky

Current distributed motion-control systems rely on proprietary implementations to time synchronize distributed motion components.

With the advent of the Institute of Electrical & Electronics Engineers (IEEE) 1588, it is possible to develop motion control solutions over standard networks such as Ethernet using commercially available technology.

Here is the basic operation of 1588 and motion in a working prototype.

Off the shelf components

With the introduction of the IEEE standard 1588, it is now possible, using commercially available technology, to develop distributed motion control applications requiring tight synchronization between nodes in the system.

Typically, this requires the jitter between the clocks in the system to be a few microseconds. Higher performance applications are increasingly driving this requirement to the sub-microsecond range.

Current solutions achieve tight synchronization between the nodes in a distributed system using proprietary networks and interface components.

Custom application-specific integrated circuits (ASICs) in the interface cards control the distribution and synchronization of clocks throughout the system as well as timely delivery of control data.

The IEEE 1588 Precision Time Protocol provides a standard mechanism to synchronize the clocks across a distributed network. By using the 1588 protocol over a standard network, a standard solution can replace a proprietary solution. Off-the-shelf components can then replace the custom network interface components.

Prototype description

The prototype motion system consists of three motion controllers. Each controller connects to one drive over a serial real-time communication system (SERCOS) through a SERCOS Adapter card. SERCOS is an industry standard for connecting digital drives. All the motion nodes connect via standard Ethernet through an Ethernet adapter card.

A "motion planner" in the controller manages the position information for each drive to control motion jogging, moving, and gearing operations. Each drive corresponds to one axis of motion. One drive is the master axis, and two of the drives are each slave axes. Each slave axis gears to the master axis in a one-to-one ratio. The controller connected to the master axis on a periodic basis sends position references to each of the controllers connected to the slave axes.

The clocks on all nodes in the system are in lock step. This clock synchronization over Ethernet uses the IEEE 1588 protocol. Clock synchronization over the backplane uses a proprietary protocol that was in place prior to 1588. For both the Ethernet subnet and the backplane, one node is the subnet time master, and all other nodes are time slaves.

cars1

System clock harmonization

Ethernet clock synchronization happens on the Ethernet adapter card. The card contains a field programmable gate-array (FPGA) hardware assist circuit to timestamp incoming and outgoing 1588 protocol messages. The FPGA contains a 64-bit, 25 nanosecond per tick, high resolution, tunable clock.

The 1588 protocol runs on a 50 MHz PowerPC CPU. The 1588 code interacts with the FPGA as specified by the 1588 protocol to synchronize a time slave clock to its associated master clock on the subnet. A tuning algorithm adjusts the frequency of the FPGA tunable clock once each 1588 sync update cycle.

The adapter also contains an interface chip to the backplane. The clock in the backplane chip synchronizes to the 1588 clock. On the adapter, the backplane interface serves as the master clock. All other clocks on the backplane synchronize to the master clock on the adapter. A simple algorithm synchronizes the backplane clock to the 1588 clock. The adapter represents a 1588 boundary clock node with the backplane clock classified as a foreign clock.

Position update cycle

The basic motion operation requires the motion tasks running in each node to synchronize to each other. Transactions between nodes platform on a synchronized periodic update cycle. This applies to both controller-to-drive transactions and controller-to-controller transactions.

For controller-to-drive transactions, at the beginning of the cycle, the controller sends interpolated position updates to each of the drives. The drives use the position updates to control the closed loop position and velocity of the motor. Each drive returns its actual position to the controller. The controller computes a new position and the cycle repeats. This constitutes a position update cycle.

For controller-to-controller transactions, at the beginning of the cycle, the controller of the master axis sends a position reference to each of the controllers of the slave axes. The controllers of each of the slave axes use this position reference to "plan" the motion for the slave axis.

To synchronize all motion in the system, the motion tasks and consequently the position update cycles synchronize with the 1588 clock. A small circuit in the FPGA provides a periodic interrupt to the CPU to trigger the position update cycle. The circuit compares a time, which has been loaded into a target register with the current 1588 clock time. When the current time matches the target time, an interrupt generates. In the interrupt-service routine, the CPU then loads a new target time equal to the current target time plus the cycle period and the process repeats. The phase and period of the cycle are setup during the node configuration process.

1588 monitors the integrity

The 1588 protocol is a C/C++ implementation running on the adapter. Most of the 1588 protocol includes Sync, Follow-up, Delay Request, Delay Response, and Management messages.

The time slaves use the 1588-burst protocol to speed clock synchronization during startup. The process involves a burst of eight Sync messages to realize implementation.

The best master algorithm does not go into service. Instead, the system uses the preferred master selection to determine the time master for the subnet. On startup, the slave clocks listen indefinitely for a master clock. The slaves never assume mastership. There is no provision for more than one preferred master.

There exists some support to monitor the integrity of the time master clock. If a slave clock detects the loss of a master clock, it stops its backplane clock. This causes the SERCOS adapter to shutdown the SERCOS ring and all motion stops.

In the prototype application, there is a need to precisely turn an output on and off based on the position of the master axis. This output triggers a strobe light to illuminate the phase position of all three axes. To achieve a precise output strobe, a special output module is used whose clock synchronizes to the rest of the clocks in the system. An output value transmits to the module by the motion planner in the controller with a timestamp indicating the time at which the output should assert or de-assert. The output module manages the output schedule using the task synchronizing circuit previously described to achieve precise output timing.

Global positioning as master

The motion system prototype startup time defaults to a Greenwich Mean Time (UTC) time of zero. Absolute time is not generally needed for motion control, but it can be useful for time stamping significant events such as fault conditions. A global positioning system (GPS) interface provided an accurate source for UTC time and to serve as the grand master clock for the rest of the system. This interface played on the Ethernet adapter module. An algorithm on the adapter receives pulse-per-second, and UTC updates from the GPS receiver and adjusts its local clock to maintain synchronization.

This prototype application of 1588 with distributed motion over Ethernet proved to be reliable and accurate. The hardware assist circuit provides jitter accuracy under 200 nanoseconds between the master and slave clocks. When using GPS as the master reference, an accumulated jitter of 500 nanoseconds at the slave clocks results. The additional jitter results from not having a clean edge on the pulse-per-second signal coming from the GPS receiver.

The prototype represents a relatively small system. Additional prototyping and testing are required with a more extended system under various load conditions. This work resulted in development of the CIP Sync concept.

Behind the byline

Kendal Harris, Sivaram Balasubramanian, and Anatoly Moldovansky are project engineers and work for Rockwell Automation. This article emanates from their paper presented in November 2004 at the ODVA CIP Networks Conference.

Automotive industry leans on robotics

Manufacturers are in pursuit of automation solutions that increase productivity through higher line speeds while maintaining the agility necessary to handle a wide range of products.

IEEE 1588 enables such performance by providing precise synchronization among modular machine sections while reducing life cycle cost.

The IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems is a viable foundation for standardizing the way modular machinery connects.

Network services available with the IEEE 1588 standard will enable rapid integration of modular machinery that will operate in precise synchronization. Robotic production lines are excellent automation candidates for utilizing the capabilities of IEEE 1588 as they are widely used in continuous flow operations for discrete products and perform tasks while work in process are still in motion.

Many automated production and warehouse applications such as assembly, welding, printing, or material handling are traditionally implemented with centralized command and control centers, making them costly to integrate and difficult to support.

However, the market is shifting as end users are in pursuit of automation solutions that offer continuous flow operation for discrete products to increase productivity through higher line speeds, while maintaining the agility necessary to handle a wide range of products.

Machine builders are responding in parallel to these functional requirements with modular machine designs that allow end users to configure manufacturing systems based on functional subsystems.

Robots are excellent automation candidates when implementing continuous flow by performing a task while subassemblies or work in process are still in motion. By synchronizing the robotic motion with the conveyors within its operating zone, the overall productivity increases even more.

Algorithms to synchronize robotic operation in reference to a moving conveyor enable such operation, even if conveyor speed changes continuously. Eliminating start and stopping operation of conveyors increases the average line speed by making parts move continuously. IEEE 1588 could enable operation with ease and in an open environment.

Robotics are widely used in the automotive industry for automated assembly, welding, painting fabrication, and production lines. Consequently, automotive manufacturers are constantly searching for ways to increase production or transfer line speeds for faster return on assets.

Raising the speed notch by notch on every section or station of a production line, to the point beyond which production quality might suffer or until a process bottleneck occurs, is one way manufacturers achieve high line speed.

While this is a normal practice opted by manufacturers, it does not raise the line speed to its highest potential. In most of these production lines, the highest productivity comes about when each section synchronizes with the previous station or other devices in a manner that it eliminates dead time.

For example, coordination between the robot loaders/unloaders and presses can be made very efficient by controlling inter-device coordination, increasing throughput significantly. In many operations, robots need not wait for a part to come to a complete stop in its operating zone to perform task on it.

SOURCE: ARC Advisory Group (www.arcweb.com)