CANopen for applications in machinery

Modular embedded control systems require communication links between the functional units. In the past, proprietary and not standardised serial links or networks have been used. Today embedded system designers like to use off-the-shelf functional units in order to reduce system costs. Several manufacturers produce those board-level products, smart sensors and actuators in high volumes. These off-the-shelf devices are increasingly incorporating CANopen interfaces. CANopen is a standardised network technology based on Controller Area Network (CAN), a serial bus system originally developed for in-vehicle networking of passenger cars.

The CANopen application layer is internationally standardised as EN 50325-4 but is better known as CiA 301. It was developed in the mid 1990s and has been used as an embedded network in machine control systems. In particular, European manufacturers of printing machines (eg Heidelberg), injection-moulding machines (eg Bossi Negri), wood processing machines (eg Homag) and many other types of special-purpose machine have been using CANopen networks for more than 10 years. In the first generation of CANopen-based embedded networks, no standardised profiles were used. Profiles specify the process data, configuration parameter and diagnostic information, as well as the assembling of the real-time messages - the Process Data Objects (PDO). The CAN in Automation (CiA) international users' and manufacturers' group, a non-profit association with more than 500 member companies, has specified several standardised profiles for very different application fields. CiA maintains and develops all CANopen specifications, some of which are freely downloadable from the CiA website.

Within a CANopen system the Network Management (NMT) master controls the CANopen state machines in all NMT slave devices. The highest prior message (NMT message) of the CAN data link layer does this. The confirmation send by the NMT slave devices is implemented as a low-prior Heartbeat message. The periodically transmitted Heartbeat message also has a second function: it indicates that the related device is still alive and active in the network even if it does not send any process data.

Service Data Object (SDO) peer-to-peer communications involve the SDO client and SDO server devices. The SDO client takes the communication initiative and reads or writes to the CANopen Object Dictionary of the SDO server. The object dictionary is a list of parameters addressable by means of a 16-bit index and an 8-bit sub-index. This overcomes the 11-bit limitation of the CAN-Identifier, which allows the unique identification of 2048 messages. Theoretically each device could be the SDO client of each other device and vice versa. In most master/salve-oriented applications, the application master is the SDO client for all other devices. CANopen allows for several application masters to coexist. The SDO transfer may be segmented; this means any size of data is down- or up-loadable. The server confirms every segment. A single SDO channel requires just two CAN message IDs; however, one or four bytes of the data field are required for the SDO protocol overhead.

Real-time communication

For real-time communication, CANopen provides the PDOs, which are unconfirmed single messages with up to eight bytes of process data. The scheduling of PDOs and prioritising, as well as the mapping of process data, is all configurable. This gives the system designer a very high degree of flexibility to optimise the real-time behaviour. On the other hand, this also entails additional work for system designer. One of the unique features of CANopen is the synchronous transmission and reception of PDOs triggered by means of the Sync message.

The benefit of a standardised application layer is that several software vendors offer off-the-shelf CANopen protocol stacks in source or binary code. There are also some CANopen open-source projects offering free protocol downloads. In addition, several toolmakers provide CANopen tools for the entire device and system development process, including diagnostic tools.

Device, interface, and application profiles

The second generation of CANopen networks uses standardised device profiles. CiA has released generic profiles for I/O modules (CiA 401), electrical drives (CiA 402 published as IEC 61800-7-201/301), transducers (CiA 404), encoders (CiA 406), and hydraulic valves and drives. In addition, there are standardised profiles for dedicated applications - for example, a collimator for medical devices (CiA 412-2), feeder for weaving machines (CiA 414-2) and downstream devices for extruders (CiA 420 series). CiA has also released some interface profiles, including an ASI-to-CANopen gateway (CiA 445) and a CANopen-to-truck gateway (CiA 413 series). Such standardised device and interface profiles simplify system integration and shorten system development times.

Application profiles specify not just one device interface, but all interfaces in the system. Therefore application profiles are application-specific. CiA has released CANopen application profiles for lift control (CiA 417), rail vehicles (CiA 421), photovoltaic systems (CiA 437) and others. If required, application profiles define PDO cross-communication between devices. The application profile approach is regarded as the third generation of CANopen networks.

In summary, therefore, CANopen is a set of communication specifications for embedded control systems. System designers should consider some limitations: speed versus network length (1Mbit/s @ 25m to 50kbit/s @ 1km); one CANopen segment can contain 127 devices, and 512 PDOs can be transmitted and 512 PDOs received per device. CANopen is used in a very broad range of applications: in addition to machine control, this network technology is applied in medical devices, laboratory automation, off-highway vehicles, building automation, wind power systems and embedded door controls. CiA has developed more than 50 standardised profiles, which is highly advantageous for system designers. They can choose CANopen hardware, software and tools from more than 800 suppliers. Some of them are listed in the CANopen product guide available on CiA's website. In India, the use of CANopen is not as widespread as in Europe and North America. However, the CDAC institute in Trivandrum has developed a three-wheeler with an in-vehicle network based on CANopen. And there are more CANopen applications in India (eg GE Healthcare in Bangalore develops medical device with embedded CANopen networks).