The typical relationships between the communications buses in an actual system are illustrated.
Select figure to enlarge.

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