THE BASICS OF CANOPEN
According to CIA (CIA meaning CAN in Automation), the international users’ and manufacturers’ group for the CAN network (Controller Area Network), “CANopen is a CAN-based communication system. It comprises higher-layer protocols and profile specifications. CANopen has been developed as a standardized embedded network with highly flexible configuration capabilities. It was designed originally for motion-oriented machine control systems, such as handling systems. Today it is used in various application fields, such as medical equipment, off-road vehicles, maritime electronics, railway applications, or building automation.”
Like DeviceNet and J1939, CANopen is another low-level industrial application layer protocol for automation applications. CANopen connects automation devices together using peer messaging. Built on the standard CAN (Controller Area Network) physical communications standard, CANopen uses CAN hardware to define an application layer protocol that structures the task of configuring, accessing and messaging between various kinds of automation devices.
CANOPEN DEVICE ARCHITECTURE
A CANopen device includes three parts:
- The CANopen protocol stack which handles the communication via the CAN network
- The application software which provides the internal control functionality as well as an interface to the process hardware interfaces
- The CANopen Object Dictionary interfaces the protocol as well as the application software. It contains references (indices) for all used data types and stores all communication and application parameters.
CANOPEN DATA STRUCTURE
Read on to understand the basic concepts of the CANopen protocol application layer.
Object Dictionary
The CANopen Object Dictionary is the core of a CANopen device. This is essentially a table that stores configuration and process data. As CANopen is an object-based communications protocol, the object dictionary is the connection point between the communication interface and the application program. CANopen defines a 16-bit index and 8-bit sub-index.
The CANopen Object Dictionary provides standardized communication objects for real-time data (PDOs – Process Data Objects), configuration data (SDOs – Service Data Objects), and special functions (Time Stamp, Sync Message, and Emergency Message) as well as network management data (Boot-up Message, NMT Message, and Error Control Message).
The two CANopen communication mechanisms for accessing the object dictionary are Service Data Objects (SDOs) and Process Data Objects (PDOs).
The basic CANopen datatypes for object dictionary values such as booleans, integers and floats are defined in the standard (their size in bits is optionally stored in the related type definition, index range 0x0001–0x001F), as well as composite data types such as strings, arrays and records (defined in index range 0x0040–0x025F). The composite datatypes can be subindex with an 8-bit index; the value in subindex 0 of an array or record indicates the number of elements in the data structure and is of type UNSIGNED8.
CANOPEN COMMUNICATION PROTOCOLS/SERVICES
A CANopen protocol stack implements several CANopen COBs that are communicated with one of the CANopen bit-rates. The CANopen communication objects enable system designers to transfer control information, to react to certain error conditions or to influence and control the network behavior. There are 7 service types mentioned under CANopen communication protocols:
Network Management (NMT)
The NMT service is used for controlling the state of CANopen devices (e.g. pre-operational, operational, stopped) by means of NMT commands (e.g. start, stop, reset).
Synchronization (SYNC)
The SYNC message is used e.g. to synchronize the sensing of inputs and actuation of several CANopen devices – typically triggered by the application master.
Emergency (EMCY)
The emergency service is used in case a device experiences a fatal error (e.g. a sensor failure), allowing it to indicate this to the rest of the network.
Timestamp (TIME) (PDO)
With this communication service, a global network time can be distributed. The TIME service contains a 6-byte date & time information.
Process Data Object (PDO)
The PDO service is used to transmit real-time data between devices – e.g. measured data such as position or command data such as torque requests. A PDO communicates up to 8 bytes of pure application data.
Service Data Object (SDO)
The SDO services are used to access/change values in the object dictionary of a CANopen device – e.g. when an application master needs to change certain configurations of a CANopen device.
ADVANTAGE FOR DEVICE DESIGNERS & MANUFACTURERS
CANopen is on one hand standardized, but on the other hand, it is still open to a nearly unlimited field of applications.
CANopen provides several communication objects, which enable device designers to implement desired network behavior into a device. With these communication objects, device designers can offer devices that can communicate process data, indicate device-internal error conditions or influence and control the network behavior. As CANopen defines the internal device structure, the system designer knows exactly how to access a CANopen device and how to adjust the intended device behavior.
CANopen unburdens the developer from dealing with CAN hardware-specific details such as bit timing and acceptance filtering. It provides standardized communication objects (COB) for time-critical processes, configuration as well as network management data.
The 11-bit id of a CAN-frame is known as a communication object identifier or CANopen COB-ID. In case of a transmission collision, the bus arbitration used in the CAN bus allows the frame with the smallest id to be transmitted first and without a delay.
CANopen servo drives and CANopen motor controllers offer great advantages over traditional serial servo drives and controllers. The CIA standard object dictionaries provide a faster time-to-market for applications development and improve compatibility between slave devices and master controllers.
For system designers, it is very important to reuse application software. This requires not only communication compatibility but also interoperability and interchangeability of devices. CANopen device, interface, and application profiles enable device manufacturers to provide their products with standardized interfaces to achieve CANopen devices with “plug and play” capability. CANopen allows implementing manufacturer-specific functionalities.
CONCLUSION
Since its initial release in 1996, CANopen has found broad acceptance around the world as the leading standard for CAN-based system solutions.
Functionality, parameters and the access to process data of standard devices such as I/O modules, drives, controllers, or encoders are defined by so-called device profiles. Thus, devices of different manufacturers can be accessed via the bus in exactly the same manner. This provides a high degree of vendor independence.
Messung, the pioneer of the indigenous PLC in India, has developed the XM-PRO range of advanced CANopen I/O modules, which it uses to expand the capabilities of its smart automation solutions. In fields such as machine control, factory automation and building automation, Messung utilizes the power of CANopen to deliver cutting-edge automation solutions for productivity, efficiency and sustainability.