CANopen

CANopen

CANopen is a communication protocol and device profile specification for embedded systems used in automation. In terms of the OSI model, CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, several small communication protocols and an application layer defined by a device profile. The communication protocols have support for network management, device monitoring and communication between nodes, including a simple transport layer for message segmentation/desegmentation. The lower level protocol implementing the data link and physical layers is usually Controller Area Network (CAN), although devices using some other means of communication (such as EtherCAT) can also implement the CANopen device profile.

The basic CANopen device and communication profiles are given in the CAN in Automation (CiA) draft standard 301.ref|CiA301 Profiles for more specialized devices are built on top of this basic profile, and are specified in numerous other standards released by CAN in Automation, such as CiA401ref|CiA401 for I/O-modules and CiA402ref|CiA402 for motion control.

Device model

Every CANopen device has to implement certain standard features in its controlling software.

* A Communication unit implements the protocols for messaging with the other nodes in the network
* Starting and resetting the device is controlled via a state machine. It must contain the states Initialization, Pre-operational, Operational and Stopped. The transitions between states are made by issuing a network management (NMT) communication object to the device.
* The object dictionary is an array of variables with a 16-bit index. Additionally, each variable can have an 8-bit subindex. The variables can be used to configure the device and reflect its environment, i.e. contain measurement data.
* The application part of the device actually performs the desired function of the device, after the state machine is set to the operational state. The application is configured by variables in the object directory and the data is sent and received through the communication layer.

Object dictionary

CANopen devices must have an object dictionary, which is used for configuration and non-realtime communication with the device. An entry in the object dictionary is defined by:
* Index, the 16-bit address of the object in the dictionary
* Object name, a symbolic type of the object in the entry, such an array, record, or simple variable
* Name, a string describing the entry
* Type, gives the datatype of the variable
* Attribute, which gives information on the access rights for this entry, this can be read/write, read-only, write-only or read only constant
* The Mandatory/Optional field defines whether a device conforming to the device specification has to implement this object or not

The basic datatypes for object dictionary values such as booleans, integers and floats are defined in the standard, as well as composite datatypes such as arrays, records and strings. The composite datatypes can be subindexed 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.

For example, the device communication parameters, standardized in the basic device profile DS301ref|CiA301 are mapped in the index range 0x1000 - 0x1FFF ("communication profile area"). The first few entries in this area are as follows:

* ccs is the client command specifier of the SDO transfer, this is 0 for SDO segment download, 1 for initiating download, 2 for initiating upload, 3 for SDO segment upload and 4 for aborting an SDO transfer
* n is the number of bytes in the data part of the message which do not contain data, only valid if e and s are set
* e, if set, indicates an expedited transfer , i.e. all data exchanged are contained within the message. If this bit is cleared then the message is a segmented transfer where the data does not fit into one message and multiple messages are used.
* s, if set, indicates that the date set size is specified in n (if e is set) or in the data part of the message
* index is the object directory index of the data to be accessed
* subindex is the subindex of the object directory variable
* data contains the data to be uploaded in the case of an expedited transfer (e is set), or the size of the data to be uploaded (s is set, e is not set)

Process Data Object (PDO) protocol

Process Data Object protocol is used to process real time data among various nodes. You can transfer up to 8 bytes (64bits) data per one PDO either from or to the device. One PDO can contain multiple object dictionary entries and the objects within one PDO is configurable using the mapping and parameter object dictionary entries. There are four (4) TPDOs and four (4) RPDOs available.

There are two kinds of PDOs: transmit and receive PDOs (TPDO and RPDO). The former is for data coming from the device and the latter is for data going to the device, ie. with RPDO you can send data to the device and with TPDO you can read data from the device.

PDOs can be send synchronously or asynchronously. Synchronous PDOs are sent after the SYNC message whereas asynchronous messages are sent after internal or external trigger. For example, you can make a request to a device to transmit TPDO that contains data you need by sending empty TPDO with RTR flag (if the device is configured to accept TPDO requests).

With RPDOs you can, for example, start two devices simultaneously. You only need to map the same RPDO into two or more different device and make sure those RPDOs are mapped with the same COB ID.

ynchronization Object (SYNC) protocol

The Sync-Producer provides the synchronization-signal for the Sync-Consumer. When the Sync-Consumer receive the signal they start carrying out their synchronous tasks.

In general the fixing of the transmission time of synchronous PDO messages coupled with the periodicity of transmission of the Sync Object guarantees that sensor devices may arrange to sample process variables and that actuator devices may apply their actuation in a coordinated fashion.

The identifier of the Sync Object is available at index 1005h.

Time Stamp Object (TIME) protocol

Usually the Time-Stamp object represents an absolute time in ms after midnight and the number of days since January 1, 1984. This is a bit sequence of length 48 (6 byte).

Some time critical applications especially in large networks with reduced transmission rates require very accurate synchronization; it may be necessary to synchronize the local clocks with an accuracy in the order of microseconds.This is achieved by using the optional high resolution synchronization protocol which employs a special form of time stamp message to adjust the inevitable drift of the local clocks.

The high-resolution time-stamp is encoded as unsigned32 with a resolution of 1 microsecond which means that the time counter restarts every 72 minutes. It is configured by mapping the high resolution time-stamp (object 1013h) into a PDO.

Emergency Object (EMCY) protocol

Emergency messages are triggered by the occurrence of a device internal fatal error situation and are transmitted from the concerned application device to the other devices with high priority. This makes them suitable for interrupt type error alerts. An Emergency Telegram may be sent only once per ‘error event’, i.e. the emergency messages must not be repeated. As long as no new errors occur on a device no further emergency message must be sent.By means of CANopen Communication Profile defined emergency error codes, the error register and device specific additional information are specified in the device profiles.

Initialization

Sample trace of communications between a master and 2 pressure transducer slaves configured for id 1 and node id 2.

Glossary of CANopen Terms

PDO Process Data Object - Inputs and outputs. Values of type RPM, V, Hz, mAmps etc.
SDO Service Data Object - Configuration settings, possibly NODE ID, baud rate, offset, gain etc.
COB-ID - CAN Object Identifiers
CAN ID - CAN Identifier. This is the 11 bit CAN message identifier which is at the beginning of every CAN message on the bus.
EDS - Electronic data sheet. This is an INI style resp. XML style formatted file.
DCF - Device configuration file. This is modified EDS with settings for node ID and baud rate.

The EDS file is a file format, that describes the communication behaviour and the object dictionary entries of a device. Those EDS files are mandatory for passing the CiA CANopen Conformance Test. A free EDS checker is [http://www.vector-worldwide.com/downloads/canchkeds.zip CANchkEDS]

ee also

* Controller area network Article on the CANBUS.

References

#Note|CiA301 CiA Draft Standard 301, available from [http://www.can-cia.org CAN in Automation]
#Note|CiA306 CiA Draft Standard 306
#Note|CiA311 CiA Draft Standard 311
#Note|CiA401 CiA Draft Standard 401
#Note|CiA402 CiA Draft Standard 402

External links

* [http://www.canopensolutions.com/english/about_canopen/about_canopen.shtml About CANopen (canopensolutions.com)]
* [http://www.canfestival.org/ CanFestival - An open source CANopen multiplatform framework]
* [http://www.industrialcontroldesignline.com/showArticle.jhtml?articleID=192200423 CANopen: An Introduction]
* [http://www.can-cia.org/index.php?id=171 CANopen overview]
* [http://www.canopendesign.com CANopen Design Information]
* [http://www.softing.com/home/en/industrial-automation/products/can-bus/more-can-open/communication/reference-model.php CANopen educational pages]
* [http://www.can-wiki.info/CanOpen CANopen-Page in the CAN-wiki]
* [http://www.esacademy.com/myacademy/classes/CANopenIntro/CANopenIntro_files/frame.htm?category=& CANopen Introduction]
* [http://www.canopen-solutions.com/canopen_fundamentals_en.html Introduction to CANopen Fundamentals (in www.canopen-solutions.com)]
* [http://en.canopen-lift.org/ Wiki of the CANopen-Lift Community]


Wikimedia Foundation. 2010.

Игры ⚽ Нужно сделать НИР?

Look at other dictionaries:

  • CANOpen — est une couche applicative (couche 7 du modèle OSI), originellement pour les bus de terrain du type CAN (Controller area network) fonctionnant en temps réel. D autres bus intègrent depuis peu CANopen, tel (EtherCAT, Powerlink) démontrant par là l …   Wikipédia en Français

  • CANopen — открытый сетевой протокол верхнего уровня для подключения встраиваемых устройств в бортовых транспортных и промышленных сетях. В качестве сетевого и транспортного уровня использует протокол реального времени CAN. Используется для связи датчиков,… …   Википедия

  • CANopen — est une couche applicative (couche 7 du modèle OSI), originellement pour les Bus de terrain du type CAN (Controller area network) fonctionnant en temps réel. D autres bus intègrent depuis peu CANopen, tel (EtherCAT, Powerlink) démontrant par là l …   Wikipédia en Français

  • CANopen — Logo von CANopen CANopen ist ein auf CAN basierendes Kommunikationsprotokoll, welches hauptsächlich in der Automatisierungstechnik und zur Vernetzung innerhalb komplexer Geräte verwendet wird. Das Hauptverbreitungsgebiet von CANopen ist Europa.… …   Deutsch Wikipedia

  • Canopen — …   Википедия

  • прикладной уровень CANopen — Прикладной уровень и коммуникационный профиль CANopen определяются стандартом EN 50325 2. Этот стандарт описывает коммуникационные сервисы и объекты. Кроме того, он дает спецификацию объектного словаря и протокола управление сетью (NMT).… …   Справочник технического переводчика

  • безопасный CANopen — Коммуникационный протокол, позволяющий осуществлять безопасную передачу данных. Для его реализации достаточно одной физической CAN сети. Избыточность достигается путем передачи каждого сообщения дважды с побитно инвертированными данными и… …   Справочник технического переводчика

  • CAN-Bus — CAN Logo Der CAN Bus (Controller Area Network) ist ein asynchrones, serielles Bussystem und gehört zu den Feldbussen. Um die Kabelbäume (bis zu 2 km pro Fahrzeug) zu reduzieren und dadurch Gewicht zu sparen, wurde der CAN Bus 1983 von Bosch für… …   Deutsch Wikipedia

  • CAN Bus — CAN Logo Der CAN Bus (Controller Area Network) ist ein asynchrones, serielles Bussystem und gehört zu den Feldbussen. Um die Kabelbäume (bis zu 2 km pro Fahrzeug) zu reduzieren und dadurch Gewicht zu sparen, wurde der CAN Bus 1983 von Bosch für… …   Deutsch Wikipedia

  • Can-bus — CAN Logo Der CAN Bus (Controller Area Network) ist ein asynchrones, serielles Bussystem und gehört zu den Feldbussen. Um die Kabelbäume (bis zu 2 km pro Fahrzeug) zu reduzieren und dadurch Gewicht zu sparen, wurde der CAN Bus 1983 von Bosch für… …   Deutsch Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”