CANOpen協(xié)議如何保證通訊不丟幀

　　摘要：如何讓現場(chǎng)總線(xiàn)通訊更加穩定可靠，不丟失，這向來(lái)都是工程師們難以解決的問(wèn)題。本文將運用國際規范的通訊協(xié)議來(lái)展示怎樣才能搭建好握手通訊。

　　服務(wù)數據對象SDO(Service data object)

　　SDO主要用于CANopen主站對從節點(diǎn)的參數配置。服務(wù)確認是SDO的最大的特點(diǎn)，為每個(gè)消息都生成一個(gè)應答，確保數據傳輸的準確性。如圖 1所示，這就像快遞，需要收方簽收后，給寄方發(fā)送一個(gè)已經(jīng)簽收的確認才算完成一次投遞。

　　圖 1 SDO與快遞簽收

　　在一個(gè)CANopen系統中，通常CANopen從節點(diǎn)作為SDO服務(wù)器，CANopen主節點(diǎn)作為客戶(hù)端(稱(chēng)為CS通訊)。SDO客戶(hù)端通過(guò)索引和子索引，能夠訪(fǎng)問(wèn)SDO服務(wù)器上的對象字典。這樣CANopen主節點(diǎn)可以訪(fǎng)問(wèn)從節點(diǎn)的任意對象字典項的參數，并且SDO也可以傳輸任何長(cháng)度的數據(當數據長(cháng)度超過(guò)4個(gè)字節時(shí)就拆分成多個(gè)報文來(lái)傳輸)。

　　通訊原則(communication principle)

　　SDO的通訊原則非常單一，發(fā)送方(客戶(hù)端)發(fā)送CAN-ID為600h+Node-ID的報文，其中Node-ID為接收方(服務(wù)器)的節點(diǎn)地址，數據長(cháng)度均為8字節;

　　接收方(服務(wù)器)成功接收后，回應CAN-ID為580h+Node-ID的報文。這里的Node-ID依然是接收方(服務(wù)器)的節點(diǎn)地址，數據長(cháng)度均為8字節。如圖 2所示。

　　圖 2 SDO通訊原則

　　快速SDO協(xié)議(Expedited SDO protocol)

　　最常用最常見(jiàn)的SDO協(xié)議是快速SDO，所謂快速，就是1次來(lái)回就搞定。前提是讀取和寫(xiě)入的值不能大于32位。如圖 3所示，為快速SDO協(xié)議的示意圖。命令中直接包含了要讀寫(xiě)的索引、子索引、數據?？芍^直接命中。

　　快速SDO的難點(diǎn)在于CS命令符的記憶，需要讀者收藏這個(gè)示意圖。

　　圖 3 快速SDO示意圖

　　通過(guò)快速SDO，可以直接對CANopen節點(diǎn)的對象字典中的值進(jìn)行讀取和修改，所以在做參數配置之外，也經(jīng)常作為關(guān)鍵性數據傳輸之用。比如CANopen控制機器人的電機轉動(dòng)角度時(shí)，就使用SDO來(lái)傳輸，保證可靠到達。

　　普通SDO協(xié)議(Normal SDO protocol)

　　當需要傳輸的值超過(guò)32位時(shí)，就不能使用快速SDO傳輸。必須使用普通SDO進(jìn)行分幀傳輸。在應用中較少用到，一般用于CANopen節點(diǎn)的程序固件升級，或者做網(wǎng)關(guān)轉換MVB總線(xiàn)之類(lèi)數據最大可達256位的應用。

　　普通SDO協(xié)議難點(diǎn)在于分包邏輯與CS命令符的變化。依然難以記憶，需要讀者將以下示意圖進(jìn)行收藏。

　　當然普通SDO的CAN幀ID與快速SDO相同，依然發(fā)送方(客戶(hù)端)發(fā)送的報文CAN-ID為600h+Node-ID，接收方(服務(wù)器)成功接收后，回應CAN-ID為580h+Node-ID的報文。

　　下載協(xié)議download protocol 如圖 4所示。

　　圖 4 普通SDO下載協(xié)議

　　上傳協(xié)議upload protocol 如圖 5所示。

　　圖 5 普通SDO上傳協(xié)議