CANopen

CANopen is a CAN-based communication protocol, which is mainly used in automation and networking within complex devices.

The main distribution area of CANopen is Europe. However, increase in both North America and in Asia the number of users. It was mainly initiated by German medium-sized companies and developed under the ESPRIT project ASPIC headed by Bosch as a proto 1993-1995. Since 1995 it is used by the organization CAN in Automation ( CiA) maintained and is standardized as a European Standard EN 50325-4.

Basic services of CANopen

In CANopen Several basic services ( service primitives ) are defined. These basic services are:

In addition to these CANopen client-server services, other communication concepts such as producer-consumer concept can be used. This shows that CANopen is not a classical master-slave system. Originally discovered CANopen in the OSI model, the application layer (layer 7) and from using the CAN of a layer -2 transport medium. Since 2006, however, meshed networks with routing capabilities are standardized.

Communication objects

Communication objects can be broken down as follows in

• Service Data Objects (SDO ) for the parameterization of the object directory entries,
• Process Data Objects ( PDO ) for transporting real -time data,
• Network Management Objects (NMT ) for control of the state machine of the CANopen device and to monitor the nodes,
• Other objects such as synchronization object ( SYNC), timestamps, and error messages ( EMCY).

Object directory

All communication objects and all user objects are grouped together in the object dictionary (OD ) (English Object Dictionary ( OD) ). The OV is in the CANopen device model the link between the application and the CANopen communication unit. Each entry in the object directory represents an object and is identified by a 16 -bit index. An index can in turn contain up to 256 sub-indices. As a result, regardless of the " 11- bit identifiers " to 65536 x 254 elements can be distinguished. ( The sub-indices 0 and 255 can not be used freely. ) Profiles in the assignment of communication and device profile objects to a respective index is well defined; thus is defined externally to the object directory is a single interface between the application and the communication. So each CANopen node in the network is known, for example, that on the index 1017h heartbeat interval is to find, and each node or configuration program can read or write access to it.

For each communication object a unique COB - ID (Communication Object Identifier) ​​exists on the network. The COB - ID consists of 32 -bit values ​​, where the first two bits each of which has an object-specific meaning. In a 11-bit CAN network the following 19 bits (29 to 11) have the value 0 and the last bits ( 10-0 ) comply with the CAN identifier.

Service Data Objects provide a service to access ready to the object directory. Each CANopen device requires at least one SDO server, which receives SDO requests from other devices and processes. Per default setting use messages to a device SDO server, the node number of the receiver 1536 COB ID or as "identifier" for the CAN message. For the response of the SDO server, the node number of the sender 1408 is used as the "identifier". With these relatively high and thus low priority IDs entries are transferred in the OD. For this SDO transfer exists a protocol that requires 4 bytes to the transmit direction, to encode the index and subindex. Thus only 4 bytes of the 8 bytes remain a CAN data field for the data content left. For objects whose data content is greater than 4 bytes, there are two additional protocols to the fragmented SDO transfer.

In contrast to the low-priority and overloaded with log data SDO transfer process data objects provide a faster way for the transport of process data. The data used for PDO transfer "Identifier" Default settings are in the COB- ID range 385-1407, and are thus a higher priority than the SDO messages. Furthermore, they contain only user data, and thus there are 8 bytes are available. The contents of the payload is determined via PDO mapping entries. These are objects in the OD defining as a mapping table, the data to be transmitted over a PDO. These data are in turn the content of other objects of the OV. In a PDO, the values ​​of multiple objects can be transferred, and the recipient of the PDO can use only parts of the data according to their PDO mapping entries. When receiving a PDO turn the data are written according to the mapping entries in each of the other objects OV, for example, in a digital output object. The PDO transmission can be done cyclic, event- oriented, interrogated or synchronized.

Network management objects used for managing the network. There are, inter alia, Messages which cause or spread global error messages a state change in one device.

Sends the Sync object or receives, for example, the high-priority SYNC message, which is used to synchronize the nodes in the network and ensures with the timestamp object a single time in the network. There are also in the communication profile, and in particular, in the device profiles, a variety of other objects.

Device Profiles

For a number of device classes CANopen device profiles have been defined. This device profiles define the functionality and the structure of the object directory for the respective devices. Through the use of CANopen devices that match a certain profile, a higher independence is achieved by the device manufacturers.

Some of the devices profiles are:

Application Profiles

In contrast to the device profiles not the functionality of a group of devices (drives, encoders, inputs and outputs) is described in the application profiles, but the functions of an application. There are, for example, application profiles for lift equipment ( CiA 417), rail vehicles (CiA 421 ), or refuse collection vehicles (CiA 422).

The most important application profiles are:

Electronic Data Sheets

For the use of CANopen devices continuing to provide electronic data sheets, called EDS files necessary. These files describe in a standardized text format, both the main parameters of the objects in the object dictionary of a device as well as physical parameters such as the baud rates supported. Configuration tools can read the EDS files and communicate with their help with the device and parameterize it if necessary. To test the syntactic correctness of EDS, there is the free tool CANchkEDS.

Example: Excerpt from an EDS file

[File Info] Filename = newProject_line0.eds File version = 1 File revision = 0 EDSVersion = 4.0 Description = xxx Creation Time = 10:15 AM Creation Date = 03-06-2005 CreatedBy = me ModificationTime = 10:15 AM ModificationDate = 03-06-2005 ModifiedBy = me [ Device Info ] Vendor Name = xxx Vendor Number = 0x0 ProductName = test Product Number = 0x0 Revision Number = 0x0 Order code = BaudRate_10 = 0 BaudRate_20 = 0 BaudRate_50 = 1 BaudRate_125 = 1 BaudRate_250 = 1 BaudRate_500 = 0 BaudRate_800 = 0 BaudRate_1000 = 0 DynamicChannelsSupported = 0 Group messaging = 0 LSS_Supported = 0 Granularity = 0 SimpleBootUpSlave = 1 SimpleBootUpMaster = 0 NrOfRXPDO = ​​0 NrOfTXPDO = ​​0 [ MandatoryObjects ] SupportedObjects = 3 1 = 0x1000 2 = 0x1001 3 = 0x1018 Parameter Name = Device Type ObjectType = 0x07 DataType = 0x0007 Access Type = const Default Value = 0x00000000 PDOMapping = 0 Parameter name = Error Register ObjectType = 0x07 DataType = 0x0005 Access Type = ro Default Value = 0x00 PDOMapping = 0 Since early 2007, a XML- based description format XDD is standardized. This format is based on the ISO 15745 standard and allows a detailed description of the device functionality. In this case, the application will be described regardless of CANopen and the parameters of the application associated with the objects CANopen.

For this new XML-based format and the previously valid EDS format, there is a free editor named CANeds.