CANopen communication protocol - an introduction

CAN (Controller Area Network) is a real-time communications protocol that is now well proven in the automobile industry. Its low costs and robust physical layer also make the protocol attractive for industrial networks. The CANopen higher-layer protocol, which is based on CAN, was developed specifically for embedded machine control purposes. Standardised in Europe as EN 50325-4, Industrial communication subsystem based on ISO 11898 (CAN) for controller-device interfaces. CANopen, it has been hugely successful worldwide and provides system integrators and buyers with a high degree of plug-and-play capability for devices within the network.

While CANopen allows devices in the network to communicate, an even higher degree of standardisation is necessary for specific applications - for example, weaving machines or extruders. This higher degree of standardisation is defined in CANopen device and application profiles. The CAN in Automation (CiA) international users' and manufacturers' group, and its more than 500 member companies, institutes and universities, have been developing such device and application profiles for a substantial number of applications already. These profiles simplify the life of all those participating in the business process: device manufacturers, system integrators, and end users/buyers of complete systems.

CANopen protocols and profiles

CANopen is a standardised higher-layer protocol (EN 50325-4) that is based upon CAN, a protocol that was developed in the early 1980s for automotive applications. It is a highly flexible communication protocol and provides a very robust physical layer, with high EMC resistance. Due to the high volume of CAN micro-controllers used and sold to the automotive industry, the chips are available at a low price. These facts make the protocol very attractive to applications outside the automotive industry.

Since CAN comprises just layer 1 (physical) and layer 2 (data link) of the OSI reference model, a higher-layer protocol is necessary to actually make devices communicate within a network. Early in the 1990s, the CANopen protocol was developed for embedded machine control applications and for networking several machine modules, which has become a significant trend lately. This protocol covers the OSI layers up to 7 (application); it enables highly flexible configuration and has therefore been used in many different application areas even outside machine building. Besides machine control systems, CANopen networks can now be found in medical devices, railways, building automation and elsewhere. It is also used in wheeled machines, such as paving machines, truck-mounted cranes and excavators.

CANopen provides standardised communication objects for sending process data, the process data objects (PDO) and, for sending configuration data, the service data objects (SDO). The Sync object enables synchronised communication between several devices, such as in motion control applications. Further communication objects, such as the time stamp, the emergency object and the error control message, make CANopen very flexible and adaptable to the required configuration of an application. The higher-layer protocol also enables network management, meaning networked devices can be put into specific states to better supervise them.

Plug-and-play

While CANopen lays the foundation for all communication between the devices in a network, further agreements for communication between them is necessary to make them plug-and-play. Plug-and-play, however, is what system integrators and end users want: rather than configure each device anew, they would like to be able to hot-swap devices from and into an existing network. For this, they require device and application profiles, ie agreements on the data to be exchanged between the devices, depending on the application.

The further communication standardisation is taken, the less system integration is necessary. CANopen-based device profiles specify exactly which communication and application objects have to be or may be supported by the device. They also specify which process data is mapped into real-time messages. The profiles also define which way a device will react by default to a specific message. If this default behaviour is not wanted, device manufacturers may still add other behaviours by means of configuration.

Besides a number of generic CANopen device profiles (eg for I/O modules, electric and hydraulic drives, sensors and encoders), CiA has released specific CANopen application profiles for machine modules. This includes feeders for weaving machines, collimators for medical imaging machines and extruder downstream devices such as pullers and saws. Standardised communication interfaces are especially important in markets in which several companies manufacture machine modules.

CiA and the Euromap organisation have developed a CANopen application profile for extruder downstream devices, which is available for free from both groups' websites. Since extruders are not always installed and retrofitted by highly qualified staff, the system integration must be automated to the utmost degree. The family of profiles (several device profile make one application profile) includes specifications for corrugators, saws, pullers, calibration desks and co-extruders. These downstream devices communicate with the main extruder, which also controls the CANopen network management. Despite the plug-and-play functionality of the devices, end users may still configure additional functions such as set temperature, pressure and height limits. The device manufacturer may also offer specific functions to differentiate its machine from that of others. This, of course, makes the unit lose its plug-and-play functionality. The beauty of the plug-and-play functionality is that a system integrator may just plug the devices together. The CiA 444 CANopen device profile for crane spreaders is an interesting example of how interoperability between products from different manufacturers is possible.

CANopen device profiles are not just applicable for CANopen networks but may also be mapped to other communication systems. The user groups for Ethercat, Ethernet Powerlink, Safetynet, and Varan have officially adapted the CANopen profiles for their respective real-time Ethernet variant. Also some ModbusTCP devices use the CANopen profiles already; however, the mapping of parameters and process data to the 16-bit Modbus registers is not standardised.

CiA is still developing further profiles for other industrial applications such as construction machines, woodworking machines (see photo), print machines, packaging machines and many others. The next profiles to be finished include device profiles for power supplies, pumps and low-voltage switchgear devices. The CiA 402 device profile for frequency inverters, servo controllers and stepper motors has been already standardized in the IEC 61800-7 series.

Reducing cost and development time

So many profiles already exist that you might wonder why there is a need to develop even more. The common fear is that standardisation takes away from competition and makes all devices the same. Far from it! The communication between devices is a pre-competitive part of a machine development, which costs individual manufacturers months and months to develop and uses up a large amount of manpower.

Machine module manufacturers reduce their development costs by using the CANopen profiles. Since the modules will all be using the same communication technology, they need to keep track of one technology rather than several ones that may not be interchangeable. New markets will open up - especially international markets - as well as the 'vertical markets,' which use devices and machines that were originally developed for other purposes. A secondary benefit of this will be the larger number of units to be manufactured. This, again, provides space for mass purchase of parts and/or savings or higher profit margins per module manufactured.

Machine system integrators also benefit by repetitive processes: all CANopen object dictionary entries will remain the same for them, too. So, rather than read through many different textbooks to look up details of the communication, they can concentrate on the system itself and improve set-ups and other performance parameters. The number of cumbersome references is reduced and their work will be easier and quicker. Values, such as temperatures or lengths, are always referenced at the same location, and units, such as degrees C or mm, are always used in fixed ways. No second-guessing or searching is necessary.

Of course, this is also true for retrofitting a machine with additional or new modules: the CANopen communication remains the same, whatever device is added. A very important benefit of standardised CANopen communication is the large number of sophisticated software and tools. The market is brimming with low-cost but powerful tools that enable manufacturers as well as system integrators to do their job more easily and successfully. This cannot be said for proprietary communication or even some of the other standardised networks. Since CANopen is not the property of any single company, there is lot of variety. Competition between software houses is high and the quality good. Manufacturers profit from this.

Last but not least are the savings to be gained from unified test runs and quality checks. Units must be checked before they are sold but checking the communication part will take next to no time if all units' communication is the same. If a module has been approved, all others implementing the same communication will automatically be approved also.

So far we have talked about manufacturers and system integrators, but end users also benefit from using CANopen device and application profiles. Purchasers of machine modules will not be tied to any single manufacturer, who may or may not provide all they need. Mid-sized to small companies will especially appreciate being able to buy modules from different manufacturers. There are usually a number of competitors. Now they will compete will machine functionalities rather than force the purchaser into making 'one size fits all' choice. Their modules will be interchangeable by communication, if not by functionality. Purchasers may therefore pick what is best for their requirements, swap devices between CANopen networks and also retrofit machines with additional modules.

The CANopen conformance test

CiA offers vendor-independent device certification for CANopen devices. This certification may be requested by manufacturers, integrators or by end users. The CANopen device certification is a certification of communication quality. Purchasers may want to pay attention to this certification, since every device that carries it will assuredly works within the CANopen network. The certification proves that a device has implemented the CANopen protocol completely and correctly. All certified devices communicate as required in the network.

Several CANopen specifications and recommendations are downloadable from CiA's website (www.can-cia.org), where more technical detailed descriptions of the CANopen protocols and profiles are available.

An interesting application for CANopen describing its use in a specialist carbon-fibre winding machine can be read at www.machinebuilding.net/ap/a0421.htm.