【導讀】穩(wěn)健的通信協(xié)議和接口在工業(yè)電機控制應用中發(fā)揮著重要作用。在工業(yè)驅(qū)動應用中，當需要多個處理器元件來持續(xù)通信以完成復雜任務時，CANopen?因其易于集成、高度可配置，以及支持高效、可靠的實時數(shù)據(jù)交換等特性，受到了眾多工程師青睞。本文從低功耗電機控制應用的角度深入探討CANopen。
摘要
穩(wěn)健的通信協(xié)議和接口在工業(yè)電機控制應用中發(fā)揮著重要作用。在工業(yè)驅(qū)動應用中，當需要多個處理器元件來持續(xù)通信以完成復雜任務時，CANopen?因其易于集成、高度可配置，以及支持高效、可靠的實時數(shù)據(jù)交換等特性，受到了眾多工程師青睞。本文從低功耗電機控制應用的角度深入探討CANopen。
控制器局域網(wǎng)的背景
控制器局域網(wǎng)(CAN)由Robert Bosch Gmbh于1983年研發(fā)，是一種高度穩(wěn)健的通信協(xié)議和接口，創(chuàng)建之初是為了克服RS232等傳統(tǒng)串行通信網(wǎng)絡的局限性，這些網(wǎng)絡無法支持多個控制器之間的實時通信。汽車行業(yè)要求多個傳感器連續(xù)同步傳輸數(shù)據(jù)，因而率先采用CAN。CAN允許多個節(jié)點使用短小的消息相互通信，因此成為汽車應用的理想選擇。
隨著時間推移，CAN憑借其經(jīng)過驗證的穩(wěn)健性和諸多優(yōu)勢，在各行各業(yè)越來越受歡迎。然而，受限于專有編碼規(guī)則，利用CAN協(xié)議將來自不同供應商的多個設備集成到單個系統(tǒng)中頗有挑戰(zhàn)性，有時甚至是天方夜譚。為了克服這一限制，自動化領域CAN (CiA)的國際用戶和制造商協(xié)會開發(fā)了一種高層協(xié)議CANopen。
本文接下來將探討CANopen協(xié)議架構及其在控制多軸電機驅(qū)動器中的應用。本文將深入探究這種高層通信協(xié)議的復雜之處及其對電機和運動控制領域的影響。為了讓讀者了解CANopen協(xié)議，我們會分析ADI Trinamic? TMCM-6212多軸電機控制器/驅(qū)動器模塊與QSH4218-35-10-027步進電機的實時通信日志。具體來說，我們將重點關注網(wǎng)絡管理(NMT)狀態(tài)和基于客戶端-服務器的CANopen協(xié)議。此外，我們還將通過案例研究來展示如何解讀通信日志并確定驅(qū)動器的狀態(tài)。
CANopen架構
本節(jié)講解CANopen協(xié)議的各種應用原理，包括NMT和SDO（服務數(shù)據(jù)對象）。
網(wǎng)絡管理：NMT是CANopen中的關鍵通信原則，每個CANopen兼容設備都必須遵守。它作為狀態(tài)機運行，在協(xié)調(diào)CANopen框架內(nèi)的應用方面發(fā)揮著重要作用。
網(wǎng)絡管理狀態(tài)機架構：NMT狀態(tài)機如圖1所示，由三個不同的狀態(tài)組成，詳情如下：
?初始化狀態(tài)
?預運行狀態(tài)
?運行狀態(tài)
圖1.NMT狀態(tài)機
客戶端節(jié)點承擔著監(jiān)督不同運行狀態(tài)下，相關服務器節(jié)點通信狀態(tài)的關鍵角色。這是通過實施NMT機制來實現(xiàn)的。可通過心跳和節(jié)點守護兩種不同方法，使客戶端節(jié)點能夠評估服務器節(jié)點的通信完整性。TMCM-6212采用心跳技術來驗證通信是否正確。每個節(jié)點利用對象1017h，以用戶可配置的循環(huán)時間間隔（以毫秒為單位）發(fā)出心跳信號。這種方式確保所有節(jié)點都處于活動狀態(tài)，可以進行通信。
初始化 預運行 運行 停止
啟動 ?
SDO ? ?
緊急情況 ? ?
同步/時間 ? ?
心跳/節(jié)點守護 ? ? ?
PDO（過程數(shù)據(jù)對象） ?
表1.NMT通信中的狀態(tài)配置
表1列出了不同通信狀態(tài)下使用的所有通信對象的組合。設備上電或復位后進入初始化狀態(tài)時，會產(chǎn)生啟動消息。然后，設備轉(zhuǎn)換到預運行狀態(tài)，準備好執(zhí)行期望的操作。在預運行狀態(tài)下，網(wǎng)絡中的所有節(jié)點可以傳輸與SDO、心跳/節(jié)點守護、緊急情況和時間/同步相關的所有對象。在運行狀態(tài)下，除了預運行狀態(tài)下可用的所有對象之外，還可以映射PDO對象。最后，在停止狀態(tài)下，設備會禁用所有SDO和PDO對象的通信，僅允許執(zhí)行NMT命令。
服務數(shù)據(jù)對象：SDO通信協(xié)議主要用于NMT狀態(tài)機的預運行狀態(tài)。它以客戶端-服務器配置運行，其中客戶端可以訪問所有連接的服務器（節(jié)點）的對象字典中可用的所有對象。在該協(xié)議中，客戶端總是發(fā)起服務器的讀/寫事務，并由服務器確認任務完成。此過程可確保SDO中的每個事務都得到確認。
圖2顯示了多節(jié)點網(wǎng)絡中SDO協(xié)議的基于客戶端-服務器的配置。每個節(jié)點都被分配一個通道，通過該通道可以與客戶端進行通信。在這種情況下，Trinamic TMCM-6212六步進電機驅(qū)動器/控制器充當服務器，而連接的PC充當客戶端，發(fā)起與特定節(jié)點（本例中為NODE-1）的讀/寫事務。雖然所有節(jié)點都會收到SDO客戶端消息，但只有目標節(jié)點會響應，而其他服務器會忽略客戶端請求。
圖2.多節(jié)點SDO配置
服務數(shù)據(jù)對象數(shù)據(jù)報
圖2顯示了SDO數(shù)據(jù)報的完整結(jié)構。SDO報頭由COB-ID（連接對象ID）組成，該ID是分配給特定任務（例如讀寫功能）的唯一編號。因此，SDO通信需要兩個COB-ID。第一個COB-ID代表客戶端上載/下載請求的NODE-ID+功能代碼，即600h + NODE-ID。第二個COB-ID（580h + NODE-ID）用于服務器的響應。
圖3.SDO數(shù)據(jù)報結(jié)構
SDO消息中的第一個字節(jié)為說明符，對于確定消息的性質(zhì)至關重要，可表明客戶端是打算寫入（下載）還是讀?。ㄉ蟼鳎?shù)據(jù)，而且還通過中止消息表示事務中的任何錯誤。說明符字節(jié)分為8位，如圖3所示。位7-5為客戶端命令說明符(CCS)，提供有關消息性質(zhì)的關鍵信息。客戶端命令說明符根據(jù)客戶端的操作（例如讀取、寫入、分段/快速傳輸或事務中的錯誤）而有不同的配置。在服務器的響應中，說明符（SCS，服務器命令說明符）的三位用于確定事務是否成功。表2列出了不同操作中CCS和SCS位的各種組合。說明符數(shù)據(jù)報中的位4是超過四字節(jié)的數(shù)據(jù)傳輸中使用的切換位。位3-2不包含任何數(shù)據(jù)，并且僅當設置了位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ù)包的形式傳輸。為了響應客戶端的初始讀/寫請求，服務器在數(shù)據(jù)字段中提供數(shù)據(jù)大小。然后，隨著每個數(shù)據(jù)包傳輸?shù)娇蛻舳?，第四位（切換位）開始切換。最后，如果說明符數(shù)據(jù)報中的位0已設置，則位3-2會指示數(shù)據(jù)大小，如前所述。
操作 客戶端請求(CCS) 服務器響應(SCS)
表2.CCS和SCS配置
SDO數(shù)據(jù)報中的字節(jié)2-3和4分別對應索引和子索引字節(jié)，如圖3所示。這些字節(jié)用于訪問設備對象字典中可用的所有對象。對象字典包含所有設備參數(shù)，用戶可根據(jù)實時應用需求配置設備的功能。通過設備剖析，無論是像驅(qū)動器這樣的控制設備，還是簡單的I/O器件，我們都可以實現(xiàn)行為標準化。如前所述，SDO數(shù)據(jù)報中的最后四個字節(jié)專門用于存放需要通過SDO層傳輸?shù)臄?shù)據(jù)。
一旦發(fā)生錯誤，SDO傳輸就會中止，傳輸停止的原因可以參考目標設備手冊中提供的錯誤代碼解釋來確定。在這種情況下，CCS位的值為4，索引和子索引指定傳輸期間設備中受影響的參數(shù)，最后四個字節(jié)表示錯誤代碼。
實時通信分析
本節(jié)使用機器處于預運行狀態(tài)下的實時通信日志窗口來解釋SDO數(shù)據(jù)報。ADI Trinamic TMCM-6212六軸步進電機驅(qū)動器/控制器4與QSH4218-35-10-027 [5]步進電機配合使用。對于此設置，電機的最大電流（對象2003h）設置為200。利用目標設置的軟件界面日志窗口中突出顯示的消息，客戶端和服務器之間的上傳和下載事務得到進一步解釋，如圖4所示。
圖4.CANopen IDE
情形1：客戶端與服務器之間的下載操作
由客戶端發(fā)起：0x601：2f 03 20 c8 00 00 00（圖5）。
圖5.客戶端發(fā)起下載請求
服務器響應：0x581：60 03 20 00 00 00 00（圖6）。
圖6.服務器的下載響應
在圖6所示的操作中，CCS和SCS位的組合顯示了客戶端的成功寫入操作和服務器的響應，這在表2中也有體現(xiàn)。
情形2：客戶端與服務器之間的上傳操作
由客戶端發(fā)起：0x601：40 03 20 00 00 00 00（圖7）。
圖7.客戶端發(fā)起上傳請求
服務器響應：0x581：4f 03 20 00 c8 00 00 00（圖8）
圖8.服務器的上傳響應
結(jié)論
CCS和SCS位的組合指示在客戶端和服務器之間成功執(zhí)行上傳操作。本文提到的示例可以推廣到設備對象字典中的其他對象，幫助我們深入了解機器的狀態(tài)。本次演示的主要目的是幫助用戶解讀通信日志并監(jiān)視驅(qū)動器的狀態(tài)。用戶可以實時排除錯誤，更高效地探索ADI Trinamic CANopen的高級特性。ADI產(chǎn)品中集成CANopen協(xié)議為客戶帶來了靈活性。客戶可以將自己的PLC與ADI Trinamic模塊集成，從而實現(xiàn)多供應商系統(tǒng)的開發(fā)。此界面對于從事實驗室自動化、機器人、液體處理、半導體處理等復雜應用領域的客戶特別有價值。本CANopen系列的下一篇文章將深入分析過程數(shù)據(jù)對象(PDO) CANopen協(xié)議，同時探索TMCM-6212針對電機控制應用的更高級特性。
參考文獻
1 Olaf Pfeiffer、Andrew Ayre和Christian Keydel，“采用CAN和CANopen的嵌入式網(wǎng)絡”，Copperhill Technologies Corporation，2008年。
2 “TMCM-6212 CANopen固件手冊”，Trinamic Motion Control，2018年。
（來源：ADI公司，作者：Atul Kumar，應用工程師）
免責聲明：本文為轉(zhuǎn)載文章，轉(zhuǎn)載此文目的在于傳遞更多信息，版權歸原作者所有。本文所用視頻、圖片、文字如涉及作品版權問題，請聯(lián)系小編進行處理。
推薦閱讀：
DigiKey與 Lippincott 合作品牌煥新項目榮獲2025年度 Graphis 設計大賽金獎
貿(mào)澤電子、Silicon Labs和Arduino聯(lián)手贊助2024 Matter挑戰(zhàn)賽比賽現(xiàn)已開放報名
