Short Introduction on CANopen
Automating with CANopen
CANopen is a standard for distributed industrial automation technology based on CAN-bus. It was developed by the manufacturer and users association CiA (CAN in Automation) and has been standardized since late 2002 as CENELEC EN 50325-4. CANopen has established itself in a number of areas of industrial communication (e.g. mechanical engineering, drive systems and components, medical devices, building automation, vehicle construction, etc.). The fundamental communications mechanisms are described in the so-called Communication Profile. Devices from different manufacturers can be used in a CANopen network and work in harmony with each other. Frameworks complement the communication profile for specific applications. This is how frameworks are defined for safety-compliant data transfer ("CANopen Safety") or for programmable devices (e.g. PLCs). The so-called object directory is the central element of every CANopen device and describes the device's functionality.
The object directory is the central element of a CANopen device. It describes the complete functionality of the device from the perspective of the network. The object directory represents the interface between the network and the application. All entries in the object directory are referenced using a 16-bit index and an 8-bit sub-index. The object directory contains all of the parameters accessible via the network. Device identifiers, manufacturer name, communications parameters for the PDOs and SDOs and device monitoring ("error control"), for example, are stored in the generally applicable area of the object directory. The device-specific area contains the connection to the process; that is, the I/O functionality (analog and digital inputs and outputs), parameters for drives, mapping of a PLC process image. The behavior in the event of an error can also be configured in the object directory. Accordingly, the behavior of a device can be adapted to the respective utilization requirements using the object directory.
Device profiles describe the properties and features of the most important device types that are utilized in automation technology. Both functions and parameters of the respective standard device types are defined. All parameters are stored in the object directory. In this way, it is ensured that the CANopen devices can be accessed in the same manner as using the CANbus. This creates the prerequisite for a far-reaching multi-vendor capability through interoperability and interchangeability of different manufacturers' devices. Device profiles are defined for digital and analog I/O devices, drives PLCs, controllers, for example. The parameters and properties of the CANopen devices are described in a standardized EDS file (electronic data sheet) in ASCII format. It can be understood as a 'form' containing all device properties that are accessible over the network. The actual parameters of a particular device configuration are stored in the DCF (device configuration file). A DCF is derived from an EDS.
Data Transfer using PDO/SDO
CANopen differentiates between two data transfer mechanisms. Fast exchange of short process data is done using process data objects (PDOs, Process Data Object). Access to the entries of the object directory is done via SDO (Service Data Object). PDOs can be transferred event-controlled, cyclic or on-demand. Transfer is done without protocol overhead as broadcast objects. A PDO transfers up to 8 bytes of data. A synchronization message synchronizes the sending and data migration network-wide. The properties of each PDO can be configured in the object directory. This includes the communications parameters (CAN-identifiers, transmission type, etc.) and the assignment of the process data to the respective PDO using so-called PDO mapping. SDOs are confirmed data transfers using 2 CAN-telegrams. They establish point-to-point communication between two devices. In this way, large data packets (> 8 bytes) can be transferred for each SDO.
Network management (NMT) is available for control of the device status. It is structured as a master – slave relationship. A CANopen device sends a signal to the NMT master via a boot-up message that it is initialized and is active on the network. The device status of individual devices or of the entire network can be specifically influenced using NMT commands. Every device status is characterized by specific properties. PDOs are transferred only in the OPERATIONAL status. Configuration of the device can be done in the PRE_OPERATIONAL condition. The STOPPED condition blocks communication by means of both PDOs and SDOs. "Node – Guarding and "Heartbeat" are two alternative services that monitor the communication capability and the status of a CANopen device. Alarm messages are defined for reporting device errors. These high-priority 'emergency' messages are transferred event-oriented. Standardized error codes describe in more detail the errors that occur.
CANopen networks enable transfer of safety-oriented information. Safety functions (e.g. Emergency OFF, Two-handed operation) can be integrated into a CANopen network. Special safety-relevant services (SRDO, Safety Relevant Data Object) accept the communication. An SRDO transfers up to 8 bytes of safety information. Transfer of the data is done redundantly in a defined time window.