【CANopen实战】如何实现PDO数据变化即刻发送（事件触发模式详解）

摘要：

在CANopen通讯开发中，我们经常遇到这样的需求：当TPDO映射的对象字典(OD)数值发生变化时，从站需要即刻发送该PDO数据。

 

本文将结合CiA301标准，详细解析“事件触发(Event-driven)”模式的配置细节，并演示如何通过应用层代码(回调函数)实现这一功能。

一、需求背景

默认情况下，PDO可能被配置为同步(Sync)模式。但对于状态改变、报警等关键数据，我们需要它具有“实时性”，即：值变即发，无需等待SYNC帧。这就涉及到了PDO的传输类型(Transmission Type)配置。

二、理论基础：Transmission Type选型

查阅CiA301标准或相关资料，我们可以看到Sub-index 02的定义如下表：

分析：

根据功能需求，由于无需同步周期触发或远程帧触发，我们将研究重心放在“事件驱动(Event-driven)”模式上。基于此，首先需要了解什么是事件触发。

 

参阅CiA301文档中7.2.2.3 Triggering modes章节所述，协议将PDO的传输触发分为三大类：

• Event- and timer-driven(事件和定时器触发)
• Remotely requested(远程帧触发)
• Synchronously triggered(周期触发)

 

我们着重看Event-and timer-driven的解释：

在参考CiA相关协议文档时，并未发现“PDO映射数值变化即自动触发传输”的直接定义。 换言之，仅配置Transmission Type(传输类型)尚不足以实现该功能。

 

若需将对象字典(OD)的变化定义为触发事件，通常属于“用户设定”范畴，需要通过应用层代码配合实现。

深入理解Event-driven：254与255的区别 

在CANopen协议中，254与255均属于“事件驱动型(Event-driven)”，但其应用场景存在差异：

• 254(用户设定)： 触发逻辑完全由用户自行定义。传输行为仅受对象字典与应用程序控制，不受其他CANopen服务或报文的影响。
• 255(行业子协议)： 遵循特定行业标准(Device Profile)的设定。若相关Profile对PDO报文传输有特定约束，则需配置为255；通用场景下，通常首选254。

三、关键配置参数总结

在确定将Transmission Type设置为254后，需同步核查PDO的约束参数，以确保通信的稳定性。特别是在高频触发场景下，抑制时间(Inhibit Time)的设置对于防止总线拥塞至关重要。

 

至此，对象字典(OD)层面的配置已准备就绪。

四、应用层代码实现

配置完OD后，我们需要在代码层面实现“监控数据变化”并“请求发送”的逻辑。

1、核心思路  

注册一个 Object Dictionary Callback(对象字典回调函数)。

监控目标对象(例如 0x2000:01)的写入操作。

当检测到值发生变化时，调用协议栈的发送函数(如coPdoReqNr或类似 API)。

2、代码示例  

假设TPDO 1映射的值为0x2000:01。

 

步骤一：预设回调函数

我们在初始化阶段注册回调，监控索引2000，子索引01的变化：

步骤二：实现回调逻辑

在回调函数中，判断变化的对象，并手动触发PDO发送请求。

五、测试验证

1、测试环境 

TPDO 1映射对象：0x2000:01

应用逻辑：在Demo中设置一个5s定时器，每隔5秒让0x2000:01自增。

Demo逻辑代码：

2、测试结果分析 

通过CAN分析仪抓包可以看到：

当应用层逻辑修改0x2000:01的数值时，回调函数被触发。

coPdoReqNr(1)被执行。

总线上即刻观测到TPDO 1的报文发出，且数据已更新。

结论

通过Transmission Type = 254配合Inhibit Time以及应用层回调机制，我们成功实现了CANopen PDO的事件驱动发送功能。