CANopen

from Wikipedia, the free encyclopedia
CANopen logo

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

The main distribution area of ​​CANopen is Europe. However, user numbers are increasing in both North America and Asia. It was mainly initiated by German medium-sized companies and developed as a prototype from 1993 to 1995 as part of the ESPRIT project ASPIC under the direction of Bosch . It has been maintained by the CAN in Automation (CiA) organization since 1995 and is standardized as the European standard EN 50325-4.

Basic services of CANopen

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

Request
Request for a CANopen service by the application
Indication
Notification to the application that there is a result or a specific message
Response
Application response to an indication
Confirmation
Confirmation to the application that a CANopen service has been carried out

In addition to these client-server services, other communication concepts such as the producer-consumer concept are also used in CANopen . This shows that CANopen is not a classic master-slave system. Originally, CANopen covered the application layer (layer 7) in the OSI model and uses CAN as a layer 2 transport medium. However, meshed networks with routing options have also been standardized since 2006 .

Communication objects

Communication objects can be divided into

  • Service data objects (SDO) for the parameterization of object directory entries,
  • Process data objects (PDO) for the transport of real-time data,
  • Network management objects (NMT) for controlling the state machine of the CANopen device and for monitoring the nodes,
  • other objects such as synchronization object (SYNC), time stamp and error messages (EMCY).

Object directory

All communication objects and all user objects are summarized in the Object Dictionary (OD). In the CANopen device model, the OV is the link between the application and the CANopen communication unit. Each entry in the object dictionary stands for an object and is identified by a 16-bit index. An index can in turn contain up to 255 sub-indices. This means that up to 65536 × 254 elements can be differentiated independently of the "11-bit identifiers". (The sub-indices 0 and 255 cannot be used freely.) In profiles, the assignment of communication and device profile objects to a respective index is precisely defined; thus a clear interface between the application and the external communication is defined with the object directory. For example, every CANopen node in the network knows that the heartbeat interval can be found on index 1017h, and every node or every configuration program can read or write to it.

Index area use
0000-0000 not used
0001-009F Data types (special case)
00A0-0FFF reserved
1000-1FFF Communication profile
2000-5FFF manufacturer-specific area
6000-9FFF up to 8 standardized device profiles
A000-AFFF Process images of IEC61131 devices
B000-BFFF Process images of CANopen gateways according to CiA 302-7
C000-FFFF reserved

For each communication object there is a unique COB-ID (Communication Object Identifier) ​​in the network. The COB-ID consists of 32-bit values, whereby the first two bits each have an object-specific meaning. In an 11-bit CAN network, the following 19 bits (29 to 11) have the value 0 and the last bits (10 to 0) correspond to the CAN identifier.

Service data objects provide a service for accessing the object dictionary. Every CANopen device requires at least one SDO server, which accepts and processes SDO requests from other devices. By default, messages to the SDO server of a device use the node number of the recipient + 1536 (0x600) as a COB ID or as an "identifier" for the CAN message. The node number of the sender +1408 (0x580) is used as the "identifier" for the response from the SDO server. Entries in the OV are transmitted with these relatively high and thus low-priority IDs. There is a protocol for this SDO transfer which requires 4 bytes to encode the direction of transmission, the index and the subindex. This leaves only 4 bytes of the 8 bytes of a CAN data field for the data content. For objects whose data content is larger than 4 bytes, there are two other protocols for fragmented SDO transfer.

In contrast to the low-priority SDO transfer that is overloaded with protocol data, the process data objects provide a faster way of transporting process data. The "identifiers" used for PDO transfer are with default settings in the COB ID range from 385 (0x181) to 1407 (0x57F) and are therefore prioritized higher than the SDO messages. Furthermore, they only contain user data, so 8 bytes are available. The content of the user data is determined via PDO mapping entries. These are objects in the OD which, like an assignment table, determine which data are transmitted via a PDO. These data are in turn the content of other objects in the OV. The values ​​of several objects can also be transmitted in a PDO, and the receivers of the PDO can only use parts of the data according to their PDO mapping entries. When a PDO is received, the data is in turn transferred to other objects of the OD according to the mapping entries, e.g. B. in a digital output object written. The transmission of PDOs can take place cyclically, event-oriented, queried or synchronized.

Network management objects are used to manage the network. So there are u. a. Messages that cause a status change in a device or spread global error messages.

The sync object sends or receives, for example, the high-priority SYNC message, which is used to synchronize the nodes in the network and ensures a uniform time in the network with the time stamp object. In addition, there are a number of other objects in the communication profile and especially in the device profiles.

Device profiles

CANopen device profiles have been defined for a number of device classes. These device profiles define the functionality and structure of the object directory for the respective devices. By using CANopen devices that correspond to a certain profile, greater independence from the device manufacturers is achieved.

Some of the device profiles are:

default Device class
CiA 401 Input / output modules
CiA 402 electric motors
CiA 404 Sensors and controllers
CiA 406 Linear and rotating encoders
CiA 408 hydraulic valves and actuators

Application profiles

SIG Lift logo

In contrast to the device profiles, the application profiles do not describe the functionality of a group of devices (drives, encoders, inputs / outputs), but the functions of an application. So there are z. B. Application profiles for elevator systems (CiA 417), rail vehicles (CiA 421), garbage trucks (CiA 422) or electric light vehicles such as electric bicycles (CiA 454 EnergyBus ).

The most important application profiles are:

default application
CiA 410 Inclinometer
CiA 412 Medical equipment
CiA 413 Gateways to truck bodies
CiA 415 Sensors for road construction machines
CiA 416 Door controls
CiA 417 Elevator controls
CiA 418/9 Batteries and chargers
CiA 420 Extruder downstream devices
CiA 421 Rail vehicles
CiA 422 Garbage trucks
CiA 444 Cranes / spreaders
CiA 454 Light electric vehicles

Electronic datasheets

Electronic data sheets, so-called EDS files, are still required for the use of CANopen devices. These files in a standardized text format describe both the most important parameters of the objects in the object directories of a device and physical parameters such as B. the supported baud rates. Configuration tools can read EDS files and, with their help, communicate with the respective device and, if necessary, parameterize it. The free tool CANchkEDS is used to check the syntactic correctness of an EDS.

Example: Extract from an EDS file

[FileInfo]
FileName=newProject_line0.eds
FileVersion=1
FileRevision=0
EDSVersion=4.0
Description=xxx
CreationTime=10:15AM
CreationDate=03-06-2005
CreatedBy=me
ModificationTime=10:15AM
ModificationDate=03-06-2005
ModifiedBy=me
[DeviceInfo]
VendorName=xxx
VendorNumber=0x0
ProductName=test
ProductNumber=0x0
RevisionNumber=0x0
OrderCode=
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
GroupMessaging=0
LSS_Supported=0
Granularity=0
SimpleBootUpSlave=1
SimpleBootUpMaster=0
NrOfRXPDO=0
NrOfTXPDO=0
[MandatoryObjects]
SupportedObjects=3
1=0x1000
2=0x1001
3=0x1018
[1000]
ParameterName=Device Type
ObjectType=0x07
DataType=0x0007
AccessType=const
DefaultValue=0x00000000
PDOMapping=0
[1001]
ParameterName=Error Register
ObjectType=0x07
DataType=0x0005
AccessType=ro
DefaultValue=0x00
PDOMapping=0

An XML-based description format XDD has been standardized since the beginning of 2007 . This format is based on the ISO standard 15745 and allows a detailed description of the device functionality. The application is described independently of CANopen and the parameters of the application are assigned to the CANopen objects.

There is a free editor called CANeds for this new, XML-based format as well as for the EDS format that was valid before.

Individual evidence

  1. http://www.can-cia.org/can-knowledge/canopen/canopen/
  2. Some of the device profiles can be downloaded free of charge from the CiA website.
  3. http://www.embedded-communication.com/canopen/energybus-the-canopen-based-communication-standard-for-levs-and-e-bikes/
  4. Source for downloading the free EDS-checker CANchkEDS ( Memento of the original from January 28, 2011 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.  @1@ 2Template: Webachiv / IABot / canopen-forum.com
  5. Source for the download of the free editor CANeds

Web links