摘要

穩(wěn)健的通信協(xié)議和接口在工業(yè)電機控制應(yīng)用中發(fā)揮著重要作用。在工業(yè)驅(qū)動應(yīng)用中，當(dāng)需要多個處理器元件來持續(xù)通信以完成復(fù)雜任務(wù)時，CANopen®因其易于集成、高度可配置，以及支持高效、可靠的實時數(shù)據(jù)交換等特性，受到了眾多工程師青睞。本文從低功耗電機控制應(yīng)用的角度深入探討CANopen。

控制器局域網(wǎng)的背景

控制器局域網(wǎng)(CAN)由Robert Bosch Gmbh于1983年研發(fā)，是一種高度穩(wěn)健的通信協(xié)議和接口，創(chuàng)建之初是為了克服RS232等傳統(tǒng)串行通信網(wǎng)絡(luò)的局限性，這些網(wǎng)絡(luò)無法支持多個控制器之間的實時通信。汽車行業(yè)要求多個傳感器連續(xù)同步傳輸數(shù)據(jù)，因而率先采用CAN。CAN允許多個節(jié)點使用短小的消息相互通信，因此成為汽車應(yīng)用的理想選擇。

隨著時間推移，CAN憑借其經(jīng)過驗證的穩(wěn)健性和諸多優(yōu)勢，在各行各業(yè)越來越受歡迎。然而，受限于專有編碼規(guī)則，利用CAN協(xié)議將來自不同供應(yīng)商的多個設(shè)備集成到單個系統(tǒng)中頗有挑戰(zhàn)性，有時甚至是天方夜譚。為了克服這一限制，自動化領(lǐng)域CAN (CiA)的國際用戶和制造商協(xié)會開發(fā)了一種高層協(xié)議CANopen。

本文接下來將探討CANopen協(xié)議架構(gòu)及其在控制多軸電機驅(qū)動器中的應(yīng)用。本文將深入探究這種高層通信協(xié)議的復(fù)雜之處及其對電機和運動控制領(lǐng)域的影響。為了讓讀者了解CANopen協(xié)議，我們會分析ADI Trinamic? TMCM-6212多軸電機控制器/驅(qū)動器模塊與QSH4218-35-10-027步進(jìn)電機的實時通信日志。具體來說，我們將重點關(guān)注網(wǎng)絡(luò)管理(NMT)狀態(tài)和基于客戶端-服務(wù)器的CANopen協(xié)議。此外，我們還將通過案例研究來展示如何解讀通信日志并確定驅(qū)動器的狀態(tài)。

CANopen架構(gòu)

本節(jié)講解CANopen協(xié)議的各種應(yīng)用原理，包括NMT和SDO（服務(wù)數(shù)據(jù)對象）。

網(wǎng)絡(luò)管理：NMT是CANopen中的關(guān)鍵通信原則，每個CANopen兼容設(shè)備都必須遵守。它作為狀態(tài)機運行，在協(xié)調(diào)CANopen框架內(nèi)的應(yīng)用方面發(fā)揮著重要作用。

網(wǎng)絡(luò)管理狀態(tài)機架構(gòu)：NMT狀態(tài)機如圖1所示，由三個不同的狀態(tài)組成，詳情如下：

初始化狀態(tài)

預(yù)運行狀態(tài)

運行狀態(tài)

圖1.NMT狀態(tài)機

客戶端節(jié)點承擔(dān)著監(jiān)督不同運行狀態(tài)下，相關(guān)服務(wù)器節(jié)點通信狀態(tài)的關(guān)鍵角色。這是通過實施NMT機制來實現(xiàn)的?？赏ㄟ^心跳和節(jié)點守護兩種不同方法，使客戶端節(jié)點能夠評估服務(wù)器節(jié)點的通信完整性。TMCM-6212采用心跳技術(shù)來驗證通信是否正確。每個節(jié)點利用對象1017h，以用戶可配置的循環(huán)時間間隔（以毫秒為單位）發(fā)出心跳信號。這種方式確保所有節(jié)點都處于活動狀態(tài)，可以進(jìn)行通信。

表1.NMT通信中的狀態(tài)配置

表1列出了不同通信狀態(tài)下使用的所有通信對象的組合。設(shè)備上電或復(fù)位后進(jìn)入初始化狀態(tài)時，會產(chǎn)生啟動消息。然后，設(shè)備轉(zhuǎn)換到預(yù)運行狀態(tài)，準(zhǔn)備好執(zhí)行期望的操作。在預(yù)運行狀態(tài)下，網(wǎng)絡(luò)中的所有節(jié)點可以傳輸與SDO、心跳/節(jié)點守護、緊急情況和時間/同步相關(guān)的所有對象。在運行狀態(tài)下，除了預(yù)運行狀態(tài)下可用的所有對象之外，還可以映射PDO對象。最后，在停止?fàn)顟B(tài)下，設(shè)備會禁用所有SDO和PDO對象的通信，僅允許執(zhí)行NMT命令。

服務(wù)數(shù)據(jù)對象：SDO通信協(xié)議主要用于NMT狀態(tài)機的預(yù)運行狀態(tài)。它以客戶端-服務(wù)器配置運行，其中客戶端可以訪問所有連接的服務(wù)器（節(jié)點）的對象字典中可用的所有對象。在該協(xié)議中，客戶端總是發(fā)起服務(wù)器的讀/寫事務(wù)，并由服務(wù)器確認(rèn)任務(wù)完成。此過程可確保SDO中的每個事務(wù)都得到確認(rèn)。

圖2顯示了多節(jié)點網(wǎng)絡(luò)中SDO協(xié)議的基于客戶端-服務(wù)器的配置。每個節(jié)點都被分配一個通道，通過該通道可以與客戶端進(jìn)行通信。在這種情況下，Trinamic TMCM-6212六步進(jìn)電機驅(qū)動器/控制器充當(dāng)服務(wù)器，而連接的PC充當(dāng)客戶端，發(fā)起與特定節(jié)點（本例中為NODE-1）的讀/寫事務(wù)。雖然所有節(jié)點都會收到SDO客戶端消息，但只有目標(biāo)節(jié)點會響應(yīng)，而其他服務(wù)器會忽略客戶端請求。

圖2.多節(jié)點SDO配置

服務(wù)數(shù)據(jù)對象數(shù)據(jù)報

圖2顯示了SDO數(shù)據(jù)報的完整結(jié)構(gòu)。SDO報頭由COB-ID（連接對象ID）組成，該ID是分配給特定任務(wù)（例如讀寫功能）的唯一編號。因此，SDO通信需要兩個COB-ID。第一個COB-ID代表客戶端上載/下載請求的NODE-ID+功能代碼，即600h + NODE-ID。第二個COB-ID（580h + NODE-ID）用于服務(wù)器的響應(yīng)。

圖3.SDO數(shù)據(jù)報結(jié)構(gòu)

SDO消息中的第一個字節(jié)為說明符，對于確定消息的性質(zhì)至關(guān)重要，可表明客戶端是打算寫入（下載）還是讀?。ㄉ蟼鳎?shù)據(jù)，而且還通過中止消息表示事務(wù)中的任何錯誤。說明符字節(jié)分為8位，如圖3所示。位7-5為客戶端命令說明符(CCS)，提供有關(guān)消息性質(zhì)的關(guān)鍵信息?？蛻舳嗣钫f明符根據(jù)客戶端的操作（例如讀取、寫入、分段/快速傳輸或事務(wù)中的錯誤）而有不同的配置。在服務(wù)器的響應(yīng)中，說明符（SCS，服務(wù)器命令說明符）的三位用于確定事務(wù)是否成功。表2列出了不同操作中CCS和SCS位的各種組合。說明符數(shù)據(jù)報中的位4是超過四字節(jié)的數(shù)據(jù)傳輸中使用的切換位。位3-2不包含任何數(shù)據(jù)，并且僅當(dāng)設(shè)置了位0-1時才有效。位1決定通過SDO通道傳輸?shù)南㈩愋停甘舅欠侄蝹鬏斶€是快速傳輸。在SDO數(shù)據(jù)報中，如圖3所示，最后四個字節(jié)專門用于存放需要傳輸?shù)臄?shù)據(jù)。如果數(shù)據(jù)超過四個字節(jié)，則會以分段方式發(fā)送。另一方面，如果SDO數(shù)據(jù)報包含完整數(shù)據(jù)，則其被視為快速傳輸。因此，位1為高電平表示快速傳輸，位1為低電平表示分段傳輸。在分段傳輸中，數(shù)據(jù)以數(shù)據(jù)包的形式傳輸。為了響應(yīng)客戶端的初始讀/寫請求，服務(wù)器在數(shù)據(jù)字段中提供數(shù)據(jù)大小。然后，隨著每個數(shù)據(jù)包傳輸?shù)娇蛻舳耍谒奈唬ㄇ袚Q位）開始切換。最后，如果說明符數(shù)據(jù)報中的位0已設(shè)置，則位3-2會指示數(shù)據(jù)大小，如前所述。

表2.CCS和SCS配置

SDO數(shù)據(jù)報中的字節(jié)2-3和4分別對應(yīng)索引和子索引字節(jié)，如圖3所示。這些字節(jié)用于訪問設(shè)備對象字典中可用的所有對象。對象字典包含所有設(shè)備參數(shù)，用戶可根據(jù)實時應(yīng)用需求配置設(shè)備的功能。通過設(shè)備剖析，無論是像驅(qū)動器這樣的控制設(shè)備，還是簡單的I/O器件，我們都可以實現(xiàn)行為標(biāo)準(zhǔn)化。如前所述，SDO數(shù)據(jù)報中的最后四個字節(jié)專門用于存放需要通過SDO層傳輸?shù)臄?shù)據(jù)。

一旦發(fā)生錯誤，SDO傳輸就會中止，傳輸停止的原因可以參考目標(biāo)設(shè)備手冊中提供的錯誤代碼解釋來確定。在這種情況下，CCS位的值為4，索引和子索引指定傳輸期間設(shè)備中受影響的參數(shù)，最后四個字節(jié)表示錯誤代碼。

實時通信分析

本節(jié)使用機器處于預(yù)運行狀態(tài)下的實時通信日志窗口來解釋SDO數(shù)據(jù)報。ADI Trinamic TMCM-6212六軸步進(jìn)電機驅(qū)動器/控制器4與QSH4218-35-10-027 [5]步進(jìn)電機配合使用。對于此設(shè)置，電機的最大電流（對象2003h）設(shè)置為200。利用目標(biāo)設(shè)置的軟件界面日志窗口中突出顯示的消息，客戶端和服務(wù)器之間的上傳和下載事務(wù)得到進(jìn)一步解釋，如圖4所示。

圖4.CANopen IDE

情形1：客戶端與服務(wù)器之間的下載操作

由客戶端發(fā)起：0x601：2f 03 20 c8 00 00 00（圖5）。

圖5.客戶端發(fā)起下載請求

服務(wù)器響應(yīng)：0x581：60 03 20 00 00 00 00（圖6）。

圖6.服務(wù)器的下載響應(yīng)

在圖6所示的操作中，CCS和SCS位的組合顯示了客戶端的成功寫入操作和服務(wù)器的響應(yīng)，這在表2中也有體現(xiàn)。

情形2：客戶端與服務(wù)器之間的上傳操作

由客戶端發(fā)起：0x601：40 03 20 00 00 00 00（圖7）。

圖7.客戶端發(fā)起上傳請求

服務(wù)器響應(yīng)：0x581：4f 03 20 00 c8 00 00 00（圖8）

圖8.服務(wù)器的上傳響應(yīng)

結(jié)論

CCS和SCS位的組合指示在客戶端和服務(wù)器之間成功執(zhí)行上傳操作。本文提到的示例可以推廣到設(shè)備對象字典中的其他對象，幫助我們深入了解機器的狀態(tài)。本次演示的主要目的是幫助用戶解讀通信日志并監(jiān)視驅(qū)動器的狀態(tài)。用戶可以實時排除錯誤，更高效地探索ADI Trinamic CANopen的高級特性。ADI產(chǎn)品中集成CANopen協(xié)議為客戶帶來了靈活性。客戶可以將自己的PLC與ADI Trinamic模塊集成，從而實現(xiàn)多供應(yīng)商系統(tǒng)的開發(fā)。此界面對于從事實驗室自動化、機器人、液體處理、半導(dǎo)體處理等復(fù)雜應(yīng)用領(lǐng)域的客戶特別有價值。本CANopen系列的下一篇文章將深入分析過程數(shù)據(jù)對象(PDO) CANopen協(xié)議，同時探索TMCM-6212針對電機控制應(yīng)用的更高級特性。

參考文獻(xiàn)

1Olaf Pfeiffer、Andrew Ayre和Christian Keydel，“采用CAN和CANopen的嵌入式網(wǎng)絡(luò)”，Copperhill Technologies Corporation，2008年。

2“TMCM-6212 CANopen固件手冊”，Trinamic Motion Control，2018年。