目前,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消息变量解释
- 首先,COB-ID 605反映了“SDO接收”的使用(COB-ID 600 +节点ID)
- CCS(客户端命令指定符)是传输类型(例如,1:下载,2:上传)
- n是字节区4-7中不包含的字节数(如果e和s被设置为有效)
- e表示“加速传输”,且所有数据都在单个CAN帧中(如果有设置)
- s表示数据大小显示为n(如果有设置)
- 索引(16位)和子索引(8位)反映了要访问的OD地址
- 最后,节点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 服务期间进行更改。