Get to know CANopen, a CAN-based communication protocol for use in automation technology and standard device control.
This is a series of articles about the technology behind CANopen. At the end of each post, there is a button to the next article, or you can choose a specific topic from the menu at the bottom on the left.
Click right at the very top for an overview of all the know-how articles.
CAN, but suitable for industrial applications?
CAN was developed for the automotive industry. Car manufacturers are, by definition, the system owners of a car and the technology used in it. This is entirely due to the enormous production volumes involved. A platform – the basis of a car – can easily encompass more than a million cars over the course of its production cycle. Optimising costs and ensuring the reliability of systems tailored to that platform is therefore crucial.
This was also the starting point during the development of CAN. The specific definition of CAN IDs and data bytes was unrestricted and left entirely to the car manufacturers. Each manufacturer, or group, developed its own communication model in which CAN IDs and data are assigned.
However, this freedom is actually a disadvantage in industrial applications. Although the CAN bus, and also the physical layer, are standardised, you cannot simply connect CAN nodes from different suppliers to build a system. Those nodes would simply not understand each other’s messages.
That is why, in the late 1980s, the industry and a number of research institutes began their own development programme. It was known as CAL, the CAN Application Layer – in other words, a layer on top of CAN. Philips Medical Systems and a number of German universities, amongst others, were the driving forces behind this. Together with the newly founded CiA – CAN in Automation – the first version of CANopen was presented in 1994. In 1999, CANopen was officially standardised worldwide as EN 50325-4.
Embedded Industrial Protocol
Nevertheless, CANopen’s role as a communication protocol in general machine control has remained limited. Comparable networks such as Profibus – with Siemens as the driving force – or Modbus – with Schneider as a key manufacturer – have gained a much larger share of the market in mechanical engineering. However, suppliers such as Beckhoff or Lenze have also contributed to CANopen’s success. General-purpose machine control is often based on PLCs and features a modular structure of components in a DIN-rail environment.
CANopen has become particularly popular as an embedded industrial protocol, whilst such control cabinets are not actually used in this context. It is ideally suited to machines and systems where the aim is to reduce complexity by using a bus. For example, it is widely used in compressors and compressor systems, in battery management solutions and, for instance, in heating systems. CANopen is also used in many medical applications.
CANopen in comparison
Compared with other industrial networks, CANopen has a much richer architecture. Other networks were designed solely to implement remote I/O to a central controller. I/O typically consisted of just one bit, a byte or a word (2 bytes), often characterised by a cyclical pattern of writing and retrieving data in an infinite loop. The protocol supports both asynchronous and synchronous communication in combination, supplemented by the ability to write or retrieve data on an ad hoc basis. A master can also configure slaves to combine sets of data into a single message and then determine the transmission algorithm for it.
CANopen also offers various complex networking capabilities, such as the dynamic addressing of available nodes within a network. Masters can be flexible and configure the network from a PLC or Master Controller based on a programmer’s configuration. However, masters can also be embedded, set up for a single specific machine. CANopen also supports ‘flying masters’. Multiple masters in a single network jointly determine in advance which master is assigned the master role.
Advantages and disadvantages
The open nature of CANopen is, whilst a major advantage, also a significant pitfall. Whereas with other networks the Master Controller or PLC comes from a single manufacturer, with CANopen anyone can offer CANopen Masters. CANopen certification is not mandatory, so deviations may occur. Furthermore, there are unfortunately also CANopen-like nodes on the market. These support the most important messages, but not the full standard.
All of this can lead to some degree of incompatibility. As a result, CANopen projects and systems simply require more attention during development than other plug-and-play industrial networks.
On the other hand, CANopen is an open standard and therefore involves no licences or fees. Furthermore, compared with other networks, it is a cost-effective protocol. Thanks to the robust CAN technology, it also operates very reliably in practice, particularly in places where other networks struggle with interference.
Furthermore, CANopen is easy to implement on a microcontroller and is therefore also very well suited to embedded applications.
