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

由博世（Robert Bosch Gmbh）公司在1983年開發出的控制器區域網路（CAN）是一種高度強韌的通訊協定與介面。其設計宗旨是解決像是RS232此類傳統串列通訊網路的種種限制，以往一直面臨的關卡，是無法在多個控制器之間執行即時通訊。當時汽車產業率先採納CAN，因為汽車需要在多個感測器之間進行持續與同步的資料傳輸。CAN允許多個節點使用小訊息量相互通訊，因此使其適合用在各種汽車應用。

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

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

CANopen架構

本章節解說CANopen協定的各種應用原則，其中包括NMT與SDO（服務資料物件）

網路管理

NMT 是CANopen的關鍵通訊原則，每個CANopen相容裝置都必須遵循這個原則，其以狀態機的方式運作，在協調CANopen架構中各種應用方面扮演重要的角色。

網路管理狀態機架構

NMT狀態機如圖一所示，包含3個狀態：發起狀態、預運行狀態及運行狀態。

圖一 : NMT狀態機

從屬端節點扮演樞紐角色，負責監視相關伺服端節點在各個運行狀態下的通訊狀態。此方面是透過NMT機制來執行。心跳與節點保護這兩種方法論，讓從屬端節點能評估伺服端節點的通訊完整性。

在TMCM-6212的例子中，則是運用技巧來檢驗通訊的結果。每個節點經過使用者設定的週期時間間隔後就會發出一個心跳訊號，長度為毫秒等級，使用的物件為1017h。這種作法可確保所有節點都處於活躍與運行中的狀況可立即進行通訊。

圖二 : 多節點SDO 組態

服務資料物件Datagram

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

圖三 : SDO Datagram結構

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

其中3個位元（7-5）為從屬端命令指定符（CCS），其中提供有關訊息性質的關鍵資訊。從屬端命令指定符依據從屬端的作業會有不同的組態，像是讀取、寫入、分段/快速傳輸、或是交易中錯誤。在伺服端的回應方面，指定符的3個位元（SCS 伺服端命令指定符）指明了傳輸的成功狀態。

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

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

SDODatagram中的Bytes 2至3與4，分別對應到索引與子索引位元組，如圖三所示。這些位元組用來存取裝置物件字典中所有可用的物件。物件字典含有所有裝置參數，讓使用者能根據即時應用的需求來設定裝置的功能。這種裝置分析的概念為裝置帶來標準化的行為，它們會以控制驅動器或一個I/O元件的方式來控制裝置。SDODatagram的最後4個位元組指明了需要經過SDO層進行傳輸的資料，如先前所發展。

在發生錯誤時，SDO傳輸就會中止，要查明傳輸中止的原因，可查看目標裝置手冊所列的錯誤碼說明。在這個例子中，CCS位元值為4，索引與子索引指明了裝置在傳輸過程中受影響的各項參數，而最後4位元組則是錯誤代碼。

即時通訊分析

本節闡述SDODatagram，這裡使用即時通訊日誌視窗介面，而機器此時處在預運行狀態。ADI Trinamic TMCM-6212 六路步進馬達驅動器/控制器搭配QSH4218-35-10-027 [5]步進馬達。

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

圖四 : CANopen IDE整合開發介面

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

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

圖五 : 從屬端發起的下載要求

伺服端的回應 : 0x581: 60 03 20 00 00 00 00（圖六）

圖六 : 伺服端的下載回應

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

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

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

圖七 : 從屬端發起一個上傳要求

伺服端的回應 : 0x581: 4f 03 20 00 c8 00 00 00（圖八）

圖八 : 伺服端發起的上傳要求.

總結

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

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

（本文作者Atul Kumar為ADI 應用工程師）