強(qiáng)韌的通訊協(xié)定與介面在工業(yè)馬達(dá)控制應(yīng)用中扮演關(guān)鍵角色，這方面需要多個(gè)處理器組件持續(xù)進(jìn)行通訊以完成各種複雜任務(wù)，而CANopen具備易於整合和高度可設(shè)定性，還提供高效率且可靠的即時(shí)資料交換機(jī)制，本文將從低功耗馬達(dá)控制應(yīng)用的層面切入深入探討CANopen。

由博世（Robert Bosch Gmbh）公司在1983年開發(fā)出的控制器區(qū)域網(wǎng)路（CAN）是一種高度強(qiáng)韌的通訊協(xié)定與介面。其設(shè)計(jì)宗旨是解決像是RS232此類傳統(tǒng)串列通訊網(wǎng)路的種種限制，以往一直面臨的關(guān)卡，是無法在多個(gè)控制器之間執(zhí)行即時(shí)通訊。當(dāng)時(shí)汽車產(chǎn)業(yè)率先採納CAN，因?yàn)槠囆枰诙鄠€(gè)感測器之間進(jìn)行持續(xù)與同步的資料傳輸。CAN允許多個(gè)節(jié)點(diǎn)使用小訊息量相互通訊，因此使其適合用在各種汽車應(yīng)用。

通過實(shí)際應(yīng)用驗(yàn)證且具備諸多利益的CAN，歷經(jīng)長久發(fā)展至今已廣獲眾多產(chǎn)業(yè)採納。然而由於存在專利程式開發(fā)的規(guī)範(fàn)，因此想要將不同廠商的多個(gè)元件透過CAN協(xié)定整合到一個(gè)系統(tǒng)中，不僅在實(shí)務(wù)上困難重重，有時(shí)甚至完全無法達(dá)成。為了克服這項(xiàng)限制，CAN in Automation（CiA）組織的各國使用者和多個(gè)製造業(yè)協(xié)會(huì)著手發(fā)展一個(gè)名為CANopen的高層次通訊協(xié)定。

在以下章節(jié)中，將探討CANopen協(xié)定架構(gòu)，以及其在控制多軸馬達(dá)趨動(dòng)器方面的各種應(yīng)用，文中將深入闡述這個(gè)高階層通訊協(xié)定，以及其對馬達(dá)與馬達(dá)控制領(lǐng)域的影響。藉由分析ADI Trinamic TMCM-6212多軸馬達(dá)控制器/驅(qū)動(dòng)器模組與QSH4218-35-10-027步進(jìn)馬達(dá)的即時(shí)通訊日誌，將為讀者提供CANopen協(xié)定的詳盡說明，並專注探討網(wǎng)路管理（NMT）狀態(tài)，以及從屬端-伺服端架構(gòu)的CANopen協(xié)定。此外，文中將透過多個(gè)案例研究展示如何解譯通訊日誌，以及判斷驅(qū)動(dòng)器的狀態(tài)。

CANopen架構(gòu)

本章節(jié)解說CANopen協(xié)定的各種應(yīng)用原則，其中包括NMT與SDO（服務(wù)資料物件）

網(wǎng)路管理

NMT 是CANopen的關(guān)鍵通訊原則，每個(gè)CANopen相容裝置都必須遵循這個(gè)原則，其以狀態(tài)機(jī)的方式運(yùn)作，在協(xié)調(diào)CANopen架構(gòu)中各種應(yīng)用方面扮演重要的角色。

網(wǎng)路管理狀態(tài)機(jī)架構(gòu)

NMT狀態(tài)機(jī)如圖一所示，包含3個(gè)狀態(tài)：發(fā)起狀態(tài)、預(yù)運(yùn)行狀態(tài)及運(yùn)行狀態(tài)。

圖一 : NMT狀態(tài)機(jī)

從屬端節(jié)點(diǎn)扮演樞紐角色，負(fù)責(zé)監(jiān)視相關(guān)伺服端節(jié)點(diǎn)在各個(gè)運(yùn)行狀態(tài)下的通訊狀態(tài)。此方面是透過NMT機(jī)制來執(zhí)行。心跳與節(jié)點(diǎn)保護(hù)這兩種方法論，讓從屬端節(jié)點(diǎn)能評估伺服端節(jié)點(diǎn)的通訊完整性。

在TMCM-6212的例子中，則是運(yùn)用技巧來檢驗(yàn)通訊的結(jié)果。每個(gè)節(jié)點(diǎn)經(jīng)過使用者設(shè)定的週期時(shí)間間隔後就會(huì)發(fā)出一個(gè)心跳訊號，長度為毫秒等級，使用的物件為1017h。這種作法可確保所有節(jié)點(diǎn)都處於活躍與運(yùn)行中的狀況可立即進(jìn)行通訊。

圖二 : 多節(jié)點(diǎn)SDO 組態(tài)

服務(wù)資料物件Datagram

圖二顯示SDO Datagram的完整結(jié)構(gòu)。SDO表頭包含COB-ID（連結(jié)物件ID），這個(gè)獨(dú)一無二的數(shù)字指派給特定任務(wù)，像是讀取與寫入功能。因此，SDO通訊需要兩個(gè)COB-ID。第一個(gè)COB-ID代表 NODE-ID+ 功能代碼，用於從屬端的上傳/下載要求，亦即600h + NODE-ID。第二個(gè)COB-ID，580h+ NODE-ID，則是用於伺服端的要求

圖三 : SDO Datagram結(jié)構(gòu)

SDO訊息的第一個(gè)位元組，亦即指定符，在判斷訊息性質(zhì)方面扮演關(guān)鍵的角色。它不僅指明了從屬端是否有意要寫入（下載）或讀取（上傳）資料，也會(huì)透過中止訊息反映出傳輸過程中的任何錯(cuò)誤。指定符位元組分成8個(gè)位元，如圖三所示。

其中3個(gè)位元（7-5）為從屬端命令指定符（CCS），其中提供有關(guān)訊息性質(zhì)的關(guān)鍵資訊。從屬端命令指定符依據(jù)從屬端的作業(yè)會(huì)有不同的組態(tài)，像是讀取、寫入、分段/快速傳輸、或是交易中錯(cuò)誤。在伺服端的回應(yīng)方面，指定符的3個(gè)位元（SCS 伺服端命令指定符）指明了傳輸?shù)某晒顟B(tài)。

表二列出CCS與SCS位元對於不同作業(yè)的各種組合。指定符Datagram中的Bit 4是切換位元，用在超過4個(gè)位元組的資料傳輸。Bits 3-2 不含任何資料，而且只有在bits 0-1設(shè)定後才會(huì)有效。Bit 1指明了透過SDO通道傳輸訊息的種類，指明其屬於分段或是快速傳輸。如圖三所示，在SDO Datagram中，最後4個(gè)位元組指明了需要被傳輸?shù)馁Y料。如果資料超過4位元組，系統(tǒng)就會(huì)以分段的方式進(jìn)行傳輸。

另一種狀況是，如果SDODatagram含有完整的資料，系統(tǒng)就會(huì)考量採用快速傳輸。因此，如果bit 1處於高位（high），就指明是快速傳輸，而低位（low）位元?jiǎng)t指明是分段傳輸。在分段傳輸中，資料會(huì)透過多個(gè)封包進(jìn)行傳輸。伺服端在回應(yīng)從屬端發(fā)起的讀取/寫入要求時(shí)，會(huì)提供資料欄位中的資料大小，然後第4位元（切換位元）會(huì)開始將每個(gè)資料封包切換傳輸至從屬端。最後，如果指定符Datagram中的bit 0已經(jīng)設(shè)定，它會(huì)指明bit 3至2的資料大小，如先前所述。

SDODatagram中的Bytes 2至3與4，分別對應(yīng)到索引與子索引位元組，如圖三所示。這些位元組用來存取裝置物件字典中所有可用的物件。物件字典含有所有裝置參數(shù)，讓使用者能根據(jù)即時(shí)應(yīng)用的需求來設(shè)定裝置的功能。這種裝置分析的概念為裝置帶來標(biāo)準(zhǔn)化的行為，它們會(huì)以控制驅(qū)動(dòng)器或一個(gè)I/O元件的方式來控制裝置。SDODatagram的最後4個(gè)位元組指明了需要經(jīng)過SDO層進(jìn)行傳輸?shù)馁Y料，如先前所發(fā)展。

在發(fā)生錯(cuò)誤時(shí)，SDO傳輸就會(huì)中止，要查明傳輸中止的原因，可查看目標(biāo)裝置手冊所列的錯(cuò)誤碼說明。在這個(gè)例子中，CCS位元值為4，索引與子索引指明了裝置在傳輸過程中受影響的各項(xiàng)參數(shù)，而最後4位元組則是錯(cuò)誤代碼。

即時(shí)通訊分析

本節(jié)闡述SDODatagram，這裡使用即時(shí)通訊日誌視窗介面，而機(jī)器此時(shí)處在預(yù)運(yùn)行狀態(tài)。ADI Trinamic TMCM-6212 六路步進(jìn)馬達(dá)驅(qū)動(dòng)器/控制器搭配QSH4218-35-10-027 [5]步進(jìn)馬達(dá)。

在這個(gè)設(shè)定中，馬達(dá)的最大電流（Object 2003h） 設(shè)為200。這裡對從屬端與伺服端之間的上傳與下載交易作進(jìn)一步的解說，使用的是目標(biāo)設(shè)定的軟體介面中，在日誌視窗中標(biāo)上亮光顏色的訊息，如圖四所示。

圖四 : CANopen IDE整合開發(fā)介面

【案例1】從屬端與伺服端之間的下載作業(yè)

從屬端發(fā)起: 0x601: 2f 03 20 c8 00 00 00（圖五）

圖五 : 從屬端發(fā)起的下載要求

伺服端的回應(yīng) : 0x581: 60 03 20 00 00 00 00（圖六）

圖六 : 伺服端的下載回應(yīng)

在圖六所示的作業(yè)中，CCS與SCS位元的組合顯示了從屬端的成功寫入以及伺服端的回應(yīng)，如表二所示。

【案例2】從屬端與伺服端之間的上傳作業(yè)

由從屬端發(fā)起: 0x601: 40 03 20 00 00 00 00（圖七）.

圖七 : 從屬端發(fā)起一個(gè)上傳要求

伺服端的回應(yīng) : 0x581: 4f 03 20 00 c8 00 00 00（圖八）

圖八 : 伺服端發(fā)起的上傳要求.

總結(jié)

CCS結(jié)合SCS位元就指示了從屬端與之間成功完成上傳作業(yè)。本文的例子亦可套用在裝置的物件字典，提供反映機(jī)器狀態(tài)的分析訊息。

此項(xiàng)展示的主要目的是讓使用者能解讀通訊日誌的內(nèi)容，以及監(jiān)視驅(qū)動(dòng)器的狀態(tài)。使用者可即時(shí)排除各種錯(cuò)誤，以及更有效率地探索ADI Trinamic CANopen的先進(jìn)功能。將CANopen協(xié)定整合到ADI的產(chǎn)品，讓客戶有充裕的彈性整合自己的PLC與ADI Trinamic模組，促成多廠商系統(tǒng)的發(fā)展。對於工作涉及實(shí)驗(yàn)室自動(dòng)化、機(jī)器人、液體處理、半導(dǎo)體處理等複雜應(yīng)用的客戶而言，此項(xiàng)介面特別寶貴。CANopen系列後續(xù)專文將深入分析程序資料物件（PDO） CANopen協(xié)定，以及探索TMCM-6212在馬達(dá)控制應(yīng)用方面更多先進(jìn)功能。

（本文作者Atul Kumar為ADI 應(yīng)用工程師）