CAN 知识杂记

CAN 知识杂记

Heartbeat是slave主动上报的0x05(operational),0x7f（pre-operational）
如果是Nodeguarding则是master发00，然后slave是0x05和0x85交替上报
start node是0x01

Node guarding:

NMT-Master=> NMT-Slave

COB-ID

0x700 + Node_ID

NMT-Master <= NMT-Slave
COB-ID	Byte 0
0x700 + Node_ID	bit 7:toggle, bit 6-0:state

Byte0包含一个toggle位（bit7），每一次Node Guard请求都会在0和1之间进行翻转（第一次值为0），翻转的目的是为了区分设备当前状态值和历史状态值；bit 6-0用来表示Slave的当前状态，有以下几种状态

Value	State
0	Initialising
1	Disconnected
2	Connecting
3	Preparing
4	Stopped
5	Operational
127	Pre-operational

Note: 状态0永远不会出现在Node Guarding的reply里，因为在Initialising状态下，不会对Node Guarding请求做出响应。

=================================

Node guarding是master往0x738也就是OTS logic板发0，然后逻辑板返回0x05下次返回0x85,OTS上的两个amp的node id是05和09，目前设计是单向guarding,也就是从节点不guarding主节点

wallstand上的amp的node id是0xf也就是0x70f,而其逻辑板的nodeid为0x34，table的逻辑板nodeid为0x42

CAN的总线上，是没有主次节点之说的，消息是广播式的，不会有重发的，除非软件自己实现，也就是说，一个节点在仲裁到总线后，也就是按照ID号越小优先级越高的机制，发送消息的时候，其他节点都处于监听状态，并都可以决定是否接收该消息，如果接收到了，那么会发送一个ACK给发送节点确认，如果多个节点收到了，那么是没有办法确定是哪个节点发送确认了，或者没有发送确认的，按照can协议来说是肯定有确认消息的，主节点也不知道是谁发送的确认消息，如果没有确认消息，会报错的。所以在一个CAN的系统里，把canalyzer接入系统，trace总线的message,可以监听到所有CAN总线上的消息，每条消息理论上就是消息发送出来的时间，因为光速的延迟可以忽略了。所以如出现两条消息间隔时间不稳定，应该是发送端的问题。

关于CANOPEN协议栈：
1, SDO是协议栈自己处理的，我们不做控制
2，PDO,
TPDO是我们主动上报的，原则是当某个对象的某一个bit发生了改变，就可以上报
RPDO是我们接收的，一般是有一个线程专门处理RPDO，当我们收到RPDO的时候，转到相应的处理函数进行处理

ALB板上用的can协议栈是德国思泰的，Peafowl板上用的是德国EMTAS的，EMTAS更复杂一些，功能也功能，但是处理机制
不太一样，尤其是对TPDO的处理，EMTAS有单独的接口可以调用，根据TPDO的号由用户决定是否上报，而思泰的协议栈是栈里面
自动处理的，只要那个对象的某一个bit位发生变化就上报。
---------------------------------------------------------

CAN in Automation (CiA) draft standard 301

针对个别设备的子协定以 CiA 301 为基础再进行扩充，如针对 I/O 模组的 CiA401 及针对运动控制的 CiA402。

DS(Draft Standard)-标准级行规，最稳定
DSP(Draft Standard) - 专用设备行规
DR(Draft Recommandation)
TR(Tenical Report)
    
   DS401 - 通用I/O口模块
   DS402 - 运动控制
   DS404 - 测量与闭环控制
   DS405 - 可编程控制
   DS406 - 编码器

对象字典就相当于菜单（OD），比如你去饭店吃饭，看到有好多菜（OD中的对象），菜前面都编着号（索引），然后有一些还会让你选甜口还是咸口，微辣还是加辣，也编着小号（子索引），你选择困难，觉得自己点太麻烦，又看到有套餐（PDO），套餐包含的样式有限（64bit），然后你告诉服务员，我要套餐A（已经映射好OD中的对象的PDO），服务员听到后（PDO发送成功），不一会一下上来好几个菜。

1, CANOPEN DS301是CANopen协议中的通讯子协议（Communication Profile），通讯子协议描述对象字典的主要形式和对象字典中的通讯子协议区域中的对象，通讯参数，同时描述CANopen通讯对象，这个子协议适用于所有的CANopen设备。
2, CANOPEN DS402是CANopen协议中的设备子协议（Device Profile），设备子协议为各种不同类型设备定义对象字典中的对象，并为对象字典中的每个对象描述了它的功能、名字、索引和子索引、数据类型，以及这个对象是必需的还是可选的，这个对象是只读、只写或者可读写等等。目前已有多种不同的设备子协议。

含以下CANopen 协议及子协议,请选择 DS301 规范了对应用层、通信子协议进行了全面描述外，还为特定的应用提供了扩展架构，定义了更多规则和特殊通信对象。例如：定义 了网络管理对象（节点保护，寿命保护），并定义了使用这些对象的详细规则，是包含
通信接口、应用过程以及对象字典的CANopen设备的基本 模型 DS301    
应用层 DS302    
CANopen 管理结构与可编程驱动器 DS303    1接线接头说明,2国际单位的表示和前缀,3指示灯说明(1,2,3) DS304    网络安全结构及相关说明 DS305    无 DS306    EDS电子数据表说明 DS308 性能测量说明 DS309 TCPIP(1,2,3) 1-通用原则与服务 2-Modbus/TCP 影射 3-ASCII码影射 EDS    文件规范 设备子协议: 通常命名编号为DS4XX 
DS401 通用IO模块 
DS402    电机驱动器 
DS404    闭环测控仪器 
DS405 可编程设备 
DS406    旋转与线性编码器 
DS408    无 
DS410 角度测量仪 
DS412    医疗器械(1,2,6),1--通用定义,2---X光准直仪,3--x光发生器,4--疾人表配置,5--X光标准,6--剂量测量系统 
DS414    织布机驱动(1,2) 1--通用定义 2--馈线 
DS417    升降控制器 
DS418    电池驱动模块 
DS419    电池充电器 
DS420    挤压设备(1,2,3,4,5,6) 
DS422    市政车辆 
DS801    CANopen Automactic bit-rate detection 
DS802    CANopen CAN remote frames 远程帧-避免使用 
DS808 CANopen CiA 444 应用注释和实施指南 CANopen CiA 444 application note and implementation guideline DS201207 DSV1.1 工业应用的应用层

----------------------------------------------------------
SDO
Each amplifier provides one SDO. The CANopen master can use this SDO to configure, monitor, and control the device by reading from and writing to its object dictionary.
SDO CAN Message IDs
The SDO protocol uses two CAN message identifiers. One ID is used for messages sent from the CANopen master (SDO client) to the amplifier (SDO server). The other ID is used for messages sent from the SDO server to the SDO client.
The CAN message ID numbers for these two messages are fixed by the CANopen protocol. They are based on the device's node ID (which ranges from 1 to 127). The ID used for messages from the SDO client to the SDO server (i.e. from the CANopen master to the amplifier) is the hex value 0x600 + the node ID. The message from the SDO server to the SDO client is 0x580 + the node ID. For example, an amplifier with node ID 7 uses CAN message IDs 0x587 and 0x607 for its SDO protocol.
Table                                    
                                    
SDOs
0x580+ nodeid 和0x600+nodeid
                                    
COB-ID    Function                                
5C2    SDO Transmit (Response)                                
642    SDO Receive (Request)                                
                                    
Emergency Message                                    
COB-ID    Subindex    Mapping    Type    Name        Notes            
C2    1-2    1003.1    U16    Error Code        Contains the most recent error code.            
C2    3    1001    U8    Error Register        Each bit represents an error class.            
C2    4-8    2006.1-5    U8    Error Latch        Actual object value for error reporting.            
                                    
                                    
Wallstand                                    
                                    
SDOs                                    
COB-ID    Function                                
5B4    SDO Transmit (Response)                                
634    SDO Receive (Request)                                
                                    
Emergency Message                                    
COB-ID    Subindex    Mapping    Type    Name        Notes            
B4    1-2    1003.1    U16    Error Code        Contains the most recent error code.            
B4    3    1001    U8    Error Register        Each bit represents an error class.            
B4    4-8    2006.1-5    U8    Error Latch        Actual object value for error reporting.            
                                    
                                    
OTS                                    
                                    
SDOs                                    
COB-ID    Function                                
5B8    SDO Transmit (Response)                                
638    SDO Receive (Request)                                
                                    
Emergency Message                                    
COB-ID    Subindex    Mapping    Type    Name        Notes            
B8    1-2    1003.1    U16    Error Code        Contains the most recent error code.            
B8    3    1001    U8    Error Register        Each bit represents an error class.            
B8    4-8    2006.1-5    U8    Error Latch        Actual object value for error reporting.            

0x80+nodeid 是emergency message
------------------------------------------------------------------------

CANopen协议介绍
流行欧洲的CAN-bus高层协议

1、介绍
从OSI网络模型的角度来看同，现场总线网络一般只实现了第1层（物理层）、第2层（数据链路层）、第7层（应用层）。因为现场总线通常只包括一个网段，因此不需要第3层（传输层）和第4层（网络层），也不需要第5层（会话层）第6层（描述层）的作用。
CAN（ControllerAreaNetwork）现场总线仅仅定义了第1层、第2层（见ISO11898标准）；实际设计中，这两层完全由硬件实现，设计人员无需再为此开发相关软件（Software）或固件（Firmware）。
同时，CAN只定义物理层和数据链路层，没有规定应用层，本身并不完整，需要一个高层协议来定义CAN报文中的11/29位标识符、8字节数据的使用。而且，基于CAN总线的工业自动化应用中，越来越需要一个开放的、标准化的高层协议：这个协议支持各种CAN厂商设备的互用性、互换性，能够实现在CAN网络中提供标准的、统一的系统通讯模式，提供设备功能描述方式，执行网络管理功能。

应用层（Applicationlayer）：为网络中每一个有效设备都能够提供一组有用的服务与协议。
通讯描述（Communicationprofile）：提供配置设备、通讯数据的含义，定义数据通讯方式。
设备描述（Deviceproflile）：为设备（类）增加符合规范的行为。

下面的章节将介绍基于CAN的高层协议：CAL协议和基于CAL协议扩展的CANopen协议。CANopen协议是CAN-in- Automation(CiA)定义的标准之一，并且在发布后不久就获得了广泛的承认。尤其是在欧洲，CANopen协议被认为是在基于CAN的工业系统中占领导地位的标准。大多数重要的设备类型，例如数字和模拟的输入输出模块、驱动设备、操作设备、控制器、可编程控制器或编码器，都在称为“设备描述”的协议中进行描述；“设备描述”定义了不同类型的标准设备及其相应的功能。依靠CANopen协议的支持，可以对不同厂商的设备通过总线进行配置

2、CAL协议
CAL（CANApplicationLayer）协议是目前基于CAN的高层通讯协议中的一种，最早由Philips医疗设备部门制定。现在CAL由独立的CAN用户和制造商集团CiA（CANinAutomation）协会负责管理、发展和推广。
CAL提供了4种应用层服务功能：
CMS(CAN-basedMessageSpecification)
CMS提供了一个开放的、面向对象的环境，用于实现用户的应用。CMS提供基于变量、事件、域类型的对象，以设计和规定一个设备（节点）的功能如何被访问（例如，如何上载下载超过8字节的一组数据（域），并且有终止传输的功能）。
CMS从MMS(ManufacturingMessageSpecification)继承而来。MMS是OSI为工业设备的远程控制和监控而制定的应用层规范。
NMT(NetworkManagemenT)
提供网络管理（如初始化、启动和停止节点，侦测失效节点）服务。这种服务是采用主从通讯模式（所以只有一个NMT主节点）来实现的。
DBT(DistriBuTor)
提供动态分配CANID（正式名称为COB-ID，CommunicationObjectIdentifier）服务。这种服务是采用主从通讯模式（所以只有一个DBT主节点）来实现的。
LMT(LayerManagemenT)
LMT提供修改层参数的服务：一个节点（LMTMaster）可以设置另外一个节点（LMTSlave）的某层参数（如改变一个节点的NMT地址，或改变CAN接口的位定时和波特率）。
CMS为它的消息定义了8个优先级，每个优先级拥有220个COB-ID，范围从1到1760。剩余的标志（0，1761-2031）保留给NMT，DBT和LMT，见表2-1。
表2-1映射到CAL服务和对象的COB-ID(11位CAN标识符)
COB-ID
服务或对象
0
NMT启动/停止服务
1-220            CMS对象优先级0
221-440        CMS对象优先级1
441-660        CMS对象优先级2
661-880        CMS对象优先级3
881-1100      CMS对象优先级4

1101-1320        CMS对象优先级5
1321-1540       CMS对象优先级6
1541-1760       CMS对象优先级7
1761-2015       NMT节点保护
2016-2031       NMT，LMT，DBT服务
注意这是CAN2.0A标准，11位ID范围[0，2047]，由于历史原因限制在[0，2031]。如果使用CAN2.0B标准，29位ID并不改变这个描述；表中的11位映射到29位COB-ID中的最高11位，以至于表中的COB-ID范围变得增大许多。
3、CANopen
CAL提供了所有的网络管理服务和报文传送协议，但并没有定义CMS对象的内容或者正在通讯的对象的类型（它只定义了how，没有定义what）。而这正是CANopen切入点。
CANopen是在CAL基础上开发的，使用了CAL通讯和服务协议子集，提供了分布式控制系统的一种实现方案。CANopen在保证网络节点互用性的同时允许节点的功能随意扩展：或简单或复杂。
CANopen的核心概念是设备对象字典（OD：ObjectDictionary），在其它现场总线（Profibus，Interbus-S）系统中也使用这种设备描述形式。注意：对象字典不是CAL的一部分，而是在CANopen中实现的。
下面先介绍对象字典（OD：ObjectDictionary），然后再介绍CANopen通讯机制。
3.1对象字典OD
对象字典（OD：ObjectDictionary）是一个有序的对象组；每个对象采用一个16位的索引值来寻址，为了允许访问数据结构中的单个元素，同时定义了一个8位的子索引，对象字典的结构参照表3-1。不要被对象字典中索引值低于0x0FFF的‘datatypes’项所迷惑，它们仅仅是一些数据类型定义。一个节点的对象字典的有关范围在0x1000到0x9FFF之间。
表3-1CANopen对象字典通用结构
索引/             对象
0000             Notused
0001-001F   静态数据类型（标准数据类型，如Boolean，Integer16）
0020-003F   复杂数据类型（预定义由简单类型组合成的结构如PDOCommPar，SDOParameter）
0040-005F   制造商规定的复杂数据类型
0060-007F   设备子协议规定的静态数据类型
0080-009F   设备子协议规定的复杂数据类型
00A0-0FFF   Reserved
1000-1FFF   通讯子协议区域(如设备类型，错误寄存器，支持的PDO数量)
2000-5FFF   制造商特定子协议区域
6000-9FFF   标准的设备子协议区域(例如“DSP-401I/O模块设备子协议”：ReadState8InputLines等)
A000-FFFF   Reserved
CANopen网络中每个节点都有一个对象字典。对象字典包含了描述这个设备和它的网络行为的所有参数。
一个节点的对象字典是在电子数据文档（EDS：ElectronicDataSheet）中描述或者记录在纸上。不必要也不需要通过CAN-bus“审问” 一个节点的对象字典中的所有参数。如果一个节点严格按照在纸上的对象字典进行描述其行为，也是可以的。节点本身只需要能够提供对象字典中必需的对象（而在 CANopen规定中必需的项实际上是很少的），以及其它可选择的、构成节点部分可配置功能的对象。
CANopen由一系列称为子协议的文档组成。
通讯子协议（communicationprofile），描述对象字典的主要形式和对象字典中的通讯子协议区域中的对象，通讯参数。同时描述CANopen通讯对象。这个子协议适用于所有的CANopen设备。
还有各种设备子协议（deviceprofile），为各种不同类型设备定义对象字典中的对象。

目前已有5种不同的PDO触发模式
同步（通过接收SYNC对象实现同步）
非周期：由远程帧预触发传送，或者由设备子协议中规定的对象特定事件预触发传送。
周期：传送在每1到240个SYNC消息后触发。
异步
由远程帧触发传送。
由设备子协议中规定的对象特定事件触发传送。

表3-2给出来了由传输类型定义的不同PDO传输模式，传输类型为PDO通讯参数对象的一部分，由8位无符号整数定义。
表3-2PDO传输类型定义
触发PDO的条件     (B=both needed O=one or both)   

传输类型                0                          1-240             241-251               252                             253                                254      
SYNC                     B                              O                    -                         B                                  -                                     -
RTR                       -                               -                     -                         B                                 O                                   O
Event                     B                              -                      -                         -                                   -                                    O
PDO传输        同步，非循环          同步，循环       Reserved       同步，在RTR之后      异步，在RTR之后    异步，制造商特定事件

255
-
O
O
异步，设备子协议特定事件

说明：
SYNC–接收到SYNC-object。
RTR－接收到远程帧。
Event–例如数值改变或者定时器中断。
传输类型为：1到240时，该数字代表两个PDO之间的SYNC对象的数目）。
一个PDO可以指定一个禁止时间，即定义两个连续PDO传输的最小间隔时间，避免由于高优先级信息的数据量太大，始终占据总线，而使其它优先级较低的数据无力竞争总线的问题。禁止时间由16位无符号整数定义，单位100us。
一个PDO可以指定一个事件定时周期，当超过定时时间后，一个PDO传输可以被触发（不需要触发位）。事件定时周期由16位无符号整数定义，单位1ms。
PDO通过CAL中存储事件类型的CMS对象实现。PDO数据传送没有上层协议，而且PDO报文没有确认（一个PDO需要一个CAN-ID）。每个PDO报文传送最多8个字节（64位）数据。

4．预定义报文或者特殊功能对象
同步（SYNC）
在网络范围内同步（尤其在驱动应用中）：在整个网络范围内当前输入值准同时保存，随后传送（如果需要），根据前一个SYNC后接收到的报文更新输出值。
主从模式：SYNC主节点定时发送SYNC对象，SYNC从节点收到后同步执行任务。在SYNC报文传送后，在给定的时间窗口内传送一个同步PDO。用CAL中基本变量类型的CMS对象实现。
CANopen建议用一个最高优先级的COB-ID以保证同步信号正常传送。SYNC报文可以不传送数据以使报文尽可能短。
时间标记对象（TimeStamp）为应用设备提供公共的时间帧参考。
用CAL中存储事件类型的CMS对象实现。

图3-2预定义连接集ID
Node-ID由系统集成商定义，例如通过设备上的拨码开关设置。Node-ID范围是1~127（0不允许被使用）。
预定义的连接集定义了4个接收PDO（Receive－PDO），4个发送PDO（Transmit－PDO），1个SDO（占用2个CAN-ID），1个紧急对象和1个节点错误控制(Node-Error-Control)ID。也支持不需确认的NMT-Module-Control服务，SYNC和 TimeStamp对象的广播。
缺省ID分配表如表3-3所示。
表格3-3CANopen预定义主/从连接集CAN标识符分配表
CANopen预定义主/从连接集的广播对象
对象                                   功能码（ID-bits10-7）                   COB-ID                     通讯参数在OD中的索引
NMTModuleControl            0000                                              000H                         -
SYNC                                 0001                                              080H                        1005H，1006H，1007H
TIMESSTAMP                     0010                                             100H                        1012H，1013H

CANopen主/从连接集的对等对象
紧急                                  0001                                             081H-0FFH                  1024H，1015H
PDO1(发送)                      0011                                              181H-1FFH                  1800H
PDO1(接收)                      0100                                              201H-27FH                  1400H
PDO2(发送)                      0101                                              281H-2FFH                  1801H
PDO2(接收)                      0110                                             301H-37FH                     1401H
PDO3(发送)                      0111                                             381H-3FFH                    1802H
PDO3(接收)                      1000                                             401H-47FH                     1402H
PDO4(发送)                      1001                                             481H-4FFH                    1803H    

PDO4(接收)                     1010                                              501H-57FH                    1403H
SDO(发送/服务器)            1011                                             581H-5FFH                     1200H
SDO(接收/客户)               1100                                              601H-67FH                     1200H
NMTErrorControl             1110                                              701H-77FH                    1016H-1017H
注意：
?PDO/SDO发送/接收是由（slave）CAN节点方观察的。
?NMT错误控制包括节点保护（NodeGuarding），心跳报文（Heartbeat）和Boot-up协议。7
1：Start_Remote_Node(0x01)
2：Stop_Remote_Node(0x02)
3：Enter_Pre-Operational_State(0x80)
4：Reset_Node(0x81)
5：Reset_Communication(0x82)
6：设备初始化结束，自动进入Pre_Operational状态，发送Boot-up消息
在任何时候NMT服务都可使所有或者部分节点进入不同的工作状态。NMT服务的CAN报文由CAN头(COB-ID=0)和两字节数据组成；第一个字节表示请求的服务类型(‘NMTcommandspecifier’)，第二个字节是节点ID，或者0（此时寻址所有节点）。
仅支持最小化boot-up的设备叫最小能力设备。最小能力设备在设备初始化结束后自动进入预操作l状态。在这个状态，可以通过SDO进行参数配置和进行COB-ID分配。
设备进入准备状态后，除了NMT服务和节点保护服务（如果支持并且激活的话）外，将停止通讯。（因此‘Stopped’是描述这个状态的一个好名字）
3．6  CANopen消息语法细节
在以下部分中COB－ID使用的是CANopen预定义连接集中已定义的缺省标志符。
3．6．1  NMT模块控制（NMTModuleControl）
只有NMT-Master节点能够传送NMTModuleControl报文。所有从设备必须支持NMT模块控制服务。NMTModuleControl消息不需要应答。NMT消息格式如下：
NMT-Master                COB-ID          Byte0                  Byte1

NMT-Slave(s)              0x000              CS                   Node-ID

当Node-ID=0，则所有的NMT从设备被寻址。CS是命令字，可以取如下值：
命令字             NMT服务
1                     StartRemoteNode
2                     StopRemoteNode
128                 EnterPre-operationalState
129                 ResetNode
130                 ResetCommunication

3．6．2MNT节点保护（NMTNodeGuarding）
通过节点保护服务，MNT主节点可以检查每个节点的当前状态，当这些节点没有数据传送时这种服务尤其有意义。
NMT-Master节点发送远程帧（无数据）如下：
NMT-Master_to_ NMT-Slave      COB-ID   0x700+Node_ID

NMT-Slave节点发送如下报文应答：

NMT-Slave_to_NMT-Master       COB-ID                               Byte0
                                                  0x700+Node_ID                   Bit7:toggleBit6-0:状态

数据部分包括一个触发位（bit7），触发位必须在每次节点保护应答中交替置“0”或者“1”。触发位在第一次节点保护请求时置为“0”。位0到位6（bits0～6）表示节点状态，可为下表中的数值。9

PDO-producer & PDO-consumer(s)
COB-ID                                 Byte0                                      Byte1                                               Byte2
0x280+Node_ID               8位数据量输入                  16位模拟量输入（低8位）              16位模块量输入（高8位）

通过改变对象0x1A01的内容，PDO的内容可被改变（如果节点支持（可变PDO映射））。
注意在CANopen中多字节参数总是先发送LSB（littleendian）。
不允许超过8个字节的数据映射到某一个PDO中。
在CANopenApplicationLayerandCommunicationProfile（CiADS301V4.02）中定义了MPDO(multiplexorPDO)，允许一个PDO传输大量变量，通过在报文数据字节中包含源或目的节点ID、OD中的索引和子索引来实现。举个例子：如果没有这个机制，当一个节点有64个16位的模拟通道时，就需要16个不同的Transmit-PDOs来传送数据，
3．6．5服务数据对象（SDO）
SDO 用来访问一个设备的对象字典。访问者被称作客户(client)，对象字典被访问且提供所请求服务的CANopen设备别称作服务器(server)。客户的CAN报文和服务器的应答CAN报文总是包含8字节数据（尽管不是所有的数据字节都一定有意义）。一个客户的请求一定有来自服务器的应答。
SDO有2种传送机制：
加速传送（Expeditedtransfer）：最多传输4字节数据
分段传送（Segmentedtransfer）：传输数据长度大于4字节

SDO的基本结构如下：
Client-Server/Server-Client
Byte0                                                   Byte1-2             Byte3                      Byte4-7
SDO CommandSpecifier                      对象索引          对象子索引               ********
（**最大4字节数据(expeditedtransfer)或4字节字节计数器（segmentedtransfer）或关于blocktransfer参数)

或者Client-Server/Server-Client
Byte0                     Byte1-70
SDO命令字            最大7字节数据（segmentedtransfer）

SDO命令字包含如下信息：
下载/上传（Download/upload）
请求/应答（Request/response）
分段/加速传送（Segmented/expeditedtransfer）
CAN帧数据字节长度
用于后续每个分段的交替清零和置位的触发位（togglebit）

SDO 中实现了5个请求/应答协议：启动域下载（InitiateDomainDownload），域分段下载（DownloadDomainSegment），启动域上传（InitiateDomainUpload），域分段上传（UploadDomainSegment）和域传送中止（AbortDomainTransfer）。
在CANopen通讯协议的最新版本中，引入了一种新的SDO传送机制：
块传送（Blocktransfer）：当传送数据长度大于4字节时，多个分段只由1个确认报文应答（如果是下载，则由服务器启动传送，如果是上传，则由客户启动传送）以增加总线吞吐量。
相应的协议为：启动块下载（InitiateBlockDownload），块分段下载（DownloadBlockSegment），块下载结束（EndBlockDownload），启动块上传（InitiateBlockUpload），块分段上传（UploadBlockUpload）
在域传送中止报文中，数据字节0和1表示对象索引，字节2表示子索引，字节4到7包含32位中止码，描述中止报文传送原因，见表3-4所示。

表3-4域传送中止SDO：16进制中止代码表（字节4到7）
中止代码                         代码功能描述
05030000                       触发位没有交替改变
05040000                       SDO协议超时
05040001                       非法或未知的Client/Server命令字
05040002                       无效的块大小（仅BlockTransfer模式）
05040003                       无效的序号（仅BlockTransfer模式）
05030004                       CRC错误（仅BlockTransfer模式）
05030005                       内存溢出
06010000                      对象不支持访问
06010001                       试图读只写对象
06010002                      试图写只读对象
06020000                       对象字典中对象不存在
06040041                     对象不能够映射到PDO
06040042                     映射的对象的数目和长度超出PDO长度
06040043                     一般性参数不兼容
06040047                     一般性设备内部不兼容
06060000                    硬件错误导致对象访问失败
06060010                    数据类型不匹配，服务参数长度不匹配
06060012                    数据类型不匹配，服务参数长度太大
06060013                    数据类型不匹配，服务参数长度太短
06090011                    子索引不存在
06090030                    超出参数的值范围(写访问时)
06090031                    写入参数数值太大
06090032                    写入参数数值太小
06090036                    最大值小于最小值
08000000                    一般性错误
08000020                    数据不能传送或保存到应用
08000021                    由于本地控制导致数据不能传送或保存到应用
08000022                    由于当前设备状态导致数据不能传送或保存到应用
08000023                    对象字典动态产生错误或对象字典不存在（例如，通过文件生成对象字典，但由于文件损坏导致错误产生）
启动块下载（InitiateBlockDownload）
Bit         7  6  5  4  3  2   1   0
Client    1  1  0   -  -  cc  s   0
Server  1   0  1  -  -   sc   -   0
说明：
cc：客户数据是否使用CRC校验，0=no，1=yes。
sc：服务器数据是否使用CRC校验，0=no，1=yes。13

块分段上传（UploadBlockSegment）
Bit         7  6  5  4  3  2  1  0
Server  c  0
Server  c   1 ..etc… c  seqno
Client   1   1  0  -   -   -   1  0
说明：
c：是否有后续分段需要download，0＝yes，1=no。
seqno：分段号，0
服务器数据字节：每分段至多包括7字节数据被download。
客户字节1：表示最后一个被成功接收的分段号；如果为0，表示分段号为1的分段未正确接收，所有段必须重传。
客户字节2：包含blksize，每个块中分段的数目，客户机必须使用它进行下一次块下载，0
块上传结束（EndBlockUpload）
Bit   76543210
Server 1 1 0 n - 1
Client  1  0 1 - -  - - 1
说明：
n：指示最后一个块的最后一个段中无意义数据的字节数。
服务器数据bytes1+2为整个数据集的16位CRC；只有当启动块上传报文中cc和sc同时为1时CRC才有效。
下面给出几个例子说明如何使用SDO来访问一个节点的对象字典。
使用下面的SDO消息，值0x3FE将写到节点ID为2的对象字典中索引为0x1801，子索引为3的对象中去，使用启动域下载协议，加速传输（2字节数据）：
Client-Server(节点#2)
Byte
COB-ID  0   1    2   3    4    5   6   7
602      2B  01 18  03  FE  03  -    -
Client-Server(节点＃2)
582      60 01  18  03   -     -    -    -
使用下面的SDO消息，同样的对象字典中索引为0x1801，子索引为3的对象将被读出，使用启动域上传协议，服务器使用加速传输方式应答（2字节数据）：
Client?Server(节点＃2)
Byte
COB-ID  0   1    2   3    4    5   6   7
602       40  01  18 03   -    -    -    -
Client-Server(节点＃2)
582       4B  01  18 03 FE 03   -   -
3．6．6应急指示对象(EmergencyObject)

错误寄存器(ErrorRegister)在设备的对象字典（索引0x1001）中，表3-6说明了错误寄存器的位定义。设备可以将内部错误映射到这个状态字节中，并可以快速查看当前错误。
表3-68位错误寄存器位定义
Bit   错误类型
0    Generic
1    Current
2    Voltage
3    Temperature
4    Communication
5    Deviceprofilespecific
6    Reserved(=0)
7    Manufacturerspecific
制造商特定错误区域可能包含与设备相关的其它的错误信息。

--------------------------------------------

canalyzer编程，在首届面的conguration里面插入一个编程节点，然后双击开始编程，编完后进行编译，编译通过就可以运行了。
还可以支持图形界面，通过系统变量对控件进行控制挺好玩的，具体可以参看例子程序
-----------------------------------
在预操作状态中，用户可以通过SDO服务器读取对象字典中的所有参数，并借此来配置设备的参数，在这种情况下，用户可以使用“预定义连接集”所设定的默认SDO连接，而对应的SDO客户端由具有NMT主机功能的配置工具或应用程序来提供，在该阶段中，不仅设备的PDO参数可以得到配置，如果允许，映射条目和映射参数也可以进行配置，除此之外，用户还可以建立其他的SDO连接，但一般不推荐建立其他连接，因为设备默认的设置足以满足网络通讯的需求。
在预操作状态中还可以启动同步服务功能。同步报文生产者在发送启动报文消息之后，马上开始循环发送同步报文，从而使其他设备同步。在该状态中可以启动心跳机制来监控设备，不推荐用节点保护来监控设备，因为该功能基于can远程侦，不是所有的can设备都支持远程侦。在此预操作状态下不允许发送TPDO并且还会忽略所有的RPDO。

-

你住的城市下雨了

很想问你有没有带伞

可是我忍住了

因为我怕你说没带

而我友无能为力。。