簡(jiǎn)介本資源是一個(gè)面向嵌入式實(shí)時(shí)系統(tǒng)開發(fā)者的DS402運(yùn)動(dòng)控制協(xié)議實(shí)現(xiàn)方案基于CanFestival開源CANopen協(xié)議棧并適配Real-Time-ThreadRTT操作系統(tǒng)專為伺服驅(qū)動(dòng)器、多軸機(jī)器人及工業(yè)自動(dòng)化設(shè)備的CAN總線運(yùn)動(dòng)控制開發(fā)提供可運(yùn)行參考。資源共54個(gè)文件含26個(gè)頭文件.h定義對(duì)象字典、PDO映射、狀態(tài)機(jī)等、19個(gè)源文件.c涵蓋NMT管理、SDO/PDO通信、定時(shí)器與CAN驅(qū)動(dòng)適配、DS402狀態(tài)轉(zhuǎn)換邏輯等核心模塊以及4份Markdown文檔含README與使用說(shuō)明、3個(gè)SCons構(gòu)建腳本和1個(gè)對(duì)象字典.od配置文件整體僅115KB輕量緊湊。已有885人學(xué)習(xí)下載適合具備CAN總線基礎(chǔ)與RTOS開發(fā)經(jīng)驗(yàn)的中級(jí)以上工程師快速掌握DS402協(xié)議在RTT環(huán)境下的集成方法、PDO同步配置、SDO參數(shù)讀寫及運(yùn)動(dòng)模式切換等關(guān)鍵實(shí)踐環(huán)節(jié)。把伺服電機(jī)玩轉(zhuǎn)CanFestival在RT-Thread上實(shí)現(xiàn)CANopen主站的實(shí)戰(zhàn)記錄做工業(yè)運(yùn)動(dòng)控制這幾年伺服驅(qū)動(dòng)器的總線控制始終是個(gè)繞不開的話題。脈沖方向控制簡(jiǎn)單但擴(kuò)展性太差一兩軸還能應(yīng)付設(shè)備一上到六個(gè)軸八個(gè)軸線束、干擾、調(diào)試時(shí)間全都失控。CANopen總線在性能和成本之間算是很平衡的方案但問(wèn)題在于——不管是移植協(xié)議棧還是調(diào)試主站市面上的資料和工具都支離破碎。我這次用RT-Thread跑CanFestival協(xié)議棧配合DS402設(shè)備協(xié)議做了一套CANopen主站從選型到把電機(jī)真正轉(zhuǎn)起來(lái)踩了不少坑也沉淀了不少經(jīng)驗(yàn)。這篇文章就完整記錄下來(lái)給打算自己搭建CANopen主站的朋友做個(gè)參考。先說(shuō)結(jié)論這套方案比我之前用商用CANopen主站工具的情況可控性好很多成本基本為零協(xié)議棧開源環(huán)境是STM32代碼量不算大但要踩明白的坑真不少。整篇文章我分成五個(gè)部分從選型理由、協(xié)議棧移植、主站邏輯、實(shí)際踩坑到可靠性增強(qiáng)逐步展開適合兩種人看一是準(zhǔn)備把CanFestival移植到RT-Thread或裸機(jī)上的嵌入式工程師二是想搞懂CANopen主站到底怎么控制DS402伺服驅(qū)動(dòng)器的開發(fā)者。1. 為什么自己搭主站從脈沖控制到CANopen總線這一步非走不可1.1 設(shè)備升級(jí)過(guò)程中的真實(shí)痛點(diǎn)我手頭這個(gè)項(xiàng)目早期用的是脈沖方向方式控制伺服。六臺(tái)伺服電機(jī)驅(qū)動(dòng)器集中在電氣柜里每臺(tái)電機(jī)要拉脈沖、方向、使能、報(bào)警、復(fù)位這些信號(hào)線再加上編碼器反饋線一捆一捆的屏蔽線布線就是一場(chǎng)災(zāi)難。電氣柜施工周期長(zhǎng)現(xiàn)場(chǎng)總線端子經(jīng)常松動(dòng)排查故障全靠拿萬(wàn)用表一根一根量。真正讓我下決心換CANopen的是一次現(xiàn)場(chǎng)故障伺服報(bào)警反饋線虛接設(shè)備突然急停操作員一臉懵PLC只看到一個(gè)伺服故障的模糊信號(hào)根本定位不到是哪個(gè)軸什么原因。換到CANopen之后每個(gè)節(jié)點(diǎn)的故障碼、驅(qū)動(dòng)器溫度和母線電壓都能通過(guò)SDO讀取遠(yuǎn)程診斷能力完全不一樣。CANopen的另一個(gè)優(yōu)勢(shì)是多軸擴(kuò)展和總線拓?fù)涞撵`活性。脈沖控制的控制器要擴(kuò)展軸數(shù)基本等于換主控CANopen只要在總線上掛節(jié)點(diǎn)主站側(cè)加配置就行。1.2 協(xié)議棧選型為什么是CanFestival而不是CANopenNode在CanFestival和CANopenNode之間糾結(jié)了一段時(shí)間。CANopenNode社區(qū)活躍度確實(shí)高有些新特性支持更好但對(duì)我來(lái)說(shuō)有幾個(gè)關(guān)鍵限制首先是RT-Thread生態(tài)的適配問(wèn)題CANopenNode的硬件抽象層比較分散對(duì)接RT-Thread的設(shè)備框架需要寫不少膠水代碼其次是對(duì)象字典編輯器的體驗(yàn)CANopenNode的編輯器雖然能用但生成代碼的結(jié)構(gòu)和嵌入式的集成方式總感覺(jué)不夠直接。CanFestival吸引我的地方在于它的結(jié)構(gòu)非?！扒度胧健薄麄€(gè)協(xié)議棧就是一組C文件加一個(gè)對(duì)象字典編譯進(jìn)RT-Thread工程后跑在裸線程里沒(méi)有復(fù)雜的動(dòng)態(tài)內(nèi)存分配依賴。它的對(duì)象字典編輯器ObjDictEdit可以生成完全靜態(tài)的字典數(shù)組查表效率高RAM占用可預(yù)測(cè)。另外CanFestival對(duì)DS401、DS402伺服驅(qū)動(dòng)設(shè)備規(guī)范也就是CIA 402的支持比較完整我需要的SDO、PDO、心跳、節(jié)點(diǎn)守護(hù)、同步幀這些機(jī)制都原生具備。1.3 整體架構(gòu)RT-Thread端到端的CANopen系統(tǒng)分層這套系統(tǒng)的結(jié)構(gòu)分四層每一層的職責(zé)邊界我盡量劃清楚應(yīng)用層運(yùn)動(dòng)控制邏輯比如點(diǎn)位運(yùn)動(dòng)、速度曲線、狀態(tài)機(jī)調(diào)度協(xié)議棧層CanFestival核心EMCY、SDO、PDO、NMT、心跳、時(shí)間戳接口層RT-Thread的CAN設(shè)備驅(qū)動(dòng)、定時(shí)器回調(diào)、串口調(diào)試日志硬件層STM32芯片、CAN收發(fā)器、伺服驅(qū)動(dòng)器設(shè)備側(cè)的伺服驅(qū)動(dòng)器我測(cè)試用的是臺(tái)達(dá)和松下各一臺(tái)作為CANopen從站實(shí)現(xiàn)標(biāo)準(zhǔn)DS402對(duì)象字典。主站側(cè)的CanFestival用_nmtMaster模式工作管理整個(gè)總線的啟停和節(jié)點(diǎn)監(jiān)控。------------------------------------------ | 應(yīng)用層運(yùn)動(dòng)控制邏輯 | | 點(diǎn)位 / 速度 / 力矩 指令生成 | ------------------------------------------ | CanFestival 協(xié)議棧核心 | | NMT | SDO | PDO | EMCY | Heartbeat | | 對(duì)象字典靜態(tài)生成的OD | ------------------------------------------ | RT-Thread 設(shè)備框架 | | CAN設(shè)備驅(qū)動(dòng) | 定時(shí)器 | 線程調(diào)度 | ------------------------------------------ | STM32 CAN PHY | ------------------------------------------這個(gè)架構(gòu)的優(yōu)點(diǎn)是把CanFestival當(dāng)成一個(gè)靜態(tài)庫(kù)來(lái)用RT-Thread提供底層調(diào)度和通信能力。我后續(xù)加入的任何功能模塊比如Modbus TCP轉(zhuǎn)CANopen網(wǎng)關(guān)都是按這個(gè)分層來(lái)擴(kuò)展不會(huì)破壞協(xié)議棧的穩(wěn)定性。2. CanFestival在RT-Thread上的移植實(shí)操文件級(jí)集成與關(guān)鍵接口改造2.1 源碼獲取與工程目錄組織CanFestival的官方源碼可以從SourceForge倉(cāng)庫(kù)克隆或者直接從GitHub上的鏡像下載。我的建議是不要直接拖進(jìn)RT-Thread工程就開始編譯先把協(xié)議棧獨(dú)立成一個(gè)子目錄后續(xù)升級(jí)和排查都方便。目錄結(jié)構(gòu)大概長(zhǎng)這樣app/ ├── canfestival/ │ ├── src/ # 協(xié)議棧核心源碼 │ │ ├── can_dcf.c # CAN接口底層需適配 │ │ ├── timers_dcf.c # 定時(shí)器實(shí)現(xiàn)需適配 │ │ ├── lss.c │ │ ├── nmtMaster.c │ │ ├── sdo.c │ │ ├── pdo.c │ │ └── ... │ ├── include/ # 頭文件 │ ├── objdict/ # 生成的對(duì)象字典 │ │ ├── ObjDict.c │ │ ├── ObjDict.h │ │ └── ObjDict_utils.c │ └── drivers/ # 與RT-Thread適配的驅(qū)動(dòng) │ ├── can_rtthread.c │ └── timer_rtthread.c ├── main.c └── SConscript # RT-Thread構(gòu)建腳本移植的重點(diǎn)就是兩個(gè)文件can_dcf.c和timers_dcf.c。2.2 定時(shí)器對(duì)接協(xié)議棧的時(shí)基全依賴這里CanFestival的定時(shí)器機(jī)制比較特殊它內(nèi)部維護(hù)了一個(gè)軟件定時(shí)器鏈表每次調(diào)用TimerIRQ是1ms時(shí)基然后協(xié)議棧自己去處理和比較超時(shí)時(shí)間。RT-Thread里最簡(jiǎn)單的適配方式是用一個(gè)1ms周期的軟件定時(shí)器在回調(diào)里調(diào)用TimerIRQ()。// timer_rtthread.c #include rtthread.h #include timers_dcf.h static rt_timer_t canopen_timer RT_NULL; static void timer_irq_callback(void *parameter) { TimerIRQ(); } void canopen_timer_init(void) { canopen_timer rt_timer_create(canopen_timer, timer_irq_callback, RT_NULL, rt_tick_from_millisecond(1), RT_TIMER_FLAG_PERIODIC | RT_TIMER_FLAG_SOFT_TIMER); if (canopen_timer ! RT_NULL) { rt_timer_start(canopen_timer); } }提示不要用硬件定時(shí)器中斷里的回調(diào)直接實(shí)現(xiàn)TimerIRQ()CanFestival的處理函數(shù)中有一些臨界區(qū)操作如果優(yōu)先級(jí)設(shè)置不當(dāng)很容易破壞協(xié)議棧內(nèi)部的鏈表結(jié)構(gòu)。用RT-Thread的軟件定時(shí)器配合一個(gè)專門的協(xié)議棧線程雖然響應(yīng)有小幅延遲1ms級(jí)別完全可以接受但安全性高很多。還有幾個(gè)關(guān)鍵的定時(shí)指針要提前初始化好void timer_init(void) { TimerIRQ timer_irq_callback; // 這種寫法是在CanFestival內(nèi)部注冊(cè)回調(diào) // 實(shí)際上更常見(jiàn)的是直接讓timer_irq_callback調(diào)用TimerIRQ() }不同版本CanFestival在這塊寫法有些差異我用的3.0版本里initTimer函數(shù)需要把定時(shí)器句柄存到全局變量里。RT-Thread里別忘記使能軟件定時(shí)器宏RT_USING_TIMER_SOFT。2.3 CAN接口對(duì)接從rt_device到canDispatch的橋梁CAN接口的適配是整個(gè)移植里最直接的一層。CanFestival通過(guò)一個(gè)can_port_t類型的口調(diào)用底層的CAN發(fā)送函數(shù)名字固定為canSend不同版本可能叫canSend_或canSendMessage。我維護(hù)了一個(gè)環(huán)形緩沖區(qū)來(lái)緩沖發(fā)送報(bào)文避免在中斷里直接調(diào)用協(xié)議棧的函數(shù)。先看RT-Thread這邊把CAN設(shè)備初始化好// can_rtthread.c #include rtdevice.h #include rtthread.h #include can_dcf.h #define CAN_DEV_NAME can1 static rt_device_t can_dev RT_NULL; static rt_sem_t can_rx_sem RT_NULL; static struct rt_can_msg rx_msg; void can_init(void) { rt_err_t res; struct rt_can_filter_config filter_cfg; can_dev rt_device_find(CAN_DEV_NAME); if (can_dev RT_NULL) { rt_kprintf(can device not found!\n); return; } res rt_device_open(can_dev, RT_DEVICE_FLAG_INT_RX | RT_DEVICE_FLAG_INT_TX); if (res ! RT_EOK) { rt_kprintf(open can device failed!\n); return; } // 設(shè)置接收過(guò)濾器CANopen使用11位標(biāo)準(zhǔn)幀過(guò)濾所有ID struct rt_can_filter_item items[1] { { .id 0x000, .mask 0x000, // 接收所有報(bào)文 .mode RT_CAN_FILTER_MODE_MASK, .ind 0, } }; filter_cfg.items items; filter_cfg.count 1; filter_cfg.activated 1; rt_device_control(can_dev, RT_CAN_CMD_SET_FILTER, filter_cfg); // 創(chuàng)建接收信號(hào)量 can_rx_sem rt_sem_create(can_rx, 0, RT_IPC_FLAG_FIFO); // 設(shè)置接收回調(diào) rt_device_set_rx_indicate(can_dev, can_rx_indicate); }然后是CanFestival協(xié)議的發(fā)送和接收接入// CanFestival底層調(diào)用這個(gè)函數(shù)發(fā)送報(bào)文 UNS8 canSend(Message *m) { struct rt_can_msg tx_msg; tx_msg.id m-cob_id; tx_msg.hdr 0; tx_msg.len m-len; tx_msg.type RT_CAN_STDID; // COB-ID是11位標(biāo)準(zhǔn)ID memcpy(tx_msg.data, m-data, m-len); // 在這里用互斥鎖或直接發(fā)送看具體RT-Thread版本API rt_device_write(can_dev, 0, tx_msg, 1); return 0; } // CAN接收中斷回調(diào)信號(hào)量喚醒線程 void can_rx_indicate(rt_device_t dev, rt_size_t size) { rt_sem_release(can_rx_sem); } // 專用的接收線程 void can_rx_thread_entry(void *param) { struct rt_can_msg rx_msg; Message canopen_msg; while (1) { rt_sem_take(can_rx_sem, RT_WAITING_FOREVER); while (rt_device_read(can_dev, 0, rx_msg, 1) 1) { canopen_msg.cob_id rx_msg.id; canopen_msg.len rx_msg.len; canopen_msg.rtr (rx_msg.type RT_CAN_RTR) ? 1 : 0; memcpy(canopen_msg.data, rx_msg.data, rx_msg.len); // 送入CanFestival協(xié)議棧處理 canDispatch(canopen_OD, canopen_msg); } } }這里有個(gè)容易忽略的細(xì)節(jié)CanFestival的Message數(shù)據(jù)結(jié)構(gòu)和RT-Thread的rt_can_msg在字節(jié)序和位域定義上不完全一致memcpy前最好先轉(zhuǎn)成CanFestival的Message結(jié)構(gòu)體而不是直接把rt_can_msg指針強(qiáng)制轉(zhuǎn)成Message指針?lè)駝t在CAN ID解析那一步很容易出現(xiàn)數(shù)據(jù)錯(cuò)位。2.4 對(duì)象字典生成與DS402從站配置文件的加載對(duì)象字典是CanFestival最核心的靜態(tài)數(shù)據(jù)。我先用ObjDictEdit工具定義好主站需要的所有索引比如0x1000: 設(shè)備類型默認(rèn)值按標(biāo)準(zhǔn)設(shè)0x1005: COB-ID同步幀0x100C: 心跳時(shí)間0x1800-0x18FF: 發(fā)送PDO參數(shù)0x1400-0x14FF: 接收PDO參數(shù)對(duì)于DS402從站控制主站側(cè)的對(duì)象字典里不需要都定義出來(lái)但必須為各個(gè)從站保留地址空間和相關(guān)索引因?yàn)镃anFestival的SDO客戶端功能需要在OD里配置通信參數(shù)。最簡(jiǎn)單的方式是主站OD定義成一個(gè)完備的DSP402類型包含控制字、狀態(tài)字、模式、目標(biāo)位置等索引。當(dāng)然從站側(cè)的DS402對(duì)象字典一般在驅(qū)動(dòng)器的調(diào)試軟件里配置比如臺(tái)達(dá)的ASDA-Soft或松下的PANATERM主站側(cè)直接通過(guò)SDO讀寫即可。對(duì)象字典生成后會(huì)在工程里形成三個(gè)文件ObjDict.c、ObjDict.h和ObjDict_utils.c編譯進(jìn)工程即可。需要特別注意OBJDICT的默認(rèn)值必須和物理總線上的節(jié)點(diǎn)配置一致否則上電后SDO讀回來(lái)的數(shù)據(jù)和OD不一致排查起來(lái)非常繞。3. DS402主站核心邏輯狀態(tài)機(jī)、SDO與PDO的高效配合3.1 DS402設(shè)備狀態(tài)機(jī)與主站聯(lián)動(dòng)DS402定義了一套標(biāo)準(zhǔn)的驅(qū)動(dòng)器狀態(tài)機(jī)這是控制所有CIA 402設(shè)備的通用步驟。主站控制伺服本質(zhì)就是控制狀態(tài)機(jī)的跳轉(zhuǎn)。狀態(tài)圖如下用文字描述狀態(tài)轉(zhuǎn)移關(guān)系Fault - Fault Reset - Switch On Disabled - Ready To Switch On - Switched On - Operation Enable主站通過(guò)寫0x6040控制字索引來(lái)觸發(fā)狀態(tài)跳轉(zhuǎn)。常用的控制字值目標(biāo)狀態(tài)控制字值(hex)說(shuō)明故障復(fù)位0x80清除故障進(jìn)入Switch On Disabled上電準(zhǔn)備0x06Switch On Disabled - Ready To Switch On使能0x07Ready - Switched On操作允許0x0FSwitched On - Operation Enable禁用操作0x07或0x00退回Switched On或Ready一個(gè)測(cè)試用的使能序列函數(shù)長(zhǎng)這樣void ds402_enable_servo(UNS16 node_id) { // 清除故障 sdo_write_u16(node_id, 0x6040, 0x00, 0x80); rt_thread_mdelay(100); // 讀取狀態(tài)字確認(rèn)進(jìn)入Switch On Disabled // ... // 上電準(zhǔn)備 sdo_write_u16(node_id, 0x6040, 0x00, 0x06); rt_thread_mdelay(50); // 使能 sdo_write_u16(node_id, 0x6040, 0x00, 0x07); rt_thread_mdelay(50); // 操作允許 sdo_write_u16(node_id, 0x6040, 0x00, 0x0F); rt_thread_mdelay(50); }狀態(tài)機(jī)跳轉(zhuǎn)的判斷依據(jù)是0x6041索引的狀態(tài)字。這里有個(gè)細(xì)節(jié)狀態(tài)字的第5位quick stop、第6位switch on disabled和第7位warning這些狀態(tài)位組合起來(lái)才能準(zhǔn)確判斷當(dāng)前處于哪個(gè)狀態(tài)不能只看0-3位的值。我在調(diào)試時(shí)用了一個(gè)簡(jiǎn)易的狀態(tài)映射表把所有有效狀態(tài)組合映射成文字打印到串口排查速度快很多。3.2 SDO機(jī)制讀寫參數(shù)的可靠通道SDO是CANopen里用起來(lái)最直接但最容易被“想當(dāng)然”的機(jī)制。CanFestival主站的SDO寫函數(shù)使用sdo_write_u16實(shí)際是sdo_write_*系列底層走的是確認(rèn)型SDO協(xié)議需要等待從站返回確認(rèn)報(bào)文所以調(diào)用過(guò)程是阻塞的。我在主站側(cè)封裝了一個(gè)帶超時(shí)的SDO訪問(wèn)接口#define SDO_TIMEOUT_MS 500 rt_err_t sdo_write_u16(UNS16 node_id, UNS16 index, UNS8 subindex, UNS16 value) { UNS8 data[2]; data[0] value 0xFF; data[1] (value 8) 0xFF; // 調(diào)用CanFestival的SDO寫函數(shù) signed char res sdo_write(canopen_OD, node_id, index, subindex, data, 2, SDO_TIMEOUT_MS); if (res ! 0) { rt_kprintf(SDO write failed: node%d idx0x%X sub0x%X res%d\n, node_id, index, subindex, res); return -RT_ERROR; } return RT_EOK; }這里CanFestival的sdo_write函數(shù)本身會(huì)掛起等待所以必須在獨(dú)立線程里調(diào)用不能在CAN接收中斷或高優(yōu)先級(jí)任務(wù)里直接執(zhí)行。我專門開了一個(gè)SDO線程優(yōu)先級(jí)設(shè)為中等比如20防止阻塞影響主循環(huán)的周期任務(wù)。SDO讀比寫麻煩在返回?cái)?shù)據(jù)的數(shù)量是變長(zhǎng)的需要先發(fā)起讀請(qǐng)求再等響應(yīng)。CanFestival里sdo_read需要預(yù)先分配緩沖區(qū)如果緩沖區(qū)不夠大會(huì)返回錯(cuò)誤碼。我建議讀回的數(shù)據(jù)先打印成十六進(jìn)制再解析避免大小端理解錯(cuò)誤。3.3 PDO配置與運(yùn)動(dòng)控制報(bào)文設(shè)計(jì)PDO運(yùn)用于周期性實(shí)時(shí)數(shù)據(jù)的傳輸。DS402的運(yùn)動(dòng)控制中最常用的同步PDO是這樣設(shè)計(jì)的RPDO1主站到驅(qū)動(dòng)器控制字0x6040 目標(biāo)位置0x607A 或 目標(biāo)速度0x60FF 模式0x6060TPDO1驅(qū)動(dòng)器到主站狀態(tài)字0x6041 實(shí)際位置0x6064 實(shí)際速度0x606C主站側(cè)配置PDO映射和通信周期主要用SDO去寫幾個(gè)關(guān)鍵索引// 配置從站的RPDO1通信參數(shù)0x1400 sdo_write_u32(1, 0x1400, 1, 0x00000200); // COB-ID0x200為RPDO1標(biāo)準(zhǔn)標(biāo)識(shí) sdo_write_u8(1, 0x1400, 2, 0x01); // 傳輸類型0x01表示同步周期1 // 配置PDO映射把控制字和目標(biāo)速度映射進(jìn)RPDO10x1600 sdo_write_u8(1, 0x1600, 0, 0); // 先清零映射數(shù)量 sdo_write_u32(1, 0x1600, 1, 0x60400010); // 控制字 16bit sdo_write_u32(1, 0x1600, 2, 0x60FF0020); // 目標(biāo)速度 32bit sdo_write_u8(1, 0x1600, 0, 2); // 映射數(shù)量為2寫映射項(xiàng)之前必須先把0x1600的subindex 0清零否則部分驅(qū)動(dòng)器會(huì)拒絕修改映射。這個(gè)順序問(wèn)題我一開始沒(méi)注意松下驅(qū)動(dòng)器直接返回SDO網(wǎng)關(guān)錯(cuò)誤排查半天才找到。PDO數(shù)據(jù)按照映射順序緊湊排列控制字2字節(jié)為目標(biāo)速度4字節(jié)總長(zhǎng)6字節(jié)發(fā)送時(shí)CANframe長(zhǎng)度設(shè)成6即可。速度值默認(rèn)是32位有符號(hào)整數(shù)單位取決于驅(qū)動(dòng)器設(shè)定常用rpm或脈沖/s。同步幀的周期也是一個(gè)需要協(xié)調(diào)的參數(shù)。DS402模式下驅(qū)動(dòng)器內(nèi)部的位置控制周期通常設(shè)為1ms或2ms主站發(fā)出SYNC幀0x80后所有配置為同步的PDO報(bào)文才被觸發(fā)執(zhí)行。假如同步周期和驅(qū)動(dòng)器控制周期不匹配實(shí)際運(yùn)動(dòng)會(huì)明顯抖動(dòng)。我這邊用的策略是主站用一個(gè)2ms的定時(shí)器發(fā)送SYNC幀同時(shí)在RPDO的傳輸類型里配置為2每個(gè)同步周期觸發(fā)一次這樣控制循環(huán)和驅(qū)動(dòng)器內(nèi)部循環(huán)天然對(duì)齊。4. 從“節(jié)點(diǎn)發(fā)現(xiàn)不了”到“電機(jī)轉(zhuǎn)起來(lái)”完整踩坑排查鏈路4.1 現(xiàn)象一總線上一個(gè)節(jié)點(diǎn)都發(fā)現(xiàn)不了排查過(guò)程項(xiàng)目剛移植完CanFestival燒錄之后執(zhí)行NMT搜索總線上一片寂靜。我先是拿邏輯分析儀抓了CAN_H和CAN_L的波形發(fā)現(xiàn)確實(shí)有報(bào)文發(fā)出來(lái)但節(jié)點(diǎn)一個(gè)回應(yīng)都沒(méi)有。接著用同樣的物理鏈路換了一個(gè)多合一的CANopen調(diào)試工具去探測(cè)節(jié)點(diǎn)全部正常響應(yīng)——說(shuō)明問(wèn)題不在驅(qū)動(dòng)物理鏈路而是主站報(bào)文的數(shù)據(jù)結(jié)構(gòu)或ID映射出了問(wèn)題。拿CANalyzer直接查看主站發(fā)出來(lái)的報(bào)文發(fā)現(xiàn)問(wèn)題出在COB-ID的賦值上。CanFestival內(nèi)部用Message結(jié)構(gòu)體的cob_id成員存儲(chǔ)COB-ID但在底層發(fā)送時(shí)需要區(qū)分標(biāo)準(zhǔn)幀11位ID和擴(kuò)展幀29位ID。我在CAN發(fā)送函數(shù)里直接把cob_id賦給了rt_can_msg的id字段可RTT的CAN驅(qū)動(dòng)默認(rèn)是按擴(kuò)展幀還是標(biāo)準(zhǔn)幀處理取決于type變量。沒(méi)有給type賦為RT_CAN_STDID時(shí)驅(qū)動(dòng)按29位ID解析設(shè)備側(cè)當(dāng)然不認(rèn)。修復(fù)方式是發(fā)送前先強(qiáng)制指定幀類型同時(shí)把cob_id轉(zhuǎn)成標(biāo)準(zhǔn)ID格式tx_msg.type RT_CAN_STDID; tx_msg.id m-cob_id 0x7FF; // 確保只留低11位這個(gè)坑屬于典型的協(xié)議棧與驅(qū)動(dòng)之間的“上下文丟失”問(wèn)題。CanFestival在協(xié)議棧內(nèi)部已經(jīng)把標(biāo)準(zhǔn)幀和擴(kuò)展幀區(qū)分得非常清楚但到了驅(qū)動(dòng)層必須重新設(shè)置一遍。根源分析更深層的問(wèn)題是我在適配層拷貝報(bào)文結(jié)構(gòu)時(shí)沒(méi)有完整保存所有標(biāo)識(shí)字段。Message結(jié)構(gòu)體在不同版本CanFestival里有些成員是位域bitfield有些是普通UNS32。如果驅(qū)動(dòng)層對(duì)位域結(jié)構(gòu)理解不對(duì)打包出來(lái)的字節(jié)序就會(huì)錯(cuò)位。建議移植時(shí)直接從官方例程復(fù)制can_dcf.c去改不要自己憑感覺(jué)寫報(bào)文轉(zhuǎn)換函數(shù)。4.2 現(xiàn)象二SDO讀寫超時(shí)但PDO收發(fā)正常排查過(guò)程節(jié)點(diǎn)能被發(fā)現(xiàn)了心跳報(bào)文也正常但SDO讀驅(qū)動(dòng)器軟件版本號(hào)時(shí)一直超時(shí)。我一開始懷疑是SDO線程優(yōu)先級(jí)太低被PDO報(bào)文擠掉了于是把SDO線程優(yōu)先級(jí)提到了最高結(jié)果反而更嚴(yán)重——SDO超時(shí)頻繁電機(jī)偶爾一頓一頓。冷靜下來(lái)確認(rèn)了總線上實(shí)際跑的是什么。抓包發(fā)現(xiàn)SDO請(qǐng)求已經(jīng)發(fā)到總線上但響應(yīng)報(bào)文的COB-ID和我預(yù)期不一致導(dǎo)致協(xié)議棧在SDO層等待對(duì)應(yīng)ID的報(bào)文時(shí)一直收不到。查了驅(qū)動(dòng)器的對(duì)象字典發(fā)現(xiàn)SDO服務(wù)端配置里發(fā)送響應(yīng)用的節(jié)點(diǎn)ID被配置成了另一個(gè)地址。簡(jiǎn)單說(shuō)驅(qū)動(dòng)器的SDO服務(wù)端COB-ID是由“0x580 節(jié)點(diǎn)ID”組成的如果驅(qū)動(dòng)器側(cè)手動(dòng)改了節(jié)點(diǎn)相關(guān)的PDO/ SDO標(biāo)識(shí)主站按默認(rèn)規(guī)則算出來(lái)的ID就全對(duì)不上。解決辦法是在總線上電后先用一個(gè)固定的已知節(jié)點(diǎn)ID出廠默認(rèn)發(fā)起SDO讀獲取當(dāng)前節(jié)點(diǎn)的實(shí)際標(biāo)識(shí)配置然后重新映射主站的通信表。操作建議實(shí)際項(xiàng)目中我建議做個(gè)自動(dòng)掃描流程上電后逐個(gè)節(jié)點(diǎn)ID1到127發(fā)NMT節(jié)點(diǎn)啟動(dòng)命令同時(shí)監(jiān)聽心跳或Boot-up報(bào)文把響應(yīng)節(jié)點(diǎn)記錄下來(lái)。響應(yīng)表里列出來(lái)后再去做SDO配置。這個(gè)掃描流程也便于后續(xù)設(shè)備批量下載地址。4.3 現(xiàn)象三電機(jī)能轉(zhuǎn)但速度抖動(dòng)明顯排查過(guò)程SDO能讀PDO能跑控制字寫進(jìn)去電機(jī)也能轉(zhuǎn)了。但速度在低轉(zhuǎn)速比如300rpm下抖動(dòng)明顯示波器看編碼器反饋波形有周期性的毛刺。這是非常典型的同步問(wèn)題。我最初把SYNC幀周期設(shè)在5ms而驅(qū)動(dòng)器內(nèi)部的速度環(huán)周期是250us兩者差距太大每個(gè)同步周期之間的時(shí)間差導(dǎo)致速度積分漂移。把SYNC周期改成1ms然后把PDO的傳輸類型改成“同步周期1”抖動(dòng)立刻緩解了很多。但還有一點(diǎn)低頻波動(dòng)最后發(fā)現(xiàn)是RT-Thread里發(fā)送SYNC幀的定時(shí)器優(yōu)先級(jí)和SDO處理線程沖突。軟件定時(shí)器回調(diào)時(shí)不時(shí)晚幾百微秒導(dǎo)致SYNC的實(shí)際間隔時(shí)間不均勻。解決方案是不要用軟件定時(shí)器發(fā)SYNC改用一個(gè)獨(dú)立的硬件定時(shí)器PWM輸出模式或者把SYNC發(fā)送邏輯放到高優(yōu)先級(jí)中斷里。最穩(wěn)妥的方案是用RT-Thread的rt_timer設(shè)置更精細(xì)的周期或者直接用硬定時(shí)器中斷觸發(fā)rt_sem_release在專用線程里構(gòu)造SYNC幀發(fā)送。實(shí)測(cè)下來(lái)周期抖動(dòng)控制在±50us以內(nèi)就能滿足大多數(shù)伺服的速度平穩(wěn)性要求。排查鏈路總結(jié)這個(gè)環(huán)節(jié)的排查順序很重要先用邏輯分析儀抓總線波形確認(rèn)物理層和CAN控制器收發(fā)正常再看主站發(fā)出去的COB-ID和極幀類型是否匹配設(shè)備端配置然后看SDO事務(wù)數(shù)據(jù)鏈路是不是ID映射或數(shù)據(jù)長(zhǎng)度不一致最后才考慮從站的NMT節(jié)點(diǎn)初始化流程是否完整、心跳超時(shí)設(shè)置是否過(guò)短這套排查順序能幫你在四五個(gè)小時(shí)內(nèi)定位問(wèn)題而不是靠猜。5. 可靠性增強(qiáng)心跳監(jiān)測(cè)、故障恢復(fù)與后續(xù)演進(jìn)5.1 心跳監(jiān)測(cè)讓總線故障透明化CANopen的心跳機(jī)制Heartbeat通過(guò)每個(gè)節(jié)點(diǎn)周期性發(fā)送0x700node_id的報(bào)文向外報(bào)告“我還活著”。主站側(cè)收到任意節(jié)點(diǎn)的心跳報(bào)文后可以根據(jù)預(yù)先配置的心跳超時(shí)時(shí)間來(lái)判斷節(jié)點(diǎn)是否掉線。CanFestival里心跳超時(shí)事件通過(guò)定時(shí)器管理在OD的0x100C生產(chǎn)者心跳時(shí)間和0x1010/0x1011消費(fèi)心跳中配置。主站側(cè)要定期把所有節(jié)點(diǎn)的心跳超時(shí)清零并重新啟動(dòng)定時(shí)器。我采用了一個(gè)比協(xié)議棧自帶機(jī)制更直接的方式用RT-Thread的軟件定時(shí)器定期查詢?nèi)值男奶鵂顟B(tài)變量。每個(gè)節(jié)點(diǎn)在上電后配置完心跳周期后向0x1016和0x1017寫入期望值然后在協(xié)議?；卣{(diào)中遞增對(duì)應(yīng)的狀態(tài)計(jì)數(shù)器主線程每秒檢查計(jì)數(shù)器增量是否正常如果有節(jié)點(diǎn)超時(shí)未更新就觸發(fā)NMT復(fù)位和報(bào)警輸出。void canopen_heartbeat_check(void) { for (int i 1; i NODE_COUNT; i) { if (rt_tick_get() - node_heartbeat_tick[i] rt_tick_from_millisecond(1000)) { rt_kprintf(Node %d heartbeat lost!\n, i); // 觸發(fā)報(bào)警嘗試復(fù)位節(jié)點(diǎn) nmt_command(canopen_OD, NMT_RESET_NODE, i); } } }5.2 掉線自動(dòng)復(fù)位與故障恢復(fù)系統(tǒng)伺服驅(qū)動(dòng)器一旦觸發(fā)報(bào)警并停機(jī)主站需要按照DS402的狀態(tài)機(jī)要求執(zhí)行“故障復(fù)位”操作而不是直接發(fā)使能。這部分邏輯往往被初學(xué)者忽略故障復(fù)位是寫入控制字的0x80帶上升沿必須在寫入后保持一段時(shí)間的0x00才能正確清除故障狀態(tài)。很多人寫0x80就直接跳回0x06結(jié)果故障沒(méi)清除重新使能失敗。我封裝了這么一個(gè)函數(shù)int ds402_fault_reset(UNS16 node_id) { sdo_write_u16(node_id, 0x6040, 0x00, 0x80); rt_thread_mdelay(200); sdo_write_u16(node_id, 0x6040, 0x00, 0x00); rt_thread_mdelay(100); // 輪詢狀態(tài)字直到離開Fault狀態(tài) for (int i 0; i 10; i) { UNS16 status sdo_read_u16(node_id, 0x6041, 0x00); if ((status 0x10) 0) // bit40表示不在Fault狀態(tài) { return 0; } rt_thread_mdelay(200); } return -1; }主站側(cè)還要有一個(gè)總線級(jí)錯(cuò)誤處理機(jī)制。比如某一個(gè)從站掉線超過(guò)3秒系統(tǒng)自動(dòng)把另外幾個(gè)已使能的從站拉回到Ready狀態(tài)防止運(yùn)動(dòng)失控。這個(gè)互鎖邏輯我在RT-Thread的全局任務(wù)里實(shí)現(xiàn)優(yōu)先級(jí)低于PDO周期任務(wù)保證正常運(yùn)動(dòng)不受影響。5.3 后續(xù)演進(jìn)多主站冗余、CiA 402其他模式與協(xié)議棧升級(jí)這套主站框架跑穩(wěn)之后我計(jì)劃做幾件事接入CiA 402的Cyclic Synchronous PositionCSP模式。CSP模式下每個(gè)同步周期主站都要把目標(biāo)位置寫入RPDO驅(qū)動(dòng)器在內(nèi)部位置環(huán)做插值。這個(gè)模式對(duì)Sync幀周期抖動(dòng)的要求極高通常小于50us我打算把SYNC幀遷移到STM32的硬件定時(shí)器觸發(fā)上保證周期穩(wěn)定性。加了PROFINET轉(zhuǎn)CANopen網(wǎng)關(guān)。通過(guò)在應(yīng)用層增加一個(gè)上位機(jī)透?jìng)鹘涌诎裇DO/PDO數(shù)據(jù)映射為Modbus寄存器方便觸摸屏或PC組態(tài)軟件直接訪問(wèn)驅(qū)動(dòng)器參數(shù)。重新梳理CanFestival的NMT狀態(tài)管理?，F(xiàn)版本協(xié)議棧的主站NMT管理偏粗糙遇到多節(jié)點(diǎn)同時(shí)掉線時(shí)的恢復(fù)策略需要自己補(bǔ)。我計(jì)劃在應(yīng)用層實(shí)現(xiàn)兩個(gè)狀態(tài)表一個(gè)表示實(shí)際總線狀態(tài)一個(gè)表示應(yīng)用控制狀態(tài)兩者之間做狀態(tài)機(jī)轉(zhuǎn)換這樣能實(shí)現(xiàn)更精細(xì)的故障恢復(fù)流程。寫在最后CanFestival加RT-Thread這套組合做小型的CANopen主站絕對(duì)夠用。它的門檻主要在兩個(gè)地方一是協(xié)議棧的適配文件需要耐心調(diào)試特別是定時(shí)器和CAN接口二是DS402狀態(tài)機(jī)的理解不能拿普通Modbus那套“寫個(gè)寄存器就轉(zhuǎn)”的思路來(lái)對(duì)待。但一旦把這兩塊啃下來(lái)后面控制多少個(gè)軸都只是配置的問(wèn)題不會(huì)再像脈沖控制那樣被線纜拖累。如果讓我重新選一次我還是會(huì)走自研主站這條路。用現(xiàn)成的商業(yè)主站工具確實(shí)省事但黑盒調(diào)試在現(xiàn)場(chǎng)遇到問(wèn)題的時(shí)候那種無(wú)從下手的感覺(jué)才最要命。自己寫的協(xié)議棧適配每一個(gè)字節(jié)都是自己排過(guò)的出了問(wèn)題知道去哪里看這才是長(zhǎng)期項(xiàng)目最需要的底氣。本文還有配套的精品資源點(diǎn)擊獲取