截取地址：https://www.e-learn.cn/content/qita/715699

什么是CANOPEN协议

CANOPEN协议是基于CAN总线协议建立的应用层协议。

CANOPEN协议属于“主-从站协议”，一个CANOPEN网络中有一个主站和若干个从站。

每一个从站点都有一个ID号，一个数据字典和四种工作状态。

CANOPEN协议将CAN总线协议的通信帧进行了进一步的封装和分类，以满足更高层次通信的需要。

CANOPEN数据字典

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协议也有规定，在下文中会进行介绍。

设备ID与常用通信对象

CANOPEN协议是一个“主-从站协议”，其中规定，在总线上每一个作为“从站”的设备要有一个自己的设备ID（主站设备不做强制要求）。

这个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总线协议的应用层协议。

PDO对象

上文中提到常用的通信对象有NMT、SYNC、EMERGENCY、TIME STAMP、SDO、PDO，每一种通信对象都有自己的用途。本章重点介绍PDO对象，了解了这个对象的机理，其他对象也可以融会贯通。

1 PDO对象概述

PDO对象称为“过程数据对象”，用于无连接的数据传输，即A站发送数据给B站后，不需要等待B站给出确认收到的应答。当然B站也可以应答一些信息给A站，这个有点像网络通信中的UDP协议，即应答不是强制要求的，B站可以回答，也可以不回答。

PDO对象的DATA部分可以完全用来传输数据，没有进步做要求。

根据上文知道，CAN总线本质上是广播的，对于B站来说，它面临三个问题（假设B站是主站）：

1. 总线上的通信对象是不是PDO对象,因为不同对象的数据部分的含义是不同的，需要不同的方式去解析；
2. 如何知道PDO对象是A站发出的；
3. 如何回答，即发送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就知道数据是发送给自己的。

2 PDO对象的引申问题

上一节讲了“主-从”站间PDO对象的通信原理。不过有一个大前提就是我们遵循了《建议》，这就引申出如下两个问题：

1. 《建议》给每个从站分配了4个RPDO对象,即每次主站最多只能发送4*8BYTE（64字节）的数据给从站，不够怎么办？
2. 从站与从站之间如何通信？

对于问题1，答案是不去遵守《建议》，自己根据需要规定，比如将0x281也规定为RPDO也可以，只要主站和从站都遵守这个规定就行。但这种情况是不多见的，因为《建议》本身是许多厂商共同商讨的结果，显然满足绝大部分应用情况。

对于问题2，其实超出了CANOPEN协议的应用范围，因为CANOPEN协议是“主-从站”协议，这类协议的特点就是从站之间没有通信的渠道。如果需要通信，也是通过主站中转。比如从站A发给主站，主站再发给从站B，来实现从站A与从站B的通信。从我的工业经验来看，这种从站之间通信的情况就没发生过。

SDO对象

有了PDO对象的基础，SDO对象的说明就容易多了。

1. SDO对象也分为TSDO和RSDO两种。（遵循《建议》）
2. SDO对象是用来操作从站设备的数据字典的。
3. SDO对象是一个有应答的通信对象，即主站发送RSDO给从站后，从站如果接收到，必须发送TSDO给主站进行应答。
4. 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，但是其构成还是挺复杂的，这里就不详细描述了，可以在网上找更加详细的文档来看。

标签：协议,对象,CANopen,0x1,PDO,CANOPEN,ID
来源： https://www.cnblogs.com/real-bert/p/11728083.html