虹科分享 | 简单实用的CANopen介绍，看完你就明白了（3）——对象字典、SDO、PDO

目前，CANopen通讯协议已经在工业领域得到了广泛的使用，由于其面向对象的设计思路，CANopen协议已成为欧洲等国家的自动化公司标配的通讯接口之一。在本系列文章中，我们将介绍CANopen协议的基础内容，包括对象字典、服务、SDO、PDO和主/从站节点等。

在之前的文章中，我们介绍了CANopen协议的基础知识，以及CANopen协议的框架和7种服务类型。而在本篇文章中，我们将主要介绍CANopen协议的对象字典、SDO和PDO。
前文回顾：
虹科分享 | 简单实用的CANopen介绍，看完你就明白了（1）——CANopen基础概念
虹科分享 | 简单实用的CANopen介绍，看完你就明白了（2）——CANopen框架与七种服务类型

一、对象字典

在7个CANopen服务中，PDO和SDO服务特别重要，因为它们构成了大多数CANopen通信的基础。下面我们将进行详细介绍，但在此之前我们需要了解CANopen的一个核心概念：对象字典。

所有的CANopen节点必须有一个对象字典（OD），对象字典是一个标准化结构，包含描述CANopen节点行为的所有参数。

OD条目通过一个16位的索引和8位的子索引进行查询。例如，符合CANopen标准的节点OD的索引1008（子索引0）包含节点设备名称。

具体来说，对象字典中的条目由属性定义的：

• 索引：对象的16位地址
• 对象名称：制造商的设备名称
• 对象代码：数组、变量或记录
• 数据类型：例如VISIBLE_STRING、UNSIGNED32或记录名称
• 访问： “rw”（读/写），“ro”（只读）或 “wo”（只写）
• 类别：这表明参数是强制性的还是可选的

OD标准化部分

在对象字典被分成标准化的部分中，有一些条目是强制性的，而另一些是完全可定制的。重要的是，一个设备（例如一个从站设备）的OD条目可以被另一个设备（例如一个主设备）通过CAN访问，例如使用SDO。
这可能让主站改变从站节点是否通过特定的输入传感器记录数据，或改变从站发送心跳的频率。阅读电子数据表和设备配置文件可以帮助理解OD。

电子数据表(EDS)

在实践中，配置/管理复杂的CANopen网络将会用到一些合适的软件工具。为了简化这一点，CiA 306标准定义了一种人类可读且和机器友好的INI文件格式，作为设备OD的“模板”–例如 “ServoMotor3000”。此EDS通常由供应商提供，包含所有设备对象（但不包括值）的信息。

设备配置文件（DCF）

假设一家工厂购买了一台ServoMotor3000，以整合到他们的传送带上。在操作过程中，操作员编辑了设备的EDS，并在EDS中添加了特定的参数值或改变了每个对象的描述名称。这样一来，操作者就有效地创建了所谓的设备配置文件（DCF）。有了这个文件，ServoMotor3000便能够集成到现场的特定CANopen网络中。

查看真实的EDS/DCF示例是理解CANopen对象字典的最佳方法之一，在下图中，您可以留意EDS和DCF对象条目之间的区别以及DCF如何包含特定的参数值。

此外，我们建议到官网上查看CiA 306标准，通过实际的例子对OD、EDS和DCF有更深入的了解。

如前文所述，DCF通常在设备集成时创建。然而，经常需要在初始配置后读取或改变一个节点的对象值——这就是SDO服务的作用所在。

二、SDO——配置CANopen网络

SDO服务允许CANopen节点通过CAN网络读取/编辑另一个节点的对象字典的值。正如在“通信模型”中提到的，SDO服务使用“客户端/服务器”模式。具体来说，一个SDO “客户端”与一个专门的SDO“服务器”发起通信。其目的可以是更新一个OD条目（称为“SDO下载”）或读取一个条目（“SDO上传”）。在简单的主/从网络中，具有NMT主站功能的节点充当所有NMT从站节点读取或写入其OD的客户端。

示例：客户端节点SDO下载
客户端节点可以通过在 CAN 帧下方的广播来启动到节点 5 的 SDO 下载 - 这将触发节点 5（并被其他节点忽略，见上图）。SDO“接收”（即请求）CAN 帧如下所示：

SDO消息变量解释

1. 首先，COB-ID 605反映了“SDO接收”的使用（COB-ID 600 +节点ID）
2. CCS（客户端命令指定符）是传输类型（例如，1：下载，2：上传）
3. n是字节区4-7中不包含的字节数（如果e和s被设置为有效）
4. e表示“加速传输”，且所有数据都在单个CAN帧中（如果有设置）
5. s表示数据大小显示为n（如果有设置）
6. 索引（16位）和子索引（8位）反映了要访问的OD地址
7. 最后，节点5将相应字节4-7中包含的相关数据

一旦主站节点（客户端）发送CAN帧，从站节点5（服务器）通过COB-ID 585的“SDO传输”进行响应。响应包含索引/子索引和4个空数据字节。自然，如果客户端节点请求上传（即从节点5OD读取数据），节点5将响应字节4-7中包含的相关数据。此外，对于更大的数据场景，可以使用SDO分段/块进行传输。

一般来说，SDO很灵活，但也会带来较高的成本，这使得SDO不太适合实时操作数据。这就是PDO的用武之地。

三、PDO——操作CANopen网络

CANopen的PDO服务用于在CANopen节点之间有效地共享实时操作数据。例如，PDO将携带来自压力传感器的压力数据或来自温度传感器的温度数据。原则上，SDO服务也能实现共享实时操作数据，但由于单个SDO响应只能携带4个数据字节，出于成本原因，我们不建议这么做。

此外，假设一个主站节点需要来自节点5的两个参数值（例如“SensTemp2”和“Torque5”）。如果通过SDO来实现，需要4个完整的CAN帧（2个请求和2个响应）。相比之下，一个PDO消息可以包含8个完整的数据字节，而且它可以在一个帧内包含多个对象参数值。因此，在SDO服务中至少需要4个报文，而在PDO服务中则可能只需要1个报文就可以完成。

PDO通常被看作是最重要的CANopen协议，因为它承载了大量的信息。下面我们将介绍CANopen的PDO服务是如何工作的。

PDO服务使用的是“消费者/生产者”模型。因此，生产者 “生产数据”，它使用发送PDO（TPDO）将其传送给“消费者”（主站）。反之，它可以通过“接收PDO”（RPDO）从消费者那里接收数据。

例如，生产者节点可以被配置为对应的同步触发，例如每隔100ms广播给消费者。然后，节点5可以在传输带有COB-ID 185的PDO下广播：

请注意这里的数据字节是如何装入3个参数值的。这些值反映了节点5的特定OD条目的实时数据。使用这些信息的节点（消费者）需要知道如何解释PDO数据字节。

在某种程度上，PDO服务有点像J1939 PGN和SPN，这类似于特定J1939 参数组(PG)如何在 8 个数据字节中包含多个 SPN/信号（也称为数据参数）。J1939 CAN 帧不需要在“解码”信息上浪费数据字节，因为相关节点（以及外部工具通过例如J1939 DBC 文件或 J1939 PDF 标准）知道这一点。问题在于，在 CANopen 中，这些“PDO 映射”通常是可配置的，并且可以在创建 DCF 或通过 SDO 服务期间进行更改。