摘要：

在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.3Triggering 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的事件驅動發送功能。