電機控制中的高層協議——CANopen
我們說從OSI 網路模型的角度來看同,現場匯流排網路一般只實現了第1層( 物理層),第2層(數據鏈路層)、第7層(應用層)。 為什麼不見3,4,5,6層呢?
因為現場匯流排通常只包括一個網段,因此不需要第3層(傳輸層)和第4層(網路層),也不需要第 5 層(會話層)第 6 層(描述層)的作用。
在實際的設計中,物理層和數據鏈路層,這兩層完全由硬體實現,設計人員無需為此開發相關軟體(Software)或固件(Firmware)。同時,由於CAN只定義物理層和數據鏈路層, 沒有規定應用層,本身並不完整,需要一個高層協議來定義CAN報文中的 11/29 位標識符、8 位元組數據的使用。
而且,基於CAN匯流排的工業自動化應用中,越來越需要一個開放的、標準化的高層協議: 這個協議應該可以支持各種CAN 廠商設備的互用性、互換性,並且希望它能夠實現在CAN網路中提供標準的、統一的系統通訊模式,提供設備功能描述方式,執行網路管理功能。
今天我要介紹給大家的是基於CAN 的高層協議: CAL 協議和基於CAL 協議擴展的 CANopen 協議。CANopen協議是 CAN-in-Automation(CiA)定義的標準之一, 並且在發布後不久就獲得了廣泛的承認。 尤其是在歐洲,CANopen 協議被認為是在基於 CAN 的工業系統中佔領導地位的標準。
CiA官網:CAN in Automation (CiA): Controller Area Network (CAN)
在 OSI 模型中,CAN標準、CANopen 協議之間的關係如下圖所示:
大多數重要的設備類型,例如數字和模擬的輸入輸出模塊、驅動設備、操作設備、控制器、可編程式控制制器或編碼器,都在稱為「設備描述」的協議中進行描述;「設備描述」 定義了不同類型的標準設備及其相應的功能。 依靠 CANopen 協議的支持,可以對不同廠商的設備通過匯流排進行配置。CAL 協議
CAL( CAN Application Layer)協議是目前基於CAN的高層通訊協議中的一種【見附1】,最早由 Philips 醫療設備部門制定。現在 CAL 由獨立的 CAN 用戶和製造商集團 CiA( CAN in Automation) 協會負責管理、發展和推廣。
CAL(CAN Application Layer)協議是目前基於CAN的高層通訊協議中的一種,最早由 Philips醫療設備部門制定。現在CAL由獨立的CAN 用戶和製造商集團 CiA(CAN in Automation) 協會負責管理、 發展和推廣。CAL 提供了4 種應用層服務功能:
1.CMS (CAN-based Message Specification)CMS 提供了一個開放的、面向對象的環境,用於實現用戶的應用。CMS 提供基於變數、事件、域類型的對象,以設計和規定一個設備(節點)的功能如何被訪問(例如,如何上載下載超過8位元組的一組數據(域),並且有終止傳輸的功能)。CMS 從 MMS (Manufacturing Message Specification)繼承而來。MMS 是OSI 為工業設備的遠程控制和監控而制定的應用層規範。
2.NMT (Network ManagemenT)提供網路管理(如初始化、啟動和停止節點,偵測失效節點) 服務。這種服務是採用主從通訊模式(所以只有一個 NMT 主節點)來實現的。3. DBT (DistriBuTor)提供動態分配 CAN ID(正式名稱為 COB-ID, Communication Object Identifier)服務。這種服務是採用主從通訊模式(所以只有一個 DBT 主節點)來實現的。4. LMT (Layer ManagemenT)LMT 提供修改層參數的服務: 一個節點( LMT Master) 可以設置另外一個節點( LMT Slave)的某層參數(如改變一個節點的 NMT 地址,或改變 CAN 介面的位定時和波特率)。CANopen
CAL 提供了所有的網路管理服務和報文傳送協議,但並沒有定義 CMS 對象的內容或者正在通訊的對象的類型(它只定義了how,沒有定義what)。而這正是 CANopen 切入點。
CANopen 是在 CAL 基礎上開發的, 使用了 CAL 通訊和服務協議子集, 提供了分散式控制系統的一種實現方案。 CANopen 在保證網路節點互用性的同時允許節點的功能隨意擴展:或簡單或複雜。CANopen 的核心概念是設備對象字典 (OD:Object Dictionary),在其它現場匯流排 ( Profibus, Interbus-S)系統中也使用這種設備描述形式。注意:對象字典不是 CAL 的一部分,而是在CANopen中實現的。
總結
基於 CAN 匯流排的 CANopen 網路通訊具有以下特點:
- 使用對象字典( OD: Object Dictionary)對設備功能進行標準化的描述。z 使用 ASCII 文檔: 電子數據文檔( EDS) 和設備配置文件( DCF) 對設備及其配置進行標準化的描述。
- CANopen 網路的數據交換和系統管理基於 CAL 中 CMS 服務。
參考資料:《CANopen: high-level protocol for CAN-bus》
高校裡面電機控制目前大多使用的控制器是TI公司的28335,下面就具體看看 Introduction to the Controller Area Network (CAN)
The CAN Bus
The data link and physical signaling layers, which are normally transparent to a systemoperator, are included in any controller that implements the CAN protocol,such as TI"s TMS320LF28123.3-V DSP with integrated CAN controller.Connection to the physical medium is then implementedthrough a line transceiver (收發器)such as TI"s SN65HVD230 3.3-V CAN transceiver to form a system node .SN65HVD230 中文資料
The two signal lines of the bus, CANH and CANL, in the quiescent recessive state, are passively biased to≈ 2.5 V. The dominant state on the bus takes CANH ≈ 1 V higher to ≈ 3.5 V, and takes CANL ≈ 1 V lowerto ≈ 1.5 V, creating a typical 2-V differential signal.
The CAN standard defines a communication network that links all the nodes connected to a bus andenables them to talk with one another. There may or may not be a central control node, and nodes maybe added at any time, even while the network is operating (hot-plugging).具體使用28335如何開發eCAN可以參考一下帖子。
如何利用CANopen控制伺服電機? - 電子技術
【TI博客大賽】TMS320F28335之eCAN
————————————————————————
附1:一些可使用的 CAN 高層協議:
制定組織 主要高層協議
CiA CAL 協議
CiA CANOpen 協議ODVA DeviceNet 協議Honeywell SDS 協議Kvaser CANKingdom 協議】附2:標準CAN和擴展CAN
標準 CAN 的標誌符長度是 11 位,而擴展格式 CAN 的標誌符長度可達 29 位。
CAN 協議的 2.0A 版本規定 CAN 控制器必須有一個 11 位的標誌符。同時,在2.0B 版本中規定, CAN 控制器的標誌符長度可以是 11 位或 29 位。遵循 CAN2.0B 協議的 CAN 控制器可以發送和接收11位標識符的標準格式報文或29位標識符的擴展格式報文。 如果禁止 CAN2.0B則CAN 控制器只能發送和接收11位標識符的標準格式報文,而忽略擴展格式的報文結構,但不會出現錯誤。
附3:CiA簡介
CiA 全稱為「CAN in Automation-國際用戶和廠商協會,在德國 Erlangen 註冊。CiA 總部位於 Erlangen,並由 CiA 董事會建立各個辦事處。
1992 年,為促進CAN以及 CAN 協議的發展,歐洲的一些公司組成一個商業協會,提供 CAN的技術,產品以及市場信息。到 2002 年 6 月時, 共有約 400 家公司加入了這個協會,協作開發和支持各類 CAN 高層協議。經過近十年的發展,該協會已經為全球應用 CAN 技術的權威。推薦閱讀: