CANopen的起源，CANopen從何而來？

1. CANopen的起源，CANopen從何而來？

德國Bosch公司于1983年研發(fā)CAN協議，用于汽車傳動系統的網絡通訊。之后稱為國際標準ISO11898，目前CANopen由非營利組織CiA（CAN in Automaion）進行標準的起草及審核工作，基本的 CANopen 設備及通訊子協定定義在 CAN in Automation (CiA) draft standard 301. 中。針對個別設備的子協定以 CiA 301 為基礎再進行擴充，如針對 I/O 模組的 CiA401 及針對運動控制的 CiA402。

2. CANopen硬件的優(yōu)勢？

CAN協議最大的突出特點是錯誤檢測，限制和處理。當CAN設備檢測到總線錯誤時，會拒絕之前接收到的位序列，然后發(fā)送“錯誤幀”，其完全由CAN芯片本身處理，不需要人為編程。

支持多主站，類似Profibus DP，總線上每個設備都是主站，也是從站，免除了人為仲裁的過程，方便用戶開發(fā)。

報文短幀結構，CAN報文通常只有8個字節(jié)，數據幀非常短，在抗干擾能力上具有先天的優(yōu)勢。解釋一下，為什么短幀結構抗干擾好？如果通訊報文長，發(fā)送一幀耗時也就長，假如遇到干擾，辛辛苦苦好不容發(fā)送了一條報文，結果因為干擾對方還沒有收到，只能嚎啕大哭。

成本低廉，CAN外設基本在現在主流芯片上都可以找到，20幾塊錢的MCU都支持CAN外設，有的還支持兩個CAN。這里有CiA的積極推廣作用。

3. CANopen軟件優(yōu)勢？

CANopen主要有CiA在推廣，是非盈利組織，CANopen協議資料，網上一堆，任何人都可以下載到，我們常用的DS301（Draft Standand），DS402，CAN粉絲幾乎人手一本，猶如葵花寶典，一定要珍藏一本。

CANopen協議開發(fā)，開源項目非常多，CanFestival就是其中一個，我做過移植，在步科MT4414TE-CAN觸摸屏，用在8位單片機上，此源碼有點耗費資源，網上有很多基于MCU的精簡源碼。

開發(fā)完整的CANopen協議棧，是很艱辛的工作，想要做好非常難。難點就在于你對CANopen協議的理解上，比如EMCY，復位節(jié)點，是否需要“NO Initialization”，heartbeat，Node guard是否需要？如何處理？這條不能算是其優(yōu)點。

4. 為什么如此多公司在推廣CANopen？

CANopen對于運動控制來說是一款優(yōu)秀的通訊協議，采用了面向對象的一些設計思路，比如對象字典，過程數據對象（PDO），服務數據對象（SDO）等等。

CANopen在歐洲已成為最普通的協議，任何一家自動化公司都有CANopen的通訊接口，也成了低配。低配并不代表不好，只是說明其性價比更高。CANopen定義了完整的同步控制機制，使其成為主流的運動控制協議，除了在CAN總線上運行外，還被搬到了以太網上（CANopen over Ethernet），形成了著名的PowerLink，EtherCat工業(yè)以太網協議。

在這里多廢話幾句，所謂的運動控制總線標準，沒有多大意義，因為運動控制技術都掌握在各個廠商手里，每一個稍微大一點的廠商，都有自己的專用運動控制協議，如三菱的SSCNET，安川的MECHATROLINK，倍福的CANOPEN以及EtherCat，施耐德的CANopen，西門子的SiMotion，貝加萊的PowerLink，博世力士樂的SERCOS。

由于CANopen（可以看DS402，伺服控制標準）在運動控制的優(yōu)勢，尤其是同步控制，不管幾流的廠商，在運動控制系統中，多多少少都加入了自己的東西，導致運動控制系統通常是封閉的，很少走互聯路線，事實上要做到互聯也非常困難。

二三流廠家，開發(fā)自己的CANopen協議，根據自己的需求，將其移至到不同的物理層上去運行，形成自己的運動控制系統，其性能優(yōu)劣就在于其對CANopen協議的理解程度了。

基礎：CANopen世界里的九個晦澀概念

1. DCF

是CAN網絡的配置（Config）的數據存檔文件。其作用不大，在Codesys軟件里就有此選項。

2. EDS

電子數據表格，是描述一臺從站設備的屬性，參數的文件，是對從站設備對象字典的描述。比如一臺伺服驅動器，如果其內部參數（每個參數對應對象字典中的一個位置，由index，sub-index決定）沒有更改，其對應的EDS文件就不會更改。多說一句，不是所有的主控制器都需要使用EDS，比如Beckhoff就不需要，他需要你對CANopen DS301，DS402足夠熟悉，人工對齊配置；步科FD，JD伺服按照DS402標準制定EDS文件，用戶可直接配置，降低開發(fā)周期。

3. 復位節(jié)點

當設備遇到異常（如從站斷線后重連，使用M258測試步科FD伺服），主控會發(fā)送“復位節(jié)點”，步科的ED伺服復位節(jié)點，驅動器恢復出廠值，而且連CAN通訊參數也恢復成默認值。FD，JD伺服是除了CAN通訊參數外，其他配置參數恢復出廠值。

4. EMCY

緊急報文，從站如伺服，在斷電后會發(fā)送一條緊急報文，告訴主控其狀態(tài)，一般伺服斷電后，其電容電量能保證其發(fā)送該條報文。

5. 心跳，節(jié)點保護

配置心跳參數，設置心跳周期，心跳消費時間，這個消費者時間實際上是作為一個超時參數。主站收到一個心跳后，開始計時，如果在超時時間內沒有收到下一個心跳，則認為從站離線，并報告錯誤，按照用戶配置的錯誤處理方法處理。

網絡中的每個節(jié)點都可以配置心跳，主站可以監(jiān)聽從站，從站可以監(jiān)聽主站，從站還可以監(jiān)聽從站。這里有一個生產者、消費者的概念，總線上的設備定義自己是心跳的生產者，還是消費者。生產者產生心跳，消費者監(jiān)聽心跳，然后在捕捉到異常后做出對應的處理。

個人認為心跳作用不大，假設某個設備斷線，重連后復位節(jié)點，而此設備剛好是使用了原點功能的伺服呢？斷電上電后，原點位置改變。所以在一些客戶應用中，出現此情況，小伙子，你麻利的，趕快斷電重啟吧。

節(jié)點保護，其作用類似心跳，但可以讀取從站設備的CANopen通訊狀態(tài)（初始化，預操作，操作中，停止），屬于DS301的范疇。

6. DS301和DS402的區(qū)別

DS301就是一個通訊協議棧，DS402是建立在DS301的上層協議，屬于伺服類的控制協議，協議中規(guī)定好每個對象字典值得作用，比如0x6040，是控制字。DS402把一個伺服應該具有的功能都定義好了，開發(fā)廠家按照協議定義即可。

7. 對象字典

從軟件的角度來說，對象字典本質就是一些數據結構的集合?？梢赃@么理解，把對象字典看做是一本書，CANopen設備的行為準則是要參考這本書的，不管它做什么，只要它的行為要參考對象字典，就必須先查閱字典，再決定要不要做。比如它什么時候發(fā)送TPDO，這個行為是需要查詢對象字典中對應于TPDO的傳輸類型以及Event timer。還有就是像PDO映射的原理，比如我要發(fā)送的數據，都是去查詢這本書，看下它那里寫的什么內容，然后我在把這部分內容以PDO的形式發(fā)送出去。

例如你的程序收到了一筆CAN報文，由于可以訪問對象字典的對象是SDO，首先要判斷它是SDO對象，那么你的程序就需要按照SDO中指定的索引和子索引去查找對象字典（一個排好序的數據結構集），找到相應的對象后按照SDO中的指令去操作這個對象，例如把一個值賦給字典中的變量。

8. SDO

這個很簡單，就是類似串口的一發(fā)一回模式，主站發(fā)送請求幀，從站回復應答幀。

大家看幾個例子就明白了。

To write the 1 byte data : 0xFD in the object dictionary of node 5, at index 0x1400, subindex 2, sends :

605 2F 00 14 02 FD 00 00 00

If success, the node 5 responds :

585 60 00 14 02 00 00 00 00

To write the 4 bytes data : 0x60120208 in the object dictionary of node 5, at index 0x1603, subindex 1, sends :

605 23 03 16 01 08 02 12 60

If success, the node 5 responds :

585 60 03 16 01 00 00 00 00

9. PDO

分為TX-PDO，RX-PDO。

上圖，這就是PDO的配置過程，0x1402（接收PDO通訊參數），PDO使用的cob-id，傳輸類型，Inhibit time，EventTimer。

0x1602（映射對象），上例中映射為Controlword，Target position。

這里著重講一下Transmission Type，上述是codesys中支持的集中方式：

acyclic sync（數值為0）：同步PDO，同步方式由具體設備協議定義

Cyclic sync（數值為1-240）：同步PDO，每個N個SYNC周期后，發(fā)送PDO

Sync rtr（數值253）：同步PDO，收到遠程幀請求后發(fā)送PDO

Async（數值253）：異步PDO，收到遠程幀后發(fā)送PDO

最后兩個Async（254,255），都是設備廠家定義的，也是大家最常用的，當事件發(fā)生時發(fā)送。各個廠家在這里基本都是使用數據變化時發(fā)送方式，FD，JD伺服兩種方法是一樣的，都是數據變化發(fā)送。要注意設置“禁止時間”，降低CANOPEN通訊帶寬。

具體案例

主控制器寫target position，mode of operation給伺服，此PDO的cob-id為0x200 node id。傳輸方式為255或者254，禁止時間為100，也就是10ms。

審核編輯 ：李倩