CANopen® is a communication protocol based on CAN. On a CAN bus, nodes communicate by exchanging messages containing a so-called message identifier and up to 8 data bytes.
Closed versus Open communication
Although CAN is a standard, it does not specify what the message identifier stands for or what the data bytes contain. Each application is free to determine this for itself. This works very well in a closed communication system such as a car. However, in industrial applications where universal components from multiple suppliers are often brought together to form a single system, this is downright impractical. The communication protocols of the individual components are therefore incompatible with one another from the outset. This makes setting up a CAN network virtually impossible.
This is where CANopen comes in. Put simply, CANopen is software that manages CAN communication and ensures a universal exchange of data. CANopen ensures that CAN identifiers are optimally distributed amongst all bus participants. Furthermore, CANopen provides all manner of basic functions, such as an address – to address a participant directly – or a heartbeat – to continuously check whether participants are still present or active.
The data itself is also standardised. Data is recorded as objects in a directory, so that nodes can easily exchange data with one another.
CANopen
CANopen treats every connected participant as an independent device, with a unique address, also known as a Node ID. Thanks to the built-in CANopen software, communication with each participant is managed in exactly the same way. So-called profiles have been defined for this purpose: they describe how a typical device functions. For example, there are profiles for I/O devices, motor controllers, encoders, hydraulic actuators and so on.
An Object Directory is used to retrieve or modify data from a device. This allows a device to be configured remotely.
Configuration is carried out by a central system, referred to as the Master. Using configuration messages, the master retrieves data and configures the participants as required. Once a device has been configured, actual control can begin. The master issues the command to all participants to this end. Devices then place real-time information onto the bus – so-called process messages – which are interpreted and processed by other devices.
