www.fgks.org   »   [go: up one dir, main page]

Jump to content

Examine individual changes

This page allows you to examine the variables generated by the Edit Filter for an individual change.

Variables generated for this change

VariableValue
Whether or not the edit is marked as minor (no longer in use) (minor_edit)
false
Name of the user account (user_name)
'185.31.100.120'
Whether the user is editing from mobile app (user_app)
false
Whether or not a user is editing through the mobile interface (user_mobile)
false
user_wpzero
false
Page ID (page_id)
3837568
Page namespace (page_namespace)
0
Page title without namespace (page_title)
'CANopen'
Full page title (page_prefixedtitle)
'CANopen'
Action (action)
'edit'
Edit summary/reason (summary)
'Add the CANopen predefined connection set table and a reference to it'
Old content model (old_content_model)
'wikitext'
New content model (new_content_model)
'wikitext'
Old page wikitext, before the edit (old_wikitext)
''''CANopen''' is a communication [[Protocol (computing)|protocol]] and device profile specification for [[embedded system]]s 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 layer|data link]] and [[physical layer]]s is usually [[CAN bus|Controller Area Network]] (CAN), although devices using some other means of communication (such as [[Ethernet Powerlink]], [[EtherCAT]]) can also implement the CANopen device profile. The basic CANopen device and communication profiles are given in the CiA 301 specification released by [[CAN in Automation]].{{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 CiA 401{{ref|CiA401}} for I/O-modules and CiA 402{{ref|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 [[Finite-state machine |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 dictionary and the data are sent and received through the communication layer. ===Object dictionary=== CANopen devices must have an object dictionary, which is used for configuration and 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''' (Object Type/Size), a symbolic type of the object in the entry, such as an array, record, or simple variable * '''Name''', a string describing the entry * '''Type''', gives the datatype of the variable (or the datatype of all variables of an array) * '''Attribute''', which gives information on the access rights for this entry, this can be read/write, read-only or write-only * The '''Mandatory/Optional''' field (M/O) defines whether a device conforming to the device specification has to implement this object or not The basic [[datatype]]s for object dictionary values such as [[Boolean data type|booleans]], [[Integer (computer science)|integers]] and [[Floating point|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 datatypes such as strings, arrays and records (defined in index range 0x0040–0x025F). 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 CiA 301{{ref|CiA301}} are mapped in the index range 0x1000–0x1FFF ("communication profile area"). The first few entries in this area are as follows: {| class="wikitable" |- ! Index ! Object name ! Name ! Type ! Attribute ! M/O |- | 0x1000 | VAR | device type | UNSIGNED32 | ro | M |- | 0x1001 | VAR | error register | UNSIGNED8 | ro | M |- | ... | | | | | |- | 0x1008 | VAR | manufacturer device name | Vis-String | const | O |- | ... | | | | | |} Given suitable tools, the content of the object dictionary of a device, based on an electronic data sheet (EDS), can be customized to a device configuration file (DCF) to integrate the device into a specific CANopen network. According to CiA 306{{ref|CiA306}}, the format of the EDS-file is the [[INI file]] format. There is an upcoming XML-style format, that is described in CiA 311{{ref|CiA311}}. ==Communication== ===Communication objects=== [[CAN bus]], the data link layer of CANopen, can only transmit short packages consisting of an 11-bit id, a remote transmission request (RTR) bit and 0 to 8 bytes of data. The CANopen standard divides the 11-bit CAN frame id into a 4-bit function code and 7-bit CANopen node&nbsp;ID. This limits the number of devices in a CANopen network to 127 (0 being reserved for broadcast). An extension to the CAN bus standard (CAN 2.0 B) allows extended frame ids of 29 bits, but in practice CANopen networks big enough to need the extended id range are rarely seen. In CANopen the 11-bit id of a CAN-frame is known as communication object identifier, or 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. Using a low code number for time critical functions ensures the lowest possible delay. Contents of an 11-bit CANopen frame: {| class="wikitable" |- ! ! CAN-ID ! RTR ! Data length ! Data |- ! Length | 11 bits | 1 bit | 4 bits | 0-8 bytes |} The data frame with an 11-bit identifier is also called "base frame format". The default CAN-ID mapping sorts frames by attributing a function code (NMT, SYNC, EMCY, PDO, SDO...) to the first 4 bits, so that critical functions are given priority. This mapping can however be customized for special purposes (except for NMT and SDO, required for basic communication). {| class="wikitable" |- ! ! Function code ! Node&nbsp;ID |- ! Length | 4 bits | 7 bits |} The standard reserves certain CAN-IDs to network management and SDO transfers. Some function codes and CAN-IDs have to be mapped to standard functionality after device initialization, but can be configured for other uses later. {| class="wikitable" |- ! Communication object<ref>http://www.canopensolutions.com/english/about_canopen/predefined.shtml</ref> !! COB-ID(s) hex !! Slave nodes |- | NMT node control || 000 || Receive only |- | Sync || 080 || Receive only |- | Emergency || 080 + NodeID || Transmit |- | TimeStamp || 100 || Receive only |- | PDO || 180 + NodeID<br />200 + NodeID<br />280 + NodeID<br />300 + NodeID<br />380 + NodeID<br />400 + NodeID<br />480 + NodeID<br />500 + NodeID || 1. Transmit PDO<br />1. Receive PDO<br />2. Transmit PDO<br />2. Receive PDO<br />3. Transmit PDO<br />3. Receive PDO<br />4. Transmit PDO<br />4. Receive PDO |- | SDO || 580 + NodeID<br />600 + NodeID || Transmit<br />Receive |- | NMT node monitoring (node guarding/heartbeat) || 700 + NodeID || Transmit |- | LSS || 7E4<br />7E5 || Transmit<br />Receive |} ===Communication models=== Different kinds of communication models are used in the messaging between CANopen nodes. In a '''master/slave''' relationship, one CANopen node is designated as the master, which sends or requests data from the slaves. The NMT protocol is an example of a master/slave communication model. A '''client/server''' relationship is implemented in the SDO protocol, where the SDO client sends data (the object dictionary index and subindex) to an SDO server, which replies with one or more SDO packages containing the requested data (the contents of the object dictionary at the given index). A '''producer/consumer''' model is used in the Heartbeat and Node Guarding protocols. In the ''push-model'' of producer/consumer, the producer sends data to the consumer without a specific request, whereas in the ''pull model'', the consumer has to request the data from the producer. ===Protocols=== ====Network management (NMT) protocols==== The NMT protocols are used to issue state machine change commands (e.g. to start and stop the devices), detect remote device bootups and error conditions. The '''Module control protocol''' is used by the NMT master to change the state of the devices. The CAN-frame COB-ID of this protocol is always 0, meaning that it has a function code 0 and node&nbsp;ID 0, which means that every node in the network will process this message. The actual node&nbsp;ID, to which the command is meant to, is given in the data part of the message (at the second byte). This can also be 0, meaning that all the devices on the bus should go to the indicated state. {| class="wikitable" |- ! COB-ID !! Data Byte 0 !! Data Byte 1 |- | 0x000 || Requested state || Addressed node |} {| class="wikitable" |- ! NMT command code !! Meaning |- | 0x01 || Go to 'operational' |- | 0x02 || Go to 'stopped' |- | 0x80 || Go to 'pre-operational' |- | 0x81 || Go to 'reset node' |- | 0x82 || Go to 'reset communication' |} The '''Heartbeat protocol''' is used to monitor the nodes in the network and verify that they are alive. A heartbeat producer (usually a slave device) periodically sends a message with the binary function code of 1110 and its node&nbsp;ID (COB-ID = 0x700 + node&nbsp;ID). The data part of the frame contains a byte indicating the node status. The heartbeat consumer reads these messages. If the messages fail to arrive within a certain time limit (defined in the object dictionary of the devices) the consumer can take action to, for example, reset the device or indicate an error. The frame format is: {| class="wikitable" |- ! COB-ID !! Data Byte 0 |- | 0x700 + node&nbsp;ID || State |} {| class="wikitable" |- ! NMT state code !! Represented state |- | 0x00 || Boot up (Initialising) |- | 0x04 || Stopped |- | 0x05 || Operational |- | 0x7f || Pre-operational |} CANopen devices are required to make the transition from the state Initializing to Pre-operational automatically during bootup. When this transition is made, a single heartbeat message is sent to the bus. This is the '''bootup protocol'''. A response/reply-style (pull model) protocol, called node guarding, exists for slave monitoring. ====Service Data Object (SDO) protocol==== {{distinguish|text=[[Service Data Objects]], a data-as-a-service abstraction}} The SDO protocol is used for setting and for reading values from the object dictionary of a remote device. The device whose object dictionary is accessed is the SDO server and the device accessing the remote device is the SDO client. The communication is always initiated by the SDO client. In CANopen terminology, communication is viewed from the SDO server, so that a read from an object dictionary results in an SDO upload and a write to a dictionary entry is an SDO download. Because the object dictionary values can be larger than the eight bytes limit of a CAN frame, the SDO protocol implements segmentation and desegmentation of longer messages. Actually, there are two of these protocols: SDO download/upload and SDO Block download/upload. The SDO block transfer is a newer addition to standard, which allows large amounts of data to be transferred with slightly less protocol overhead. The COB-IDs of the respective SDO transfer messages from client to server and server to client can be set in the object dictionary. Up to 128 SDO servers can be set up in the object dictionary at addresses 0x1200 - 0x127F. Similarly, the SDO client connections of the device can be configured with variables at 0x1280 - 0x12FF. However the ''pre-defined connection set'' defines an SDO channel which can be used even just after bootup (in the Pre-operational state) to configure the device. The COB-IDs of this channel are 0x600 + node&nbsp;ID for receiving and 0x580 + node&nbsp;ID for transmitting. To initiate a download, the SDO client sends the following data in a CAN message with the 'receive' COB-ID of the SDO channel. {| class="wikitable" |- ! colspan="5" | Byte 1 ! Byte 2-3 ! Byte 4 ! Byte 5-8 |- ! 3 bits ! 1 bit ! 2 bits ! 1 bit ! 1 bit ! 2 bytes ! 1 byte ! 4 bytes |- | ccs=1 | reserved(=0) | n | e | s | index | subindex | data |} * '''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, 4 for aborting an SDO transfer, 5 for SDO block upload and 6 for SDO block download * '''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 data size is specified in n (if e is set) or in the data part of the message * '''index''' is the object dictionary index of the data to be accessed * '''subindex''' is the subindex of the object dictionary 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 {{anchor|pdo}} ==== The Process Data Object protocol is used to process real time data among various nodes. You can transfer up to 8 bytes (64 bits) of data per one PDO either from or to the device. One PDO can contain multiple object dictionary entries and the objects within one PDO are configurable using the mapping and parameter object dictionary entries. There are two kinds of PDOs: transmit and receive PDOs (TPDO and RPDO). The former is for data coming from the device (the device is a data producer) and the latter is for data going to the device (the device is a data consumer); that is, with RPDO you can send data to the device and with TPDO you can read data from the device. In the pre-defined connection set there are identifiers for four (4) TPDOs and four (4) RPDOs available. With configuration 512 PDOs are possible. PDOs can be sent 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 an empty TPDO with the 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 devices and make sure those RPDOs are mapped with the same COB-ID. ====Synchronization 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 a time as a 6-byte field: a count of milliseconds after midnight (at most 27 bits, stored in a 32-bit field), and an unsigned 16-bit number of days since January 1, 1984. (This will overflow on 7 June 2163.) 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 timestamp message to adjust the inevitable drift of the local clocks. The high-resolution timestamp 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 two pressure transducer slaves configured for id 1 and node&nbsp;ID 2. {| class="wikitable" |- ! CAN ID ! DATA LENGTH ! DATA ! Description |- | 0x0 | 2 | 01 00 | Master puts all devices on the bus into operational mode |- | 0x80 | 0 | | Master sends a SYNC message, which triggers devices to send data |- | 0x181 | 4 | CD 82 01 00 | Node at ID 1 (CID-0x180), reading pressure of 0x0182CD (99021) [[pascal (unit)|pascals]] |- | 0x182 | 4 | E5 83 01 00 | Node at ID 2 (CID-0x180), reading pressure of 0x0183E5 (99301) pascals |} ==Electronic Data Sheet== Electronic Data Sheet (EDS) is a file format, defined in CiA306, that describes the communication behaviour and the object dictionary entries of a device. This allows tools such as service tools, configuration tools, development tools, and others to handle the devices properly. Those EDS files are mandatory for passing the CiA CANopen conformance test. A free EDS checker is [https://canopen-forum.com/ CANchkEDS]. Since end of 2007 a new [[XML]] based format called XDD is defined in CiA311. XDD is conformant to [[International Organization for Standardization|ISO]] standard 15745. ==Glossary of CANopen terms== *'''PDO''': Process Data Object - Inputs and outputs. Values of type rotational speed, voltage, frequency, electric current, etc. *'''SDO''': Service Data Object - Configuration settings, possibly node&nbsp;ID, baud rate, offset, gain, etc. *'''COB-ID''': Communication object identifier *'''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 or XML style formatted file. *'''DCF''': Device Configuration File. This is a modified EDS file with settings for node&nbsp;ID and baud rate. ==See also== * [[CAN bus|Controller area network]] is an article on the CAN bus. * [[J1939]] * [[DeviceNet]] * [[IEEE 1451]] * [[TransducerML]] ==References== #{{Note|CiA301}} CiA 301 CANopen application layer specification, free downloadable from [http://www.can-cia.org CAN in Automation] #{{Note|CiA306}} CiA 306 CANopen Electronic Data Sheet (EDS) specification #{{Note|CiA311}} CiA 311 CANopen XML-EDS specification #{{Note|CiA401}} CiA 401 CANopen device profile specification for generic I/O modules, free downloadable from [http://www.can-cia.org CAN in Automation] #{{Note|CiA402}} CiA 402 CANopen device profile for motion controllers and drives (same as IEC 61800-7-201/301) <!-- How to add a footnote: NOTE: Footnotes in this article use names, not numbers. Please see [[Wikipedia:Footnotes]] for details. 1) Assign your footnote a unique name, for example TheSun_Dec9. 2) Add the macro {{ref|TheSun_Dec9}} to the body of the article, where you want the new footnote. 3) Take note of the name of the footnote that immediately precedes yours in the article body. 4) Add #{{Note|TheSun_Dec9}} to the list, immediately below the footnote you noted in step 3. No need to re-number anything! 5) Multiple footnotes to the same reference: see [[Wikipedia:Footnotes]] for a how-to. NOTE: It is important to add footnotes in the right order in the list! --> ==External links== *[http://www.can-cia.org/can-knowledge/canopen/canopen-history/ CANopen Origins - Esprit project ASPIC 1993 (Bosch, Newcastle University, University of Applied Science in Reutlingen)] *[http://www.canopensolutions.com/english/about_canopen/about_canopen.shtml About CANopen (canopensolutions.com)] *[http://www.microcontrol.net/download/appnotes/td-03011e.pdf Identifier usage in CANopen networks] *[http://www.canfestival.org/ CanFestival - An open source CANopen multiplatform framework] *[http://sourceforge.net/projects/canopennode/ CanOpenNode - An open source CANopen framework for microcontrollers] *[https://gitlab.com/lely_industries/co Lely CANopen library - An open source CANopen library for masters and slaves] *[https://github.com/marel-keytech/openCANopen openCANopen - An open source CANopen master] *[http://www.industrialcontroldesignline.com/showArticle.jhtml?articleID=192200423 CANopen: An Introduction] *[http://www.cia-productguides.org CANnewsletter-Information on CAN, CANopen and J1939] *[http://www.softing.com/home/en/industrial-automation/products/can-bus/more-can-open/communication/reference-model.php CANopen educational pages] *[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] *[http://canopen-solutions.com/canopen_caneds_en.html CANeds: Free editor EDA and XDD files] *[http://www.thaiio.com/CANinfo.html CAN Informations for industry] *[http://www.can-newsletter.org/ Online portal by CAN in Automation] [[Category:Network protocols]] [[Category:Industrial automation]]'
New page wikitext, after the edit (new_wikitext)
''''CANopen''' is a communication [[Protocol (computing)|protocol]] and device profile specification for [[embedded system]]s 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 layer|data link]] and [[physical layer]]s is usually [[CAN bus|Controller Area Network]] (CAN), although devices using some other means of communication (such as [[Ethernet Powerlink]], [[EtherCAT]]) can also implement the CANopen device profile. The basic CANopen device and communication profiles are given in the CiA 301 specification released by [[CAN in Automation]].{{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 CiA 401{{ref|CiA401}} for I/O-modules and CiA 402{{ref|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 [[Finite-state machine |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 dictionary and the data are sent and received through the communication layer. ===Object dictionary=== CANopen devices must have an object dictionary, which is used for configuration and 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''' (Object Type/Size), a symbolic type of the object in the entry, such as an array, record, or simple variable * '''Name''', a string describing the entry * '''Type''', gives the datatype of the variable (or the datatype of all variables of an array) * '''Attribute''', which gives information on the access rights for this entry, this can be read/write, read-only or write-only * The '''Mandatory/Optional''' field (M/O) defines whether a device conforming to the device specification has to implement this object or not The basic [[datatype]]s for object dictionary values such as [[Boolean data type|booleans]], [[Integer (computer science)|integers]] and [[Floating point|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 datatypes such as strings, arrays and records (defined in index range 0x0040–0x025F). 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 CiA 301{{ref|CiA301}} are mapped in the index range 0x1000–0x1FFF ("communication profile area"). The first few entries in this area are as follows: {| class="wikitable" |- ! Index ! Object name ! Name ! Type ! Attribute ! M/O |- | 0x1000 | VAR | device type | UNSIGNED32 | ro | M |- | 0x1001 | VAR | error register | UNSIGNED8 | ro | M |- | ... | | | | | |- | 0x1008 | VAR | manufacturer device name | Vis-String | const | O |- | ... | | | | | |} Given suitable tools, the content of the object dictionary of a device, based on an electronic data sheet (EDS), can be customized to a device configuration file (DCF) to integrate the device into a specific CANopen network. According to CiA 306{{ref|CiA306}}, the format of the EDS-file is the [[INI file]] format. There is an upcoming XML-style format, that is described in CiA 311{{ref|CiA311}}. ==Communication== ===Communication objects=== [[CAN bus]], the data link layer of CANopen, can only transmit short packages consisting of an 11-bit id, a remote transmission request (RTR) bit and 0 to 8 bytes of data. The CANopen standard divides the 11-bit CAN frame id into a 4-bit function code and 7-bit CANopen node&nbsp;ID. This limits the number of devices in a CANopen network to 127 (0 being reserved for broadcast). An extension to the CAN bus standard (CAN 2.0 B) allows extended frame ids of 29 bits, but in practice CANopen networks big enough to need the extended id range are rarely seen. In CANopen the 11-bit id of a CAN-frame is known as communication object identifier, or 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. Using a low code number for time critical functions ensures the lowest possible delay. Contents of an 11-bit CANopen frame: {| class="wikitable" |- ! ! CAN-ID ! RTR ! Data length ! Data |- ! Length | 11 bits | 1 bit | 4 bits | 0-8 bytes |} The data frame with an 11-bit identifier is also called "base frame format". The default CAN-ID mapping sorts frames by attributing a function code (NMT, SYNC, EMCY, PDO, SDO...) to the first 4 bits, so that critical functions are given priority. This mapping can however be customized for special purposes (except for NMT and SDO, required for basic communication). {| class="wikitable" |- ! ! Function code ! Node&nbsp;ID |- ! Length | 4 bits | 7 bits |} The standard reserves certain CAN-IDs to network management and SDO transfers. Some function codes and CAN-IDs have to be mapped to standard functionality after device initialization, but can be configured for other uses later. ==== Predefined Connection Set{{ref|PredefinedConnectionSet}} ==== For simple network structures, CANopen supports a predefined allocation of message identifiers. {| class="wikitable" |- ! Communication object !! COB-ID(s) hex !! Slave nodes |- | NMT node control || 000 || Receive only |- | Sync || 080 || Receive only |- | Emergency || 080 + NodeID || Transmit |- | TimeStamp || 100 || Receive only |- | PDO || 180 + NodeID<br />200 + NodeID<br />280 + NodeID<br />300 + NodeID<br />380 + NodeID<br />400 + NodeID<br />480 + NodeID<br />500 + NodeID || 1. Transmit PDO<br />1. Receive PDO<br />2. Transmit PDO<br />2. Receive PDO<br />3. Transmit PDO<br />3. Receive PDO<br />4. Transmit PDO<br />4. Receive PDO |- | SDO || 580 + NodeID<br />600 + NodeID || Transmit<br />Receive |- | NMT node monitoring (node guarding/heartbeat) || 700 + NodeID || Transmit |- | LSS || 7E4<br />7E5 || Transmit<br />Receive |} ===Communication models=== Different kinds of communication models are used in the messaging between CANopen nodes. In a '''master/slave''' relationship, one CANopen node is designated as the master, which sends or requests data from the slaves. The NMT protocol is an example of a master/slave communication model. A '''client/server''' relationship is implemented in the SDO protocol, where the SDO client sends data (the object dictionary index and subindex) to an SDO server, which replies with one or more SDO packages containing the requested data (the contents of the object dictionary at the given index). A '''producer/consumer''' model is used in the Heartbeat and Node Guarding protocols. In the ''push-model'' of producer/consumer, the producer sends data to the consumer without a specific request, whereas in the ''pull model'', the consumer has to request the data from the producer. ===Protocols=== ====Network management (NMT) protocols==== The NMT protocols are used to issue state machine change commands (e.g. to start and stop the devices), detect remote device bootups and error conditions. The '''Module control protocol''' is used by the NMT master to change the state of the devices. The CAN-frame COB-ID of this protocol is always 0, meaning that it has a function code 0 and node&nbsp;ID 0, which means that every node in the network will process this message. The actual node&nbsp;ID, to which the command is meant to, is given in the data part of the message (at the second byte). This can also be 0, meaning that all the devices on the bus should go to the indicated state. {| class="wikitable" |- ! COB-ID !! Data Byte 0 !! Data Byte 1 |- | 0x000 || Requested state || Addressed node |} {| class="wikitable" |- ! NMT command code !! Meaning |- | 0x01 || Go to 'operational' |- | 0x02 || Go to 'stopped' |- | 0x80 || Go to 'pre-operational' |- | 0x81 || Go to 'reset node' |- | 0x82 || Go to 'reset communication' |} The '''Heartbeat protocol''' is used to monitor the nodes in the network and verify that they are alive. A heartbeat producer (usually a slave device) periodically sends a message with the binary function code of 1110 and its node&nbsp;ID (COB-ID = 0x700 + node&nbsp;ID). The data part of the frame contains a byte indicating the node status. The heartbeat consumer reads these messages. If the messages fail to arrive within a certain time limit (defined in the object dictionary of the devices) the consumer can take action to, for example, reset the device or indicate an error. The frame format is: {| class="wikitable" |- ! COB-ID !! Data Byte 0 |- | 0x700 + node&nbsp;ID || State |} {| class="wikitable" |- ! NMT state code !! Represented state |- | 0x00 || Boot up (Initialising) |- | 0x04 || Stopped |- | 0x05 || Operational |- | 0x7f || Pre-operational |} CANopen devices are required to make the transition from the state Initializing to Pre-operational automatically during bootup. When this transition is made, a single heartbeat message is sent to the bus. This is the '''bootup protocol'''. A response/reply-style (pull model) protocol, called node guarding, exists for slave monitoring. ====Service Data Object (SDO) protocol==== {{distinguish|text=[[Service Data Objects]], a data-as-a-service abstraction}} The SDO protocol is used for setting and for reading values from the object dictionary of a remote device. The device whose object dictionary is accessed is the SDO server and the device accessing the remote device is the SDO client. The communication is always initiated by the SDO client. In CANopen terminology, communication is viewed from the SDO server, so that a read from an object dictionary results in an SDO upload and a write to a dictionary entry is an SDO download. Because the object dictionary values can be larger than the eight bytes limit of a CAN frame, the SDO protocol implements segmentation and desegmentation of longer messages. Actually, there are two of these protocols: SDO download/upload and SDO Block download/upload. The SDO block transfer is a newer addition to standard, which allows large amounts of data to be transferred with slightly less protocol overhead. The COB-IDs of the respective SDO transfer messages from client to server and server to client can be set in the object dictionary. Up to 128 SDO servers can be set up in the object dictionary at addresses 0x1200 - 0x127F. Similarly, the SDO client connections of the device can be configured with variables at 0x1280 - 0x12FF. However the ''pre-defined connection set'' defines an SDO channel which can be used even just after bootup (in the Pre-operational state) to configure the device. The COB-IDs of this channel are 0x600 + node&nbsp;ID for receiving and 0x580 + node&nbsp;ID for transmitting. To initiate a download, the SDO client sends the following data in a CAN message with the 'receive' COB-ID of the SDO channel. {| class="wikitable" |- ! colspan="5" | Byte 1 ! Byte 2-3 ! Byte 4 ! Byte 5-8 |- ! 3 bits ! 1 bit ! 2 bits ! 1 bit ! 1 bit ! 2 bytes ! 1 byte ! 4 bytes |- | ccs=1 | reserved(=0) | n | e | s | index | subindex | data |} * '''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, 4 for aborting an SDO transfer, 5 for SDO block upload and 6 for SDO block download * '''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 data size is specified in n (if e is set) or in the data part of the message * '''index''' is the object dictionary index of the data to be accessed * '''subindex''' is the subindex of the object dictionary 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 {{anchor|pdo}} ==== The Process Data Object protocol is used to process real time data among various nodes. You can transfer up to 8 bytes (64 bits) of data per one PDO either from or to the device. One PDO can contain multiple object dictionary entries and the objects within one PDO are configurable using the mapping and parameter object dictionary entries. There are two kinds of PDOs: transmit and receive PDOs (TPDO and RPDO). The former is for data coming from the device (the device is a data producer) and the latter is for data going to the device (the device is a data consumer); that is, with RPDO you can send data to the device and with TPDO you can read data from the device. In the pre-defined connection set there are identifiers for four (4) TPDOs and four (4) RPDOs available. With configuration 512 PDOs are possible. PDOs can be sent 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 an empty TPDO with the 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 devices and make sure those RPDOs are mapped with the same COB-ID. ====Synchronization 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 a time as a 6-byte field: a count of milliseconds after midnight (at most 27 bits, stored in a 32-bit field), and an unsigned 16-bit number of days since January 1, 1984. (This will overflow on 7 June 2163.) 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 timestamp message to adjust the inevitable drift of the local clocks. The high-resolution timestamp 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 two pressure transducer slaves configured for id 1 and node&nbsp;ID 2. {| class="wikitable" |- ! CAN ID ! DATA LENGTH ! DATA ! Description |- | 0x0 | 2 | 01 00 | Master puts all devices on the bus into operational mode |- | 0x80 | 0 | | Master sends a SYNC message, which triggers devices to send data |- | 0x181 | 4 | CD 82 01 00 | Node at ID 1 (CID-0x180), reading pressure of 0x0182CD (99021) [[pascal (unit)|pascals]] |- | 0x182 | 4 | E5 83 01 00 | Node at ID 2 (CID-0x180), reading pressure of 0x0183E5 (99301) pascals |} ==Electronic Data Sheet== Electronic Data Sheet (EDS) is a file format, defined in CiA306, that describes the communication behaviour and the object dictionary entries of a device. This allows tools such as service tools, configuration tools, development tools, and others to handle the devices properly. Those EDS files are mandatory for passing the CiA CANopen conformance test. A free EDS checker is [https://canopen-forum.com/ CANchkEDS]. Since end of 2007 a new [[XML]] based format called XDD is defined in CiA311. XDD is conformant to [[International Organization for Standardization|ISO]] standard 15745. ==Glossary of CANopen terms== *'''PDO''': Process Data Object - Inputs and outputs. Values of type rotational speed, voltage, frequency, electric current, etc. *'''SDO''': Service Data Object - Configuration settings, possibly node&nbsp;ID, baud rate, offset, gain, etc. *'''COB-ID''': Communication object identifier *'''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 or XML style formatted file. *'''DCF''': Device Configuration File. This is a modified EDS file with settings for node&nbsp;ID and baud rate. ==See also== * [[CAN bus|Controller area network]] is an article on the CAN bus. * [[J1939]] * [[DeviceNet]] * [[IEEE 1451]] * [[TransducerML]] ==References== #{{Note|CiA301}} CiA 301 CANopen application layer specification, free downloadable from [http://www.can-cia.org CAN in Automation] #{{Note|CiA306}} CiA 306 CANopen Electronic Data Sheet (EDS) specification #{{Note|CiA311}} CiA 311 CANopen XML-EDS specification #{{Note|PredefinedConnectionSet}} Predefined Connection Set from CANopen Basics [http://www.canopensolutions.com/english/about_canopen/predefined.shtml] #{{Note|CiA401}} CiA 401 CANopen device profile specification for generic I/O modules, free downloadable from [http://www.can-cia.org CAN in Automation] #{{Note|CiA402}} CiA 402 CANopen device profile for motion controllers and drives (same as IEC 61800-7-201/301) <!-- How to add a footnote: NOTE: Footnotes in this article use names, not numbers. Please see [[Wikipedia:Footnotes]] for details. 1) Assign your footnote a unique name, for example TheSun_Dec9. 2) Add the macro {{ref|TheSun_Dec9}} to the body of the article, where you want the new footnote. 3) Take note of the name of the footnote that immediately precedes yours in the article body. 4) Add #{{Note|TheSun_Dec9}} to the list, immediately below the footnote you noted in step 3. No need to re-number anything! 5) Multiple footnotes to the same reference: see [[Wikipedia:Footnotes]] for a how-to. NOTE: It is important to add footnotes in the right order in the list! --> ==External links== *[http://www.can-cia.org/can-knowledge/canopen/canopen-history/ CANopen Origins - Esprit project ASPIC 1993 (Bosch, Newcastle University, University of Applied Science in Reutlingen)] *[http://www.canopensolutions.com/english/about_canopen/about_canopen.shtml About CANopen (canopensolutions.com)] *[http://www.microcontrol.net/download/appnotes/td-03011e.pdf Identifier usage in CANopen networks] *[http://www.canfestival.org/ CanFestival - An open source CANopen multiplatform framework] *[http://sourceforge.net/projects/canopennode/ CanOpenNode - An open source CANopen framework for microcontrollers] *[https://gitlab.com/lely_industries/co Lely CANopen library - An open source CANopen library for masters and slaves] *[https://github.com/marel-keytech/openCANopen openCANopen - An open source CANopen master] *[http://www.industrialcontroldesignline.com/showArticle.jhtml?articleID=192200423 CANopen: An Introduction] *[http://www.cia-productguides.org CANnewsletter-Information on CAN, CANopen and J1939] *[http://www.softing.com/home/en/industrial-automation/products/can-bus/more-can-open/communication/reference-model.php CANopen educational pages] *[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] *[http://canopen-solutions.com/canopen_caneds_en.html CANeds: Free editor EDA and XDD files] *[http://www.thaiio.com/CANinfo.html CAN Informations for industry] *[http://www.can-newsletter.org/ Online portal by CAN in Automation] [[Category:Network protocols]] [[Category:Industrial automation]]'
Whether or not the change was made through a Tor exit node (tor_exit_node)
false
Unix timestamp of change (timestamp)
1534417891