CAN总线协议最早是为了统一汽车车载设备间通信的标准而开发的协议，后来由于其高速、稳定、可靠的特点，已经被ISO标准化并广泛应用于工控、医疗等领域，目前依然是欧洲汽车网络的标准协议。
CAN总线协议规定了ISO七层通信协议模型的物理层和数据链路层。其具体实现都已经被固化到CAN总线控制芯片中，无需软件实现。
理论上，CAN总线在速率小于5K时，距离可达10000m；速率接近1M时，距离小于0.4m。现实中常用的高速CAN总线速率有500k或250k，低速CAN总线有125k和62.5k，传输距离在几米到几十米间。速率和传输距离的选择还有考虑硬件的要求。
理论上，一条CAN总线上可以连接无数个CAN设备，但实际上受到其他条件限制，数量总是有限的。例如，使用了更上层的CANOPEN协议，则一条总线上只能有128个设备。
- CAN总线网络属于广播网络，同一条总线的设备都可以放送和接受数据。同一时刻只能有一个设备作为发送设备，其他设备为接收设备。
- 同一条总线上的设备必须工作在同一速率下。
- 当两个设备同时发送数据时，根据其CAN通信帧（CAN通信的最小信息单元详情见下文）的ID号进行仲裁，ID号小的优先级高，将获得发送权，优先级低的则需要放弃发送，转为接收状态。
- CAN设备可以检测总线上的错误类型是暂时性的还是持续性的，如果是持续性的，出错的设备会不停的向总线发送错误帧，一段时间后将自动脱离总线。
- can总线的终端电阻的选择很重要，选择的不好会影响通信质量。
CAN总线所使用的最基本通信单元称为帧，CAN总线协议规定了数据帧、遥控帧(也有称为远程帧的）、错误帧、过载帧和间隔帧。以下仅详细分析数据帧的帧格式，其他均只描述功能，不详细描述格式。
有些文档喜欢用显性电平和隐性电平来描述帧格式，这里说明一下，显性电平可以理解为逻辑1，隐性电平可以理解为逻辑0。
数据帧由7段构成
| 起始段 | 仲裁段 | 控制段 | 数据段 | CRC段 | ACK段 | 帧结束 |
|---|---|---|---|---|---|---|
| bit | 1 | 12 | 6 | 0-64 | 16 | 2 |
起始段：长度固定为1bit，逻辑0
仲裁段：前11bit为帧ID，后1bit为RTR标志
控制段：前2bit规定为0，后4bit为数据段的BYTE长度
数据段：长度可变，0~8BYTE
CRC段、ACK段、帧结束对于软件工程师来说可以不关注，比较重要的是理解仲裁段、控制段和数据段的含义。
没有数据段的数据帧一般用作心跳。
遥控帧的作用是向其他单元请求数据。比如设备A希望设备B向自己发送数据，设备A就向总线发送一个带有设备B的帧ID的遥控帧，设备B就会将数据发送的总线上。这里再次说明，CAN总线协议是广播的。
遥控帧的帧格式不具体列出，需要说明的是遥控帧也包含帧ID，当遥控帧与数据帧同时要发送时，也要根据ID的优先级仲裁，如果ID相同则数据帧具有更高优先级。
顾名思义，在检测到错误时发送到总线上的帧。
错误帧分为主动错误帧和被动错误帧两类。解释其不同要了解CAN总线的错误处理机制，但是其错误处理机制过于复杂，这里描写一个简化版。
每一个CAN总线芯片都会有错误计数器，初值为0。假设设备A总是发送错误。A发送一个数据帧后，发现有错误（这个发现错误的功能也是硬件实现的，应该是A发送数据的同时，也在校验总线上的数据），则A会将自己的错误计数器加8，并发送一个主动错误帧，其他设备如果接收到这个主动错误帧，会将自己的计数器加1；当A的计数器达到127时，A将改为发送被动错误帧，并依然给计数器加8，但不再发送数据帧；最后当A的计数器达到256时，A将不再工作。
以上的描述其实没有解释主动错误帧和被动错误帧在功能上有什么区别，只是描述了以下发送时机。其实CAN规范协议对此的规定十分复杂，详情还是找规范慢慢摸索吧，感觉用的不多。
如果发现总线上有错误帧，我的经验是第一查看所有设备的波特率是否一致，第二检测终端电阻是否合适。
待研究
CANOPEN协议是基于CAN总线协议建立的应用层协议。CANOPEN协议属于“主-从站协议”，一个CANOPEN网络中有一个主站和若干个从站。每一个从站点都有一个ID号，一个数据字典和四种工作状态。CANOPEN协议将CAN总线协议的通信帧进行了进一步的封装和分类，以满足更高层次通信的需要。
CANOPEN网络中的每一个从站设备都要有一个数据字典，其实数据字典这个翻译不太准确，应该叫做“命令ID与功能对照表”。比如网络中有一个信号灯设备，则这个设备就可能有这样一个数据字典。
| index | subIndex | data | 功能 |
|---|---|---|---|
| 0x400 | 0 | 0 | 开灯 |
| 0 | 1 | 关灯 |
其中index我们可以理解为“命令ID”，subIndex可以理解为“子ID”。
这个“字典”表示，只要有其他设备向信号灯发送一条包含命令ID为0x400和子ID为0的命令，如果data为0，则信号灯就亮；如果data为1,则信号灯就灭。所以说“数据字典”更像是“命令ID与功能对照表”。
实际上，CANOPEN协议规定了设备数据字典的格式，并对命令ID号进行了规定和划分（具体的规定很复杂，需要请参阅规范）。有一些命令ID的功能是固定的，有一些则可以由设备生产厂家自己决定。命令ID对应的功能也不总是操作这个设备，也可以是读取这个设备的信息，比如设备名等。
接下来的问题是如何向一个设备发送命令ID呢？对此，CANOPEN协议也有规定，在下文中会进行介绍。
CANOPEN协议是一个“主-从站协议”，其中规定，在总线上每一个作为“从站”的设备要有一个自己的设备ID（主站设备不做强制要求），称为Node-ID，这个英文名字在许多文章中更常见，范围是1~127（0有特殊用途，不能作为ID分配给设备），同一个总线上不能出现ID号相同的两个从站设备。所以，基于CANOPEN协议的总线上最多有127个从站设备。
那么为什么是127个呢，为了解释这个问题，要先了解CANOPEN协议规定的通信对象。
就像CAN总线协议的基本通信单元称为“帧”一样，CANOPEN协议的基本通信单元叫做“通信对象”（英文为Object，姑且这么翻译吧）。常用的通信对象有NMT、SYNC、EMERGENCY、TIME STAMP、SDO、PDO这几个，他们结构相同，包括funciton Code、Node-ID、DLC(数据长度）、DATA（数据）四部分构成，本质上都是通过封装CAN总线协议的数据帧实现的。他们的不同体现在DATA这个部分，有的对象DATA部分可以完全用来传输数据，有的对象针对DATA部分进一步做了划分和要求。
上文说过，CAN总线协议的数据帧包含一个仲裁段，其前11位是帧ID。CANOPEN协议进一步把帧ID分为FunctionCode和Node-ID两部分，如下：
| function Code | Node-ID |
|---|---|
| 4 | 7 |
由于Node-ID只有7位，最大值为127，所以CANOPEN协议的总线上最多有127个从站设备。functionCode和Node-ID在一起又被称为COB-ID。
DLC则对应数据帧控制段的后4位，表示后续负载数据的长度。
DATA与数据帧的数据段长度相同，至于有何用途，不同对象有不同要求。
| functionCode | Node-ID | DLC | DATA |
|---|---|---|---|
| 4bit | 7bit | 4bit | 8*8bit |
可见，CANOPEN协议的通信对象就是数据帧，只是进一步规定了数据帧的内容格式，所以说CANOPEN协议是基于CAN总线协议的应用层协议。
8 PDO瀵硅薄
上文中提到常用的通信对象有NMT、SYNC、EMERGENCY、TIME STAMP、SDO、PDO，每一种通信对象都有自己的用途。本章重点介绍PDO对象，了解了这个对象的机理，其他对象也可以融会贯通。
PDO对象称为“过程数据对象”，用于无连接的数据传输，即A站发送数据给B站后，不需要等待B站给出确认收到的应答。当然B站也可以应答一些信息给A站，这个有点像网络通信中的UDP协议，即应答不是强制要求的，B站可以回答，也可以不回答。
PDO对象的DATA部分可以完全用来传输数据，没有进步做要求。
根据上文知道，CAN总线本质上是广播的，对于B站来说，它面临三个问题（假设B站是主站）：
- 总线上的通信对象是不是PDO对象,因为不同对象的数据部分的含义是不同的，需要不同的方式去解析；
- 如何知道PDO对象是A站发出的；
- 如何回答，即发送PDO给A站。
对于问题1，B站是通过读取functionCode来判断当前总线上是不是PDO对象的。上文提到functionCode有4bit位，即有16个不同的functionCode。CANOPEN协议并没有硬性规定PDO对象必须使用那一个（或几个）functionCode，A站和B站可以自行约定。但是CANOPEN协议给了一个划分的《建议》（用书名号只是为了强调，不是真有一本叫做建议的书），既然是建议，你可以遵守也可以不遵守，但事实上，只要不是特殊情况，所用人都遵守了这个《建议》,如下：
| 对象 | functionCode | Node-ID | COB-ID |
|---|---|---|---|
| NMT（Model Control） | 0x0 | 0x0 | 0x0 |
| SYNC | 0x1 | 0x0 | 0x80 |
| TIME STAMP | 0x2 | 0x0 | 0x100 |
| EMERGENCY | 0x1 | 0x1-0x7F | 0x81-0xFF |
| PDO | 0x3-0xA | 0x1-0x7F | 0x181-0x57F |
| SDO | 0xB-0xC | 0x1-0x7F | 0x581-0x67F |
| NMT(ERROR) | 0xD | 0x1-0x7F | 0x701-0x77F |
对于问题2和问题3，我们先假设A站的Node-ID为1，并且需要进一步引入TPDO和RPDO的概念才能解决。
从上表中我们注意到PDO的functionCode是一个范围，共8个，即functionCode在此范围内的所有通信对象都是PDO对象。刚才提到的《建议》进一步对PDO进行了细分。以A站的PDO为例，如下表：
| 对象 | functionCode | Node-ID | COB-ID |
|---|---|---|---|
| TPDO1 | 0x3 | 0x1 | 0x181 |
| RPDO1 | 0x4 | 0x1 | 0x201 |
| TPDO2 | 0x5 | 0x1 | 0x281 |
| RPDO2 | 0x6 | 0x1 | 0x301 |
| TPDO3 | 0x7 | 0x1 | 0x381 |
| RPDO3 | 0x8 | 0x1 | 0x401 |
| TPDO4 | 0x9 | 0x1 | 0x481 |
| RPDO4 | 0xA | 0x1 | 0x501 |
通过上表，我们可以看出，从站A可以拥有8个PDO对象，其中4个为TPDO，4个为RPDO。下面来回答问题2,B站“如何知道PDO是A站发来的？”。答案就是检测PDO对象是否属于A站的TPDO，即COB-ID等于0x181,0x281,0x381或0x481。
对于问题3,答案是B站（主站）发送属于A站的RPDO。A站检查到总线上有自己的RPDO就知道数据是发送给自己的。
上一节讲了“主-从”站间PDO对象的通信原理。不过有一个大前提就是我们遵循了《建议》，这就引申出如下两个问题：
- 《建议》给每个从站分配了4个RPDO对象,即每次主站最多只能发送4*8BYTE（64字节）的数据给从站，不够怎么办？
- 从站与从站之间如何通信？
对于问题1，答案是不去遵守《建议》，自己根据需要规定，比如将0x281也规定为RPDO也可以，只要主站和从站都遵守这个规定就行。但这种情况是不多见的，因为《建议》本身是许多厂商共同商讨的结果，显然满足绝大部分应用情况。
对于问题2，其实超出了CANOPEN协议的应用范围，因为CANOPEN协议是“主-从站”协议，这类协议的特点就是从站之间没有通信的渠道。如果需要通信，也是通过主站中转。比如从站A发给主站，主站再发给从站B，来实现从站A与从站B的通信。从我的工业经验来看，这种从站之间通信的情况就没发生过。
9 SDO瀵硅薄
有了PDO对象的基础，SDO对象的说明就容易多了。
- SDO对象也分为TSDO和RSDO两种。（遵循《建议》）
- SDO对象是用来操作从站设备的数据字典的。
- SDO对象是一个有应答的通信对象，即主站发送RSDO给从站后，从站如果接收到，必须发送TSDO给主站进行应答。
- SDO对象对DATA段进行了进一步的规定和划分。
以下为SDO对象的结构
| functionCode | Node-ID | DLC | ControlCode | Index | SubIndex | data |
|---|---|---|---|---|---|---|
| 4bit | 7bit | 4bit | 8bit | 16bit | 8bit | 32bit |
其中ControlCode、Index、SubIndex和data就是DATA部分，SDO对象对此进行了细分规定。Index，SubIndex和data的含义，可以参考前文数据字典部分的信号灯的例子。
ControlCode在RSDO中经常表示此次操作是写入数据字典还是读取数据字典，在TSDO中表示写入是否成功，或者错误码一类的。虽然只有8bit，但是其构成还是挺复杂的，这里就不详细描述了，可以在网上找更加详细的文档来看。
<link rel="stylesheet" href="https://csdnimg.cn/release/phoenix/template/css/markdown_views-ea0013b516.css"> </div> CAN总线协议最早是为了统一汽车车载设备间通信的标准而开发的协议，后来由于其高速、稳定、可靠的特点，已经被ISO标准化并广泛应用于工控、医疗等领域，目前依然是欧洲汽车网络的标准协议。
CAN总线协议规定了ISO七层通信协议模型的物理层和数据链路层。其具体实现都已经被固化到CAN总线控制芯片中，无需软件实现。
理论上，CAN总线在速率小于5K时，距离可达10000m；速率接近1M时，距离小于0.4m。现实中常用的高速CAN总线速率有500k或250k，低速CAN总线有125k和62.5k，传输距离在几米到几十米间。速率和传输距离的选择还有考虑硬件的要求。
理论上，一条CAN总线上可以连接无数个CAN设备，但实际上受到其他条件限制，数量总是有限的。例如，使用了更上层的CANOPEN协议，则一条总线上只能有128个设备。
- CAN总线网络属于广播网络，同一条总线的设备都可以放送和接受数据。同一时刻只能有一个设备作为发送设备，其他设备为接收设备。
- 同一条总线上的设备必须工作在同一速率下。
- 当两个设备同时发送数据时，根据其CAN通信帧（CAN通信的最小信息单元详情见下文）的ID号进行仲裁，ID号小的优先级高，将获得发送权，优先级低的则需要放弃发送，转为接收状态。
- CAN设备可以检测总线上的错误类型是暂时性的还是持续性的，如果是持续性的，出错的设备会不停的向总线发送错误帧，一段时间后将自动脱离总线。
- can总线的终端电阻的选择很重要，选择的不好会影响通信质量。
CAN总线所使用的最基本通信单元称为帧，CAN总线协议规定了数据帧、遥控帧(也有称为远程帧的）、错误帧、过载帧和间隔帧。以下仅详细分析数据帧的帧格式，其他均只描述功能，不详细描述格式。
有些文档喜欢用显性电平和隐性电平来描述帧格式，这里说明一下，显性电平可以理解为逻辑1，隐性电平可以理解为逻辑0。
数据帧由7段构成
| 起始段 | 仲裁段 | 控制段 | 数据段 | CRC段 | ACK段 | 帧结束 |
|---|---|---|---|---|---|---|
| bit | 1 | 12 | 6 | 0-64 | 16 | 2 |
起始段：长度固定为1bit，逻辑0
仲裁段：前11bit为帧ID，后1bit为RTR标志
控制段：前2bit规定为0，后4bit为数据段的BYTE长度
数据段：长度可变，0~8BYTE
CRC段、ACK段、帧结束对于软件工程师来说可以不关注，比较重要的是理解仲裁段、控制段和数据段的含义。
没有数据段的数据帧一般用作心跳。
遥控帧的作用是向其他单元请求数据。比如设备A希望设备B向自己发送数据，设备A就向总线发送一个带有设备B的帧ID的遥控帧，设备B就会将数据发送的总线上。这里再次说明，CAN总线协议是广播的。
遥控帧的帧格式不具体列出，需要说明的是遥控帧也包含帧ID，当遥控帧与数据帧同时要发送时，也要根据ID的优先级仲裁，如果ID相同则数据帧具有更高优先级。
顾名思义，在检测到错误时发送到总线上的帧。
错误帧分为主动错误帧和被动错误帧两类。解释其不同要了解CAN总线的错误处理机制，但是其错误处理机制过于复杂，这里描写一个简化版。
每一个CAN总线芯片都会有错误计数器，初值为0。假设设备A总是发送错误。A发送一个数据帧后，发现有错误（这个发现错误的功能也是硬件实现的，应该是A发送数据的同时，也在校验总线上的数据），则A会将自己的错误计数器加8，并发送一个主动错误帧，其他设备如果接收到这个主动错误帧，会将自己的计数器加1；当A的计数器达到127时，A将改为发送被动错误帧，并依然给计数器加8，但不再发送数据帧；最后当A的计数器达到256时，A将不再工作。
以上的描述其实没有解释主动错误帧和被动错误帧在功能上有什么区别，只是描述了以下发送时机。其实CAN规范协议对此的规定十分复杂，详情还是找规范慢慢摸索吧，感觉用的不多。
如果发现总线上有错误帧，我的经验是第一查看所有设备的波特率是否一致，第二检测终端电阻是否合适。
待研究
CANOPEN协议是基于CAN总线协议建立的应用层协议。CANOPEN协议属于“主-从站协议”，一个CANOPEN网络中有一个主站和若干个从站。每一个从站点都有一个ID号，一个数据字典和四种工作状态。CANOPEN协议将CAN总线协议的通信帧进行了进一步的封装和分类，以满足更高层次通信的需要。
CANOPEN网络中的每一个从站设备都要有一个数据字典，其实数据字典这个翻译不太准确，应该叫做“命令ID与功能对照表”。比如网络中有一个信号灯设备，则这个设备就可能有这样一个数据字典。
| index | subIndex | data | 功能 |
|---|---|---|---|
| 0x400 | 0 | 0 | 开灯 |
| 0 | 1 | 关灯 |
其中index我们可以理解为“命令ID”，subIndex可以理解为“子ID”。
这个“字典”表示，只要有其他设备向信号灯发送一条包含命令ID为0x400和子ID为0的命令，如果data为0，则信号灯就亮；如果data为1,则信号灯就灭。所以说“数据字典”更像是“命令ID与功能对照表”。
实际上，CANOPEN协议规定了设备数据字典的格式，并对命令ID号进行了规定和划分（具体的规定很复杂，需要请参阅规范）。有一些命令ID的功能是固定的，有一些则可以由设备生产厂家自己决定。命令ID对应的功能也不总是操作这个设备，也可以是读取这个设备的信息，比如设备名等。
接下来的问题是如何向一个设备发送命令ID呢？对此，CANOPEN协议也有规定，在下文中会进行介绍。
CANOPEN协议是一个“主-从站协议”，其中规定，在总线上每一个作为“从站”的设备要有一个自己的设备ID（主站设备不做强制要求），称为Node-ID，这个英文名字在许多文章中更常见，范围是1~127（0有特殊用途，不能作为ID分配给设备），同一个总线上不能出现ID号相同的两个从站设备。所以，基于CANOPEN协议的总线上最多有127个从站设备。
那么为什么是127个呢，为了解释这个问题，要先了解CANOPEN协议规定的通信对象。
就像CAN总线协议的基本通信单元称为“帧”一样，CANOPEN协议的基本通信单元叫做“通信对象”（英文为Object，姑且这么翻译吧）。常用的通信对象有NMT、SYNC、EMERGENCY、TIME STAMP、SDO、PDO这几个，他们结构相同，包括funciton Code、Node-ID、DLC(数据长度）、DATA（数据）四部分构成，本质上都是通过封装CAN总线协议的数据帧实现的。他们的不同体现在DATA这个部分，有的对象DATA部分可以完全用来传输数据，有的对象针对DATA部分进一步做了划分和要求。
上文说过，CAN总线协议的数据帧包含一个仲裁段，其前11位是帧ID。CANOPEN协议进一步把帧ID分为FunctionCode和Node-ID两部分，如下：
| function Code | Node-ID |
|---|---|
| 4 | 7 |
由于Node-ID只有7位，最大值为127，所以CANOPEN协议的总线上最多有127个从站设备。functionCode和Node-ID在一起又被称为COB-ID。
DLC则对应数据帧控制段的后4位，表示后续负载数据的长度。
DATA与数据帧的数据段长度相同，至于有何用途，不同对象有不同要求。
| functionCode | Node-ID | DLC | DATA |
|---|---|---|---|
| 4bit | 7bit | 4bit | 8*8bit |
可见，CANOPEN协议的通信对象就是数据帧，只是进一步规定了数据帧的内容格式，所以说CANOPEN协议是基于CAN总线协议的应用层协议。
8 PDO瀵硅薄
上文中提到常用的通信对象有NMT、SYNC、EMERGENCY、TIME STAMP、SDO、PDO，每一种通信对象都有自己的用途。本章重点介绍PDO对象，了解了这个对象的机理，其他对象也可以融会贯通。
PDO对象称为“过程数据对象”，用于无连接的数据传输，即A站发送数据给B站后，不需要等待B站给出确认收到的应答。当然B站也可以应答一些信息给A站，这个有点像网络通信中的UDP协议，即应答不是强制要求的，B站可以回答，也可以不回答。
PDO对象的DATA部分可以完全用来传输数据，没有进步做要求。
根据上文知道，CAN总线本质上是广播的，对于B站来说，它面临三个问题（假设B站是主站）：
- 总线上的通信对象是不是PDO对象,因为不同对象的数据部分的含义是不同的，需要不同的方式去解析；
- 如何知道PDO对象是A站发出的；
- 如何回答，即发送PDO给A站。
对于问题1，B站是通过读取functionCode来判断当前总线上是不是PDO对象的。上文提到functionCode有4bit位，即有16个不同的functionCode。CANOPEN协议并没有硬性规定PDO对象必须使用那一个（或几个）functionCode，A站和B站可以自行约定。但是CANOPEN协议给了一个划分的《建议》（用书名号只是为了强调，不是真有一本叫做建议的书），既然是建议，你可以遵守也可以不遵守，但事实上，只要不是特殊情况，所用人都遵守了这个《建议》,如下：
| 对象 | functionCode | Node-ID | COB-ID |
|---|---|---|---|
| NMT（Model Control） | 0x0 | 0x0 | 0x0 |
| SYNC | 0x1 | 0x0 | 0x80 |
| TIME STAMP | 0x2 | 0x0 | 0x100 |
| EMERGENCY | 0x1 | 0x1-0x7F | 0x81-0xFF |
| PDO | 0x3-0xA | 0x1-0x7F | 0x181-0x57F |
| SDO | 0xB-0xC | 0x1-0x7F | 0x581-0x67F |
| NMT(ERROR) | 0xD | 0x1-0x7F | 0x701-0x77F |
对于问题2和问题3，我们先假设A站的Node-ID为1，并且需要进一步引入TPDO和RPDO的概念才能解决。
从上表中我们注意到PDO的functionCode是一个范围，共8个，即functionCode在此范围内的所有通信对象都是PDO对象。刚才提到的《建议》进一步对PDO进行了细分。以A站的PDO为例，如下表：
| 对象 | functionCode | Node-ID | COB-ID |
|---|---|---|---|
| TPDO1 | 0x3 | 0x1 | 0x181 |
| RPDO1 | 0x4 | 0x1 | 0x201 |
| TPDO2 | 0x5 | 0x1 | 0x281 |
| RPDO2 | 0x6 | 0x1 | 0x301 |
| TPDO3 | 0x7 | 0x1 | 0x381 |
| RPDO3 | 0x8 | 0x1 | 0x401 |
| TPDO4 | 0x9 | 0x1 | 0x481 |
| RPDO4 | 0xA | 0x1 | 0x501 |
通过上表，我们可以看出，从站A可以拥有8个PDO对象，其中4个为TPDO，4个为RPDO。下面来回答问题2,B站“如何知道PDO是A站发来的？”。答案就是检测PDO对象是否属于A站的TPDO，即COB-ID等于0x181,0x281,0x381或0x481。
对于问题3,答案是B站（主站）发送属于A站的RPDO。A站检查到总线上有自己的RPDO就知道数据是发送给自己的。
上一节讲了“主-从”站间PDO对象的通信原理。不过有一个大前提就是我们遵循了《建议》，这就引申出如下两个问题：
- 《建议》给每个从站分配了4个RPDO对象,即每次主站最多只能发送4*8BYTE（64字节）的数据给从站，不够怎么办？
- 从站与从站之间如何通信？
对于问题1，答案是不去遵守《建议》，自己根据需要规定，比如将0x281也规定为RPDO也可以，只要主站和从站都遵守这个规定就行。但这种情况是不多见的，因为《建议》本身是许多厂商共同商讨的结果，显然满足绝大部分应用情况。
对于问题2，其实超出了CANOPEN协议的应用范围，因为CANOPEN协议是“主-从站”协议，这类协议的特点就是从站之间没有通信的渠道。如果需要通信，也是通过主站中转。比如从站A发给主站，主站再发给从站B，来实现从站A与从站B的通信。从我的工业经验来看，这种从站之间通信的情况就没发生过。
9 SDO瀵硅薄
有了PDO对象的基础，SDO对象的说明就容易多了。
- SDO对象也分为TSDO和RSDO两种。（遵循《建议》）
- SDO对象是用来操作从站设备的数据字典的。
- SDO对象是一个有应答的通信对象，即主站发送RSDO给从站后，从站如果接收到，必须发送TSDO给主站进行应答。
- SDO对象对DATA段进行了进一步的规定和划分。
以下为SDO对象的结构
| functionCode | Node-ID | DLC | ControlCode | Index | SubIndex | data |
|---|---|---|---|---|---|---|
| 4bit | 7bit | 4bit | 8bit | 16bit | 8bit | 32bit |
其中ControlCode、Index、SubIndex和data就是DATA部分，SDO对象对此进行了细分规定。Index，SubIndex和data的含义，可以参考前文数据字典部分的信号灯的例子。
ControlCode在RSDO中经常表示此次操作是写入数据字典还是读取数据字典，在TSDO中表示写入是否成功，或者错误码一类的。虽然只有8bit，但是其构成还是挺复杂的，这里就不详细描述了，可以在网上找更加详细的文档来看。
<link rel="stylesheet" href="https://csdnimg.cn/release/phoenix/template/css/markdown_views-ea0013b516.css"> </div>