While there are many positive reasons for selecting digital communication buses for various tasks in a motion control system, there are also potential problems if the different types of buses are not fully understood.

One common mistake is the improper selection of the bus type for its intended mission. The confusion is compounded by the fact that more than one bus type could be used in a given application to serve different needs. A high-level bus could be used to connect the machine controller to the facility enterprise system while a device level network could connect the I/O to the machine controller, and the motion controller (itself an I/O point for the machine controller) could connect its axes via a motion bus. The requirements at each level are different, so it is likely that no one bus type can serve all the missions effectively.

Because connectivity at the highest levels occurs at the machine controller or cell level, motion control systems are not normally tied directly to the high level bus. The motion control system designer often is not involved in selection of the highlevel bus, but an awareness of it is important to avoid confusion when topics such as Ethernet are discussed. Because the typical protocol used to connect to the enterprise system is not the same as the protocol used to connect the I/O, confusion can arise if those responsible for the facility side connection believe that the I/O devices will be connecting directly to the enterprise network rather than to the machine or motion controller.

The ins and outs

There are certain things a designer needs to look for when choosing an I/O bus or working with one that has previously been selected. For example, the I/O may be connected to the machine controller, or the motion controller, or both, or the choice may be dictated by the user’s standard or by what is supported by the devices to be implemented. Either way, certain questions should be asked:

• Will the I/O need to operate in master-slave mode or peer-to-peer?
• If a master-slave, which devices will be masters and which will be slaves?
• Are you expecting any devices to function as both master and slave? For example, will the motion controller connect to the machine controller as a slave and then act as a master for dedicated I/O?
• What device level networks do the devices you intend to use support?
• Are the capabilities you need available from the device network you intend to use?
• Are you expecting to use devices from more than one manufacturer?
• Are you expecting to be able to interchange different manufacturer’s devices?

The capabilities of the leading I/O buses are generally more than adequate to meet most system needs. The main issue will be whether the individual manufacturer’s devices can provide all of the capability your system needs. Manufacturers are responsible for meeting specific requirements to claim their product supports a given bus structure; however, some extend product capabilities beyond this minimum. Be sure that the devices not only meet your system needs, but can also exchange the information required. As an example, if a slave device offers a specific functionality needed, but this function is an extended capability offered by a specific manufacturer, be certain that the master can support it. If you are using a product with extended capabilities, you may not be able to obtain those characteristics from another manufacturer’s equivalent product.

If you are working with a pre-selected I/O bus, you are forced to select motion and I/O products that support the bus. Because this limits your choices, it may be more difficult to achieve your design goal as not all I/O buses can support all types of functionality or have all device types available. It may be necessary, therefore, to connect some I/O devices to other system devices if those devices are not available in the pre-selected I/O bus. In this case, a conventional I/O device might be connected directly to the motion controller or machine controller’s built-in digital I/O connections rather than via the I/O bus. This would provide the functionality albeit with some loss of diagnostic capability.

Which motion bus is best?

One of the key areas that those new to the process struggle with is confusing other types of communication buses with motion control buses. Higher level and I/O buses are not appropriate for the task of motion control, instead motion control- specific buses are used. While all of the motion control bus solutions discussed below are capable of providing the performance required by most motion control systems, there are decided advantages and disadvantages that need to be understood.

Continue on page 2

SERCOS interface

Serial Realtime Communications System (SERCOS) was borne in 1988 by a multi-vendor consortium and in 1995 it became an IEC standard (IEC 61491). The open, standardized communication interface for motion control systems is internationally recognized.

A large number of manufacturers (more than 75 globally) along with trade organizations in North America, Europe, and Japan support SERCOS. Interoperability between various vendors’ products is possible.

The interface defines not only the physical layer but all the layers necessary for a complete motion control solution. The SERCOS interface is designed specifically to provide the high level of determinism required for synchronizing multi-axis systems. It does not rely on shear speed to attempt to ensure determinism.

Fiber optics are the communication medium between the controller and drives, which further enhances electrical noise immunity, isolation, and troubleshooting/maintenance capability. The interface has minimum overhead allowing maximum throughput, and a SERCOS-based system can achieve high throughput levels at much lower speeds than comparable systems.

The most often cited disadvantage of the SERCOS system is speed. The interface may appear to be slower because the data transmission rate numbers are much less than some competing buses. In reality, this is not particularly meaningful because the design of the SERCOS interface does not require the high data transmission speeds that competing architectures need.

Many leading motion control and general automation manufacturers support the SERCOS interface. For those users who decide to standardize on key hardware and systems from a manufacturer that does not support SERCOS, it may not make sense to attempt to introduce it into their environment.

• MACRO

Motion and Control Ring Optical (MACRO) was developed by Delta Tau and is also offered by several other vendors. Extremely high data transmission rates are supported, allowing the closure of servo loops across the MACRO ring. This permits the user to choose distributed intelligence (as SERCOS does, where some control resides in the motion controller and some in the drives) or centralized control (where all control is handled by the motion controller). MACRO is typically done with fiber optic cables and achieves the same benefits as seen in SERCOS systems and is reputed for delivering solid performance in complex systems.

Though MACRO is offered as a nonproprietary system, acceptance by manufacturers other than Delta Tau has been limited, reducing the number of choices for hardware and support.

• Firewire-based systems

Much like Ethernet, Firewire, a standard (IEEE 1394) high-speed protocol, was developed for more general use. Proponents point to the sheer volume of the consumer products market (in which Firewire was born) and the possibility of vastly lower product costs and wider support.

Potential aside, Firewire is not a motion control bus, rather, it is a physical layer definition. To create a motion bus, vendors must add a protocol, message content, data format, and programming. Several vendors have done so including Ormec (SERVOWIRE), Nyquist, and Adept. These systems are not presently compatible with each other.

Nonetheless, the physical layer is a rapidly growing standard, which makes for a good starting point in the development of a motion control bus. Bandwidth is guaranteed and deterministic, as well as supporting extensive high data transmission rates, often required for real-time control. Other benefits include the support of hot-pluggable devices and peerto- peer communications.

The main knock against Firewire is that the additional components beyond the physical layer are currently unique to each manufacturer, rendering every solution proprietary. In addition, these systems are relatively new, so the installed base is even more limited than that of SERCOS or MACRO. Athough the currently available systems appear to work well and are supported by reputable manufacturers, users need to carefully evaluate whether the particular implementation has required functionality for their motion control needs.

• Proprietary systems

It is necessary to mention proprietary systems because several of the leading automation equipment manufacturers offer these. Proprietary systems are designed to do what the manufacturer defines or agrees to provide. They are generally limited to equipment supplied by that manufacturer. There’s just one manufacturer to deal with on all aspects of the system, so compatibility issues rarely come up. However, hardware or support cannot be purchased from anyone but the manufacturer, which locks the designer into that vendor’s solution and pricing structure.

Continue on page 3

Ethernet

Presently, there are no motion bus solutions available that use Ethernet as the physical layer medium. Products offered as supporting Ethernet do so for connecting the motion controller to other portions of the system such as the machine controller or the I/O. This is a good solution for general interconnectivity but is not the same as controlling the drive axes.

As with Firewire, should Ethernet prove a viable solution for the physical layer portion of the motion control bus, it will need the other required components, including protocol, message content, data format, and programming, added.

At present there are significant questions as to whether Ethernet can provide the necessary determinism for a motion control bus. It may be possible to overcome some of the current Ethernet limitations via higher data transmission rates, but this remains to be seen. In one lab test an Ethernet system needed to operate at 100 Mbit/sec to achieve the same throughput as a SERCOS system operating at 16 Mbit/sec.

The motion system designer needs to consider that suppliers are looking to offer differentiable solutions to the market. Promotional claims need to be carefully scrutinized. The broadly supported, wellestablished solutions can lay claim to proven successes in a variety of applications, while newer solutions need close evaluation.

The big picture

Ultimately, control system performance is a function of the entire system, including the choice of motors, controller programming capability/language, and drive capabilities. Getting the right communication bus is but one part of the total solution.

The strength of the chosen supplier in terms of total product offering and support capability also needs to be considered. Some suppliers may be able to offer more than one communication bus solution at the I/O and motion control levels affording the user the best solution on a by-application basis.

Finally, there is a tendency to want communication bus solutions to be “plug and play.” This is the idea that the best product in each category can be selected, connected together, and then work as expected. To a point this is true, but because individual manufacturers extend their product capabilities beyond the basic requirements of the communication bus standards, this arrangement may be less than perfect.

Choosing products from a single supplier minimizes this risk and makes interoperability issues easier to correct. It does so, however, at the expense of flexibility and selecting “best in class” products. Conversely, selecting products from different manufacturers maximizes choice and optimizes the individual components, but requires more careful evaluation of the products and suppliers.

Mapping the bus system

The first step in choosing a bus or buses is to decide at which levels we need to communicate. This quick overview shows that it is possible that a given motion control system could employ three types of buses in the same system.

High level bus or information network

To connect the machine or cell controller to the enterprise system or to interconnect related machines or cells, engineers call on high level, or information, networks. These buses may use a protocol layered onto Ethernet, may be proprietary or may be an industrial control level bus such as ControlNet, ModBus Plus, or Data Highway Plus. They can configure the machine/cell control for specific processes, pass information between related machines/cells, and retrieve status information. They must move large amounts of information but operate at comparatively lower speeds than device level or motion buses.

I/O or device-level communication bus

To connect various types of I/O to other higher-level or lower-level devices (masterslave system) or allow peer-to-peer communication between I/O devices. DeviceNet, Profibus DP, Interbus-S, and CanOpen are examples. Device-level networks move much smaller amounts of information, but do it quickly, typically within 10 to 20 msec.

Motion bus

To connect the motion controller to its drive axes, motion buses support position, velocity, current, and torque commands as well as drive parameter information and detailed diagnostic messages. Examples include SERCOS, MACRO and SERVOWIRE, while many proprietary motion buses also exist. Motion buses must move their information at very fast speeds depending on the particular architecture. They are designed specifically for the task of motion control in multi-axis systems.

Continue on page 4

Mistaken identity

The connectivity components RS-232, RS-485, USB, Ethernet, and Firewire are often mistakenly interpreted to be communications buses. While these can be part of a communication bus, they do not by themselves constitute a complete solution. For example, SERVOWIRE uses the Firewire physical layer but must add a protocol and other components to provide its motion bus capability. Likewise, Ethernet-based I/O solutions are becoming very popular, but Ethernet requires the addition of a protocol to provide communication between the host and the distributed device.

Digital domain

Digital communication buses offer many advantages, such as reduced wiring costs, less need for panel and cable tray space, and a lower incidence of wiring errors. They are generally less susceptible to electrical noise and grounding problems because of the nature of digital signals, the construction of the cables, and the fact that fewer cables need to be run together to carry the same or greater volume of information. Also, digital-toanalog and analog-to-digital conversions are eliminated. Systems are able to respond faster, and errors are minimized or eliminated. Detailed diagnostics messages are possible and can be remotely accessed. As a result of all the previous points, system support is easier, better, and faster.

A system employing one or more digital communication buses typically has a lower installed cost and is simpler to set up, maintain, and service. Detailed diagnostics and a lower probability of having to chase down elusive electrical noise, grounding, and cabling problems simplify supplier support.

Given all the potential benefits of using digital communication buses, it seems to make sense to use them in every application. However, for all their advantages, digital communications buses are not for every situation. Simple systems such as indexing drives and single-axis positioning systems that operate from stored programs often are better off with a standard ±10-V interface. So are small systems where the initial equipment costs (typically higher for the digital system) outweigh the installed cost reductions and longerterm maintenance/service/support benefits.

In other cases, the user just may not be ready. This often overlooked point can create real problems. If a potential user has no interest in learning new concepts, does not plan to train support personnel, or simply expresses the desire to stay with what they know, it may be wiser to do exactly that.

Chris Radley is senior product line manager for electronics and software at Kollmorgen, Danaher Motion, Radford, Va.