標題: 如何設計通訊方式能夠更加可靠 [打印本頁]
作者: hubaba 時間: 2016-3-28 15:32
標題: 如何設計通訊方式能夠更加可靠
摘要
每一種通訊都有其短板的地方，這就需要一些特殊的處理方式來彌補，本文將運用國際規范的通訊協議來展示怎樣才能讓控制更加可靠。
特殊協議（Special protocols）
為了方便CANopen主站對從站管理。在CANopen協議中，已經為特殊的功能預定義了COB-ID，其主要有以下幾種特殊報文。
同步協議（Sync protocol）
同步（SYNC），該報文對象主要實現整個網絡的同步傳輸，如圖 1所示，就像閱兵分列式上的方陣，所有士兵邁著整齊的步伐行進。
圖1 同步協議與閱兵分列式
每個節點都以該同步報文作為PDO觸發參數，因此該同步報文的COB-ID 具有比較高的優先級以及最短的傳輸時間。 一般選用80h作為同步報文的CAN-ID，如圖2所示。
圖2 同步報文
一般同步報文由NMT主機發出，CAN報文的數據為0字節。但如果一個網絡內有2個同步機制，就需要設置不同的同步節拍，比如某些節點按1個同步幀發送1次PDO，其他的節點收到2個同步幀才發送1此PDO，所以這里PDO參數中的同步起始值就起了作用。
在同步協議中，有2個約束條件：
- 同步窗口時間：索引1007h約束了同步幀發送后，從節點發送PDO的時效，即在這個時間內發送的PDO才有效，超過時間的PDO將被丟棄；
- 通訊循環周期：索引1006h規定了同步幀的循環周期。
時間戳協議（Time-stamp protocol）
時間標記對象（Time Stamp），NMT主機發送自身的時鐘，為網絡各個節點提供公共的時間參考，即網絡對時，如圖3所示。這在故障診斷中非常需要，比如列車中火災報警，檢修人員需要準確獲知報警的時刻，然后關聯查看其它設備在這個時刻的工作狀態。
圖3 時間戳協議與校時
時間戳協議采用廣播方式，無需節點應答，CAN-ID為100h，數據長度為6，數據為當前時刻與1984年1月1日0時的時間差。如圖 4所示。節點將此時間存儲在對象字典1012h的索引中。
圖4 時間戳協議
由于時間換算起來非常費勁，這里特地準備好了換算函數，方便讀者使用。
緊急報文協議（Emergency protocol）
緊急事件對象（Emergency），是當設備內部發生錯誤，觸發該對象，發送設備內部錯誤代碼，提示NMT主站。緊急報文屬于診斷性報文，一般不會影響CANopen通訊，其CAN-ID存儲在1014h的索引中，一般會定義為080h +node-ID，數據包含8個字節，如圖5所示。
圖5 緊急報文
其中包括EEC：緊急時間錯誤代碼，ER：錯誤寄存器，MEF：廠商自定義的錯誤代碼。當然這些都需要查表才能獲知，進行診斷。
表1 Emergency error codes（緊急報文錯誤代碼）
與PDO的生產禁止時間類似，緊急報文也有生產禁止時間，存儲在對象字典的1015h中，為了限制節點不斷發送緊急報文，導致總線負載過大。
USBCAN-E-P與PCI-5010-P主站卡可為PC機拓展出CANOpen通訊接口，實現CANOpen協議的數據通信。作為CANOpen網絡的管理者，實現全部的CANOpen網絡管理（NMT）功能。
| 歡迎光臨 (http://www.denmoz.com/bbs/) |
Powered by Discuz! X3.1 |
