CANOpen協(xié)議如何保證通訊不丟幀
摘要:如何讓現(xiàn)場總線通訊更加穩(wěn)定可靠,不丟失,這向來都是工程師們難以解決的問題。本文將運用國際規(guī)范的通訊協(xié)議來展示怎樣才能搭建好握手通訊。
服務(wù)數(shù)據(jù)對象SDO(Service data object)
SDO主要用于CANopen主站對從節(jié)點的參數(shù)配置。服務(wù)確認是SDO的最大的特點,為每個消息都生成一個應(yīng)答,確保數(shù)據(jù)傳輸?shù)臏蚀_性。如圖 1所示,這就像快遞,需要收方簽收后,給寄方發(fā)送一個已經(jīng)簽收的確認才算完成一次投遞。
圖 1 SDO與快遞簽收
在一個CANopen系統(tǒng)中,通常CANopen從節(jié)點作為SDO服務(wù)器,CANopen主節(jié)點作為客戶端(稱為CS通訊)。SDO客戶端通過索引和子索引,能夠訪問SDO服務(wù)器上的對象字典。這樣CANopen主節(jié)點可以訪問從節(jié)點的任意對象字典項的參數(shù),并且SDO也可以傳輸任何長度的數(shù)據(jù)(當(dāng)數(shù)據(jù)長度超過4個字節(jié)時就拆分成多個報文來傳輸)。
通訊原則(communication principle)
SDO的通訊原則非常單一,發(fā)送方(客戶端)發(fā)送CAN-ID為600h+Node-ID的報文,其中Node-ID為接收方(服務(wù)器)的節(jié)點地址,數(shù)據(jù)長度均為8字節(jié);
接收方(服務(wù)器)成功接收后,回應(yīng)CAN-ID為580h+Node-ID的報文。這里的Node-ID依然是接收方(服務(wù)器)的節(jié)點地址,數(shù)據(jù)長度均為8字節(jié)。如圖 2所示。
圖 2 SDO通訊原則
快速SDO協(xié)議(Expedited SDO protocol)
最常用最常見的SDO協(xié)議是快速SDO,所謂快速,就是1次來回就搞定。前提是讀取和寫入的值不能大于32位。如圖 3所示,為快速SDO協(xié)議的示意圖。命令中直接包含了要讀寫的索引、子索引、數(shù)據(jù)??芍^直接命中。
快速SDO的難點在于CS命令符的記憶,需要讀者收藏這個示意圖。
圖 3 快速SDO示意圖
通過快速SDO,可以直接對CANopen節(jié)點的對象字典中的值進行讀取和修改,所以在做參數(shù)配置之外,也經(jīng)常作為關(guān)鍵性數(shù)據(jù)傳輸之用。比如CANopen控制機器人的電機轉(zhuǎn)動角度時,就使用SDO來傳輸,保證可靠到達。
普通SDO協(xié)議(Normal SDO protocol)
當(dāng)需要傳輸?shù)闹党^32位時,就不能使用快速SDO傳輸。必須使用普通SDO進行分幀傳輸。在應(yīng)用中較少用到,一般用于CANopen節(jié)點的程序固件升級,或者做網(wǎng)關(guān)轉(zhuǎn)換MVB總線之類數(shù)據(jù)最大可達256位的應(yīng)用。
普通SDO協(xié)議難點在于分包邏輯與CS命令符的變化。依然難以記憶,需要讀者將以下示意圖進行收藏。
當(dāng)然普通SDO的CAN幀ID與快速SDO相同,依然發(fā)送方(客戶端)發(fā)送的報文CAN-ID為600h+Node-ID,接收方(服務(wù)器)成功接收后,回應(yīng)CAN-ID為580h+Node-ID的報文。
下載協(xié)議download protocol 如圖 4所示。
圖 4 普通SDO下載協(xié)議
上傳協(xié)議upload protocol 如圖 5所示。
圖 5 普通SDO上傳協(xié)議