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