CANopen
维基百科，自由的百科全书
CANopen是一種架構在控制區域網路(Control Area Network, CAN)上的高層通訊協定，包括通訊子協定及設備子協定，常在嵌入式系統及工業控制中使用。
CANopen 實作了OSI模型中的網路層以上（包括網路層）的協定。CANopen 標準包括定址方案、數個小的通訊子協定及由設備子協定所定義的應用層。 CANopen 支援網路管理、設備監控及節點間的通訊，其中包括一個簡易的傳輸層，可處理資料的分段傳送及其組合。一般而言資料鏈結層及實體層會用CAN來實作。除了 CANopen 外，也有其他的通訊協定(如EtherCAT)實作 CANopen 的設備子協定。
基本的 CANopen 設備及通訊子協定定義在 CAN in Automation (CiA) draft standard 301. 中。針對個別設備的子協定以 CiA 301 為基礎再進行擴充。如針對 I/O 模組的 CiA401 及針對運動控制的 CiA402。
目录 |
[编辑] 設備模型
以下是所有 CANopen 設備都要具備的功能：
- 通訊單元 處理和網路上其他模組通訊所需要的通訊協定。
- 設備的啟動及重置由狀態機 (state machine)控制。狀態機需包括以下的幾個狀態：Initialization, Pre-operational, Operational 及 Stopped。當接收到網路管理 (NMT) 通訊物件，狀態機會轉換到對應的狀態。
- 物件字典 (Object Dictionary) 是一個有 16 位元索引 (Index) 的變數陣列。每個變數可以（但非必須）有 8 位元的子索引 (Subindex)。變數可用來調整設備的組態，也可以對應設備量測的資料或設備的輸出。
- 當狀態機設定為 operational 之後，設備的應用 (application) 部份就會實現設備預期的機能。此部份可以由物件字典中的變數調整其設定，而資料由通訊層傳收或接收。
[编辑] 物件字典
CANopen 設備都需要具備物件字典，用來設定設備組態及進行非即時的通訊。物件字典的entry 定義如下：
- 索引 (Index)：物件 16 位元的位址。
- 物件名稱 (Object name)：一個代表物件的 symbolic type，可以是陣列、紀錄或只是一個變數。
- 名稱 (Name)：描述此 entry 的字串。
- 形態 (Type)：變數的資料形態。
- 屬性 (Attribute)：提供此 entry 是否可讀/可寫的資料，有下列四種： be read/write, read-only, write-only, 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 DS301 are mapped in the index range 0x1000 - 0x1FFF ("communication profile area"). The first few entries in this area are as follows:
| 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 object dictionary of a device can be configured by editing an electronic data sheet (EDS) file and uploading the variable values to the device. The format of the EDS-file is usually INI file.
[编辑] 通訊
[编辑] 通訊物件
CANbus, the physical layer of CANopen, can only transmit short packages consisting of an 11-bit id, remote transmission request (RTR) bit and a 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 id. This limits the number of devices in a CANopen network to 127. An extension to the CANbus 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 CANbus allows the frame with the smallest id to be transmitted first and without a delay. Since in CANopen frames the first 4 bits of the frame id are reserved to the function code, giving a low code number for time critical functions ensures the lowest possible delay.
Contents of a standard CANopen frame:
| Function code | Node ID | RTR | Data length | Data | |
|---|---|---|---|---|---|
| Length | 4 bits | 7 bits | 1 bit | 4 bits | 0-8 bytes |
The standard reserves certain COB-IDs to network management and SDO transfers. Some function codes and COB-IDs have to be mapped to standard functionality after device initialization, but can be configured for other uses later.
[编辑] 通訊模型
CANopen 設備間的通訊可分為以下三種通訊模型。
- 在 master/slave 模型中，一個 CANopen 設備為 master，負責傳送或接收其他設備（稱為 slave）的資料。NMT 協定就使用了 master/slave 模型。
- 主從（client/server) 模型定義在 SDO 協定中，SDO client 將物件字典的索引及子索引傳送給 SDO server，因此會產生一個或數個需求資料（物件字典中，索引及子索引對應的內容) 的 SDO 封包。
- 生產者/消費者（producer/consumer) 模型 用在 Heartbeat and Node Guarding 協定。由一個生產者送出資料給消息者，同一個生產者的資料可能給一個以上的消息者。又可分為二種：
- push-model：生產者會自動送出資料給消費者。
- pull-model：消費者需送出請求訊息，生產者才會送出資料。
[编辑] 協定
[编辑] NMT 協定
The NMT protocols are used to issue state machine change commands (ie. 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 id 0, which means that every node in the network will process this message. The actual node id, to which the command is meant to, is given in the data part of the message. This can also be 0, meaning that all the devices in the bus should go to the indicated state.
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 binary function code of 1110 and its node id (COB ID = 0x700 + node 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 directory of the devices) the consumer can take action to, for example, reset the device or indicate an error. Frame format is :
COBID + DATA(status of node)
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 for slave monitoring called Node guarding protocol exists.
[编辑] 服務資料物件 (SDO) 協定
The SDO (Service Data Object) protocol is used to set and read values from the object directory of a remote device. The device whose object directory 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 directory results in an SDO upload and a write to directory is an SDO download.
As the object directory values can be larger than the 8 byte 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 directory. Up to 127 SDO servers can be set up in the object directory 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 id for receiving and 0x580 + node 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:
| 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 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)
[编辑] 程序資料物件 (PDO) 協定
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.
[编辑] 同步 (SYNC) 協定
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) 協定
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.
[编辑] 緊急物件 (EMCY) 協定
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.
[编辑] 初始化
Sample trace of communications between a master and 2 pressure transducer slaves configured for id 1 and node id 2.
| CAN ID | DATA LENGTH | DATA | Description |
|---|---|---|---|
| 0x0 | 2 | 1 0 | Master puts 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) pascals |
| 0x182 | 4 | E5 83 01 00 | Node at ID 2 (CID-0x180), reading pressure of 0x0183E5(99301) pascals |
[编辑] CANopen 專有名詞
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 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 CANchkEDS
[编辑] 參照
[编辑] 參考文獻
- ^ CiA Draft Standard 301, available from CAN in Automation
- ^ CiA Draft Standard 401
- ^ CiA Draft Standard 402
[编辑] 外部連結
- CAN in Automation 的 CANopen 簡介
- CANopen 簡介 (www.esacademy.com)
- CANopen 的教學網頁 (softing.com)
- CANopen 開發資料 (canopendesign.com)
- CAN-wiki 中 CANopen 的頁面
- CANopen: An Introduction
- 關於 About CANopen (canopensolutions.com)
- CANopen-Lift 社群的 WIKI
- Introduction to CANopen 基礎介紹 (www.canopen-solutions.com)
- CanFestival - 一個開放源碼多平台 CANopen 的計劃
