Distributed Control

Networking robotic systems and workcells

—By Jan Bosteels, Product Manager, Advanced Motion Controls

There exists today a broad choice of networking solutions for robotic systems and workcell distributed control architectures. Some were developed specifically for industrial communication systems (Profibus, SDS, InterBus, Sercos, DeviceNet…), some migrated from office networking solutions (Ethernet), others are the result of new PC architecture developments (IEEE1394, USB). One would assume that such a vast choice would have made selecting the most suitable communication network for distributed control architectures easier — unfortunately, the opposite is true. To make a proper selection, it is important to revisit the reasons for migrating from a centralized control system to a distributed control system.

Wiring. In a centralized control system, all the machine control logic and algorithms are executed in a central controller. Hence, all measurement and actuation devices must be connected directly to this central controller. A distributed control system “distributes” machine intelligence across the machine. Therefore, measurement and actuation devices can be connected to a local controller, which in turn is connected to other controllers via a communication link. This approach reduces overall wiring cost and complexity, with increased reliability.

Flexibility. Adding I/O, sensors and other devices to a centralized control system can be difficult or impossible, because the system integrator may have to change the complete control platform to accommodate changes. A distributed control system is more scalable in that additional devices can be added to the network directly — in worse case, only the local controller would need to be replaced to allow for more connections, resulting in a more modular system.

Diagnostics. many industrial devices are changing from analog to digital. Such devices provide more detailed information about their internal status. Unlike a centralized controller, which would require additional wiring, a distributed control system can take better advantage of this additional information due to the existence of the communication interface, thus providing improved diagnostics (locally or remotely). Such extensive diagnostics can support preventive maintenance or help troubleshoot problems more efficiently.

So, why was a transition from centralized to distributed control principles not made earlier if the advantages are so clear? The computing industry made the transition from mainframes with passive terminals to networked personal computers long ago. Firstly, not all machines will benefit from such a transition to the same degree. A geometrically compact machine with simple, well-defined functions is probably best implemented with centralized control principles (e.g. a PLC with discrete wiring to sensors and actuators via simple analog and digital ON/OFF signal lines). Also, up until recently, distributed control architectures have been cost-prohibitive. Distributing intelligence across multiple devices led to duplicating expensive hardware architectures, hence driving up cost. This last hurdle has been partially removed by progress made in digital control logic, effectively and economically distributing the machine intelligence. With the vast choice of cost-effective micro-controller and DSP technology that exists today, it is now possible to have overall machine cost at or below the cost of an equivalent machine using centralized control. In addition, networking and communications technology has made some significant leaps in terms of cost and reliability. These two factors make distributed control systems a practical reality with the above-mentioned benefits.

Selecting a network

Selection of a communication network that will form the backbone of a distributed control system should be based on the following criteria:

Bandwidth. Bandwidth requirements should be based on the real-time needs of the system (not as “as fast as possible,” but “on-time”). It is important to note that as more functionality is added to a local controller, the bandwidth requirements of the communication network will be lowered. Bandwidth should be based on effective data rates, not bit rates! An important design rule for distributed systems using serial communication: communicate as little as possible.

Integration Requirements. The transition from a centralized control system to decentralized can require a complete overhaul of machine control software. The selected network should have as many support tools as possible (hardware and software). A communication network is more than just a physical layer connection. Ideally, it should be an existing and completely defined standard. It is recommended to stay clear of network solutions with high degrees of proprietary, manufacturer-specific functionalities and definitions.

Availability. Certain communication interfaces are more popular than others with device manufacturers. When standardizing on a single network solution, it is advantageous to select one for which many different devices from many different manufacturers exist. Otherwise, the integrator must select various kinds of networks depending on the type of device, increasing cost and complexity, and defying the purpose for migrating to a distributed control solution.

CAN

A somewhat less-known communication solution exists that addresses the above criteria in most applications: CANopen. While a single network solution does not solve all possible applications, CANopen is one of the only solutions that has attracted a large following from various manufacturers, supports many different devices, is a true open standard, and is very cost-effective. It has an added advantage in that the automotive industry utilizes CAN technology extensively, improving cost and availability.

CANopen is an open standard, industrial networking protocol designed for the CAN bus. Originally developed for the automotive industry by Bosch, it has gained ISO standard status. The CANopen protocol is designed and developed by CAN in Automation, a non-for-profit organization in Europe. In addition to defining the communication protocol (i.e. the message format on the bus), CANopen also establishes so-called “device profiles” for various industrial devices that can be connected to a CAN bus (e.g. sensors, controllers, motor drives, PLC, etc.). These device profiles pre-define certain parameters and functionality in order to improve system integration and standardization.

One of the device profiles defined by CANopen is the Profile For Drives And Motion Control (DSP-402). This profile includes objects that define and configure torque, velocity, and position control of electrical motors. There also exist profiles for I/O modules, HMI’s, sensors, controllers and other devices.

In the field

Here are two applications solved using CANopen architecture:

• Medical equipment using multiple servo drives and I/O modules, connected to a single CANopen network. An embedded host controller, considered the CANopen network master, communicates with each device in an interrupt-driven fashion (so-called PDO messages in CANopen). Multi-axis coordinated position control is achieved through position-time data streaming from the host (which calculates the overall trajectories based on inverse-kinematics) to the servo drives (which close the position loop and perform dynamic interpolation between consecutive position data points). Overall time synchronization is achieved via the CANopen Time Stamp command, a broadcast message containing absolute time of the host controller. Up to 9 axes are coordinated on a single CANopen network running at 500 Kbits/s, with communication busload at a mere 20%. I/O and servo drive expansion are simply achieved by adding extra devices to the CANopen network (which can host up to 127 nodes per network).
• Semiconductor wafer processing machines contain many axes (in the order of 40 servo drives per machine) and hundreds of I/O points. Most servo drives require simple point-to-point moves. The CANopen host controller sends position, velocity and acceleration information to a servo drive node, and commands a move. An in-position message is sent from the drive to the CANopen host after move completion. CANopen busload is kept to a minimum since I/O devices and servo nodes only communicate when there is a change, making the system completely interrupt-driven. Implementation of multiple CANopen networks on a single machine is simple and cost-effective. An industrial PC with PC-to-CAN interface cards may serve as the CANopen host. PC operation systems with real-time capability allow implementation of true “soft-motion” concepts, by eliminating the need for dedicated motion control hardware on the host.

[Editor’s Note: The above applications are using Advanced Motion Controls’ DigiFlex CANopen servo drives, which are fully digital servo drives with CANopen connectivity. These drives are available with voltage supply from 80 VDC to 460 VAC, and output current capability from 15A to 100A peak. They can operate with any brushed or brushless, rotary or linear, servomotor, equipped with encoder-, Hall-, or resolver-feedback.]