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