強韌的通訊協定與介面在工業馬達控制應用中扮演關鍵角色，這方面需要多個處理器組件持續進行通訊以完成各種複雜任務，而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機制來執行。心跳與節點保護這兩種方法論，讓從屬端節點能評估伺服端節點的通訊完整性。
在TMCM-6212的例子中，則是運用技巧來檢驗通訊的結果。每個節點經過使用者設定的週期時間間隔後就會發出一個心跳訊號，長度為毫秒等級，使用的物件為1017h。這種作法可確保所有節點都處於活躍與運行中的狀況可立即進行通訊。
表一：NMT通訊中的狀態組態
|
?
|
發起
|
預運行
|
運行
|
停止
|
|
啟動
|
?
|
?
|
?
|
?
|
|
SDO
|
?
|
?
|
?
|
?
|
|
緊急
|
?
|
?
|
?
|
?
|
|
同步/時間
|
?
|
?
|
?
|
?
|
|
心跳/節點保護
|
?
|
?
|
?
|
?
|
|
PDO （程序資料物件）
|
?
|
?
|
?
|
?
|
表一顯示在不同通訊狀態中所有用到的通訊物件的組合。當裝置在啟動電源或重置後進入發起狀態，它會產生一個啟動訊息。接著裝置會轉換到預運行狀態，準備就緒進行要執行的作業。
在預運行狀態中，網路中所有節點都能傳送和SDO有關的物件、心跳/節點保護、緊急、以及時間/同步等訊息。除了預運行狀態中所有可用的物件，也可對應PDO物件。最後，在停止狀態中，裝置會關掉所有SDO與PDO物件的通訊，並僅允許執行NMT命令。
服務資料物件: SDO 通訊協定主要用在NMT狀態機的預運行狀態。它在從屬端-伺服端的組態中運行，在此種組態中從屬端可存取所有連結伺服端（節點）物件字典中的物件。在這個協定中，從屬端永遠會與伺服端發起讀取/寫入交易，而伺服端則會告知傳輸任務已經完成。此種程序確保SDO中的每次交易都會發出確認訊息。
圖二顯示在多節點網路中SDO協定的從屬端-伺服端組態。每個節點都會被指派一個通道，透過這個通道就可以和從屬端進行通訊。在這個案例中，Trinamic TMCM-6212六軸步進馬達驅動器/控制器作為伺服端，而連結的PC則作為從屬端，在這個案例中是和指定節點亦即NODE-1發起讀取/寫入交易。雖然所有節點都會收到SDO從屬端訊息，但只有目標節點會做出回應，其他伺服端則會忽視從屬端的請求。
服務資料物件Datagram
圖二顯示SDO Datagram的完整結構。SDO表頭包含COB-ID（連結物件ID），這個獨一無二的數字指派給特定任務，像是讀取與寫入功能。因此，SDO通訊需要兩個COB-ID。第一個COB-ID代表 NODE-ID+ 功能代碼，用於從屬端的上傳/下載要求，亦即600h + NODE-ID。第二個COB-ID，580h+ NODE-ID，則是用於伺服端的要求
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的資料大小，如先前所述。
表二 CCS 與SCS 組態
|
作業
|
從屬端要求（CCS）
|
伺服端回應 （SCS）
|
|
SDO 下載
|
1
|
3
|
|
SDO 上傳
|
2
|
2
|
|
SDO 下載分段
|
0
|
1
|
|
SDO 上傳分段
|
3
|
0
|
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。這裡對從屬端與伺服端之間的上傳與下載交易作進一步的解說，使用的是目標設定的軟體介面中，在日誌視窗中標上亮光顏色的訊息，如圖四所示。
【案例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 應用工程師）
