顧開祥,姜智銳,杜國(guó)斌,邵鵬程
(上海中廣核工程科技有限公司,上海, 200241)
風(fēng)力發(fā)電作為能源主力軍之一,在2020年持續(xù)維持高景氣度,根據(jù)國(guó)家能源局公布的數(shù)據(jù),繼2010年以來(lái),我國(guó)風(fēng)電新增裝機(jī)連續(xù)保持世界第一。全行業(yè)的產(chǎn)品升級(jí)迭代和科技進(jìn)步不斷得到推進(jìn),總線技術(shù)在風(fēng)電項(xiàng)目中得到大量的應(yīng)用。從OSI網(wǎng)絡(luò)模型的角度來(lái)看同,現(xiàn)場(chǎng)總線網(wǎng)絡(luò)一般只實(shí)現(xiàn)了第 1 層(物理層)、第2 層(數(shù)據(jù)鏈路層)、第7層(應(yīng)用層)。因?yàn)楝F(xiàn)場(chǎng)總線通常只包括一個(gè)網(wǎng)段,因此不需要第 3 層(傳輸層)和第4層(網(wǎng)層),也不需要第5層(會(huì)話層)第6層(描述層)的作用。
其中CAN(Controller Area Network) 現(xiàn)場(chǎng)總線僅僅定義了第1層、第2 層(見ISO11898標(biāo)準(zhǔn));實(shí)際設(shè)計(jì)中,這兩層完全由硬件實(shí)現(xiàn),設(shè)計(jì)人員無(wú)需再為此開發(fā)相關(guān)軟件(Software)或固件(Firmware)?;?CAN 的高層協(xié)議:CAL 協(xié)議和基于 CAL 協(xié)議擴(kuò)展的 CANopen 協(xié)議。CANopen協(xié)議是 CAN-in-Automation(CiA)定義的標(biāo)準(zhǔn)之一, 并且在發(fā)布后不久就獲得了廣泛的承認(rèn)。相較于其他總線,由于CAN總線技術(shù)在通訊速率、通訊距離、錯(cuò)誤處理能力等方面的綜合優(yōu)點(diǎn),提高了系統(tǒng)的實(shí)時(shí)性、可靠性與靈活性,因此在現(xiàn)場(chǎng)設(shè)備中得到廣泛運(yùn)用。
這部分內(nèi)容主要闡述系統(tǒng)的總體設(shè)計(jì),根據(jù)實(shí)際采用的PPC硬件、軟件操作系統(tǒng)及Codesys軟件給出總體設(shè)計(jì)方案,明確設(shè)計(jì)過程中的技術(shù)要點(diǎn)。并結(jié)合CANopen開源協(xié)議棧,通過分析該協(xié)議框架后,給出使用方法。CANopen從站系統(tǒng)主要是為上層應(yīng)用程序提供PDO數(shù)據(jù)交互功能。該功能實(shí)現(xiàn)主要包括以下部分:
(1)用戶程序的PDO數(shù)據(jù)交互實(shí)現(xiàn)是基于Vxworks和Codesys組件接口程序,實(shí)際的CANopen協(xié)議報(bào)文在PPC硬件上以驅(qū)動(dòng)的形式實(shí)現(xiàn)。
(2)CANopen協(xié)議部分的PDO、SDO、NMT等協(xié)議應(yīng)用實(shí)現(xiàn)是基于開源CANopen協(xié)議。通過將該協(xié)議棧移植到PPC控制器上,來(lái)完成CAN應(yīng)用層功能。
(3)CANopen協(xié)議報(bào)文由CAN鏈路層的發(fā)送或接收完成,通過PPC硬件控制CAN鏈路層控制芯片和CAN的PHY芯片,最終實(shí)現(xiàn)與外部CAN主站的數(shù)據(jù)交互。
CANopen總線網(wǎng)絡(luò)由一個(gè)主設(shè)備和多個(gè)從設(shè)備構(gòu)成分布系統(tǒng),每個(gè)節(jié)點(diǎn)設(shè)備通過不同的COB-ID為標(biāo)識(shí)。在Codesys應(yīng)用程序開發(fā)過程中,可根據(jù)實(shí)際項(xiàng)目的開發(fā)將系統(tǒng)中任意滿足協(xié)議要求的數(shù)據(jù)通過調(diào)用組件接口將其傳到CANopen協(xié)議棧中對(duì)應(yīng)的TPDO映射變量,同樣也可通過調(diào)用組件接口獲取協(xié)議棧中相應(yīng)的RPDO映射變量的數(shù)據(jù)。以該形式即可完成CAN主站設(shè)備和CAN從站設(shè)備間的PDO交互。總體設(shè)計(jì)如圖1所示。
圖1 總體設(shè)計(jì)框圖
關(guān)于如何保證主從站數(shù)據(jù)交互的可靠性與實(shí)時(shí)性要求。其中可靠性主要依賴RPDO、TPDO預(yù)定義規(guī)則,即每個(gè)PDO對(duì)應(yīng)地址中的數(shù)據(jù)定義是確定,其次CANopen開源協(xié)議的可靠性是經(jīng)過很多平臺(tái)測(cè)試驗(yàn)證的。實(shí)時(shí)性要求,開源棧協(xié)議實(shí)現(xiàn)是基于Vxworks任務(wù)調(diào)度的強(qiáng)實(shí)時(shí)性及相關(guān)定時(shí)或信號(hào)傳遞等資源的低延時(shí)的基礎(chǔ)上完成的,故實(shí)時(shí)性是能達(dá)到要求的。
CANopen 是 在 CAL基礎(chǔ)上開發(fā)的,使用了CAL 通訊和服務(wù)協(xié)議子集,提供了分布式控制系統(tǒng)的一種實(shí)現(xiàn)方案。CANopen在保證網(wǎng)絡(luò)節(jié)點(diǎn)互用性的同時(shí)允許節(jié)點(diǎn)的功能隨意擴(kuò)展:或簡(jiǎn)單或復(fù)雜。
CANopen的核心概念是設(shè)備對(duì)象字典(OD:Object Dictionary),在其他現(xiàn)場(chǎng)總線( Profibus, Interbus-S)系統(tǒng)中也使用這種設(shè)備描述形式。注意:對(duì)象字典不是 CAL的一部分,而是在 CANopen 中實(shí)現(xiàn)的。在 OSI 模型中,CAN標(biāo)準(zhǔn)、CANopen 協(xié)議之間的關(guān)系如圖2所示。
圖2 CAN標(biāo)準(zhǔn)、CANopen 協(xié)議關(guān)系圖
CANopen從站功能實(shí)現(xiàn)如下3種協(xié)議報(bào)文(通訊對(duì)象):
(1)網(wǎng)絡(luò)管理報(bào)文:負(fù)責(zé)CAN網(wǎng)絡(luò)的管理和 設(shè)備ID 分配服務(wù):如初始化,配置和網(wǎng)絡(luò)管理(包括:節(jié)點(diǎn)保護(hù))。
(2)服務(wù)數(shù)據(jù)對(duì)象 SDO(Service Data Object):通過使用索引和子索引, SDO 使客戶機(jī)能夠訪問設(shè)備(服務(wù)器)對(duì)象字典中的項(xiàng)(對(duì)象)。協(xié)議是確認(rèn)服務(wù)類型:為每個(gè)消息生成一個(gè)應(yīng)答。
(3)過程數(shù)據(jù)對(duì)象 PDO( Process Data Object):用來(lái)傳輸實(shí)時(shí)數(shù)據(jù), 數(shù)據(jù)從一個(gè)生產(chǎn)者傳到一個(gè)或多個(gè)消費(fèi)者。數(shù)據(jù)傳送限制在 1 到 8 個(gè)字節(jié)。
從站硬件的搭建主要分為三個(gè)部分,首先是控制器使用的是PPC架構(gòu)的單核控制器主頻450M;其次是CAN的控制采用的是飛利浦的PCA82C200芯片,將欲收發(fā)的消息(報(bào)文),轉(zhuǎn)換為符合CAN規(guī)范的CAN幀,通過CAN收發(fā)器,在CAN-bus上交換信息;最后是CAN收發(fā)器部分采用的是MAX305 1芯片,主要實(shí)現(xiàn)CAN控制器的邏輯電平轉(zhuǎn)換為CAN總線的差分電平,在兩條有差分電壓的總線電纜上傳輸數(shù)據(jù)。CAN從站硬件實(shí)現(xiàn)如圖3所示。
圖3 CAN從站硬件實(shí)現(xiàn)框圖
控制器系統(tǒng)的軟件開發(fā)采用WindRiver公司的Tornado2.2集成開發(fā)環(huán)境, 操作系統(tǒng)版本為Vxworks 5.5.1。軟件實(shí)現(xiàn)均基于模塊化的設(shè)計(jì),包括移植CANopen開源協(xié)議棧的應(yīng)用程序。CANopen從站的軟件框圖如圖4所示。
圖4 CAN從站軟件實(shí)現(xiàn)框圖
2.3.1 CAN底層驅(qū)動(dòng)程序?qū)崿F(xiàn)
這部分工作主要是完成PCA82C200CAN控制器的控制實(shí)現(xiàn),通過對(duì)該CAN控制器內(nèi)部REG的讀寫操作完成芯片的參數(shù)配置初始化、總線狀態(tài)監(jiān)測(cè)、報(bào)文收發(fā)等。該芯片初始化實(shí)現(xiàn)函數(shù)PCA_Init()、REG讀操作函數(shù)PCA_REG_Read()、REG寫操作函數(shù)PCA_REG_Write()等。CAN芯片初始化部分實(shí)現(xiàn),流程圖如5所示。
關(guān)于控制器的CAN報(bào)文發(fā)送,底層報(bào)文的傳輸是由PCA82C200獨(dú)立完成的,主控制器(PPC)將需發(fā)送的數(shù)據(jù)寫入CAN控制器寄存器中,CAN控制器首先會(huì)把數(shù)據(jù)放到緩沖區(qū)里,通過查詢或中斷的方式來(lái)判斷數(shù)據(jù)的發(fā)送是否完成。完成時(shí)對(duì)應(yīng)的寄存器狀態(tài)字會(huì)被置為1或中斷會(huì)被觸發(fā)。本設(shè)計(jì)是基于查詢的方式實(shí)現(xiàn)的。首先通過輪詢確定當(dāng)前發(fā)送緩沖區(qū)是否空閑,接著寫發(fā)送緩沖區(qū)。具體如流程圖6所示。
圖5 CAN芯片初始化流程圖
圖6 CAN報(bào)文發(fā)送流程圖
關(guān)于CAN控制器報(bào)文接收,當(dāng)控制器接收到報(bào)文時(shí)會(huì)將數(shù)據(jù)放到接收緩沖區(qū)中,實(shí)現(xiàn)方式與發(fā)送一樣均有兩種方式,本設(shè)計(jì)數(shù)據(jù)接收采用的是中斷的方式,當(dāng)控制器觸發(fā)接收中斷條件后,會(huì)觸發(fā)相關(guān)中斷,同時(shí)數(shù)據(jù)會(huì)存放到接收緩存中。當(dāng)接收完數(shù)據(jù)后需要清除相關(guān)的中斷狀態(tài),等待下次接收中斷的觸發(fā)。具體實(shí)現(xiàn)流程如流程圖7所示。
圖7 CAN報(bào)文接收流程圖
2.3.2 驅(qū)動(dòng)接口實(shí)現(xiàn)
關(guān)于驅(qū)動(dòng)接口實(shí)
現(xiàn),本設(shè)計(jì)與采用的嵌入式操作系統(tǒng)有關(guān),同時(shí)需要兼顧C(jī)ANopen協(xié)議棧接口。根據(jù)協(xié)議棧的設(shè)計(jì),調(diào)用CAN底層驅(qū)動(dòng)接口函數(shù)即可控制底層硬件。功能實(shí)現(xiàn)框圖如圖8所示。該過程需加載CAN驅(qū)動(dòng),主要包含以下接口:CAN口的打開、關(guān)閉、數(shù)據(jù)收發(fā)及波特率的設(shè)置。
圖8 驅(qū)動(dòng)功能實(shí)現(xiàn)框圖
2.3.2.1 系統(tǒng)定時(shí)器機(jī)制
在開源協(xié)議棧實(shí)現(xiàn)中,很多的接口交互都與定時(shí)器有關(guān),交互的實(shí)時(shí)性取決于定時(shí)器的精度,這直接決定了從站功能實(shí)現(xiàn)的可靠性。故在PPC架構(gòu)中實(shí)現(xiàn)CANopen從站功能首先需要解決定時(shí)問題。基于Vxworks提供的精準(zhǔn)軟定時(shí)器和信號(hào)量,完成協(xié)議棧中時(shí)間調(diào)度程序。在創(chuàng)建的任務(wù)中調(diào)用延時(shí)接口完成對(duì)協(xié)議棧的時(shí)間調(diào)度任務(wù)。
2.3.2.2 驅(qū)動(dòng)接口函數(shù)
該部分是實(shí)現(xiàn)的是協(xié)議棧與底層驅(qū)動(dòng)的接口函數(shù),基于底層操作的基本接口實(shí)現(xiàn),可用于上層應(yīng)用對(duì)底層的控制。驅(qū)動(dòng)與協(xié)議棧主要實(shí)現(xiàn)內(nèi)容包含CAN設(shè)備的打開、關(guān)閉、讀、寫操作。該驅(qū)動(dòng)為字符設(shè)備驅(qū)動(dòng),利用Vxworks I/O系統(tǒng)為用戶程序提供統(tǒng)一接口,使得上層應(yīng)用程序與底層硬件相互獨(dú)立。
2.4.1 CANopen開源協(xié)議棧介紹
現(xiàn)市場(chǎng)上主流的CANopen開源協(xié)議棧主要有MicroCANOPEN、CANOPENNode和CANFestival三種。使用開源協(xié)議棧可以減少開發(fā)難度和降低開發(fā)周期,且開源協(xié)議棧總線功能齊全。本實(shí)現(xiàn)選擇CANFestival協(xié)議棧,該協(xié)議棧編寫于2001年,已經(jīng)過若干項(xiàng)目驗(yàn)證至今,代碼成熟度很高。該協(xié)議相比較于其他的開源協(xié)議有如下優(yōu)點(diǎn):
(1)該開源協(xié)議棧完全符合國(guó)際協(xié)議標(biāo)準(zhǔn)并支持CIADS-301,功能上相對(duì)完整。
(2)該開源協(xié)議棧已在多種平臺(tái)上完成了移植,應(yīng)用廣泛可靠性高。協(xié)議棧的實(shí)現(xiàn)是基于標(biāo)準(zhǔn)C,可移植性強(qiáng)且官方相關(guān)支持資料完善。
(3)該協(xié)議棧的操作使用簡(jiǎn)單易上手,比如開發(fā)人員可根據(jù)實(shí)際項(xiàng)目對(duì)對(duì)象字典進(jìn)行隨意配置。
在CANFestiva協(xié)議中,全部源碼可分為4部分:目標(biāo)接口程序、CAN驅(qū)動(dòng)接口程序、協(xié)議庫(kù)文件及CAN主從站的用戶程序。在協(xié)議庫(kù)文件中主要包含三點(diǎn):調(diào)度管理、節(jié)點(diǎn)管理及核心協(xié)議代碼。高層協(xié)議包含SDO、PDO、NMT、SYNC等,關(guān)于這部分程序的移植是不用做任何修改,關(guān)于主從節(jié)點(diǎn)主要包含節(jié)點(diǎn)的狀態(tài)反饋及對(duì)象字典的定義。對(duì)于開發(fā)人員需要修改的代碼工作量主要在硬件驅(qū)動(dòng)適配及與操作系統(tǒng)的接口適配上。
SDO報(bào)文、同步報(bào)文、心跳報(bào)文等是需要通過定時(shí)器功能的支持,可通過操作系統(tǒng)的軟件定時(shí)功能來(lái)實(shí)現(xiàn),主要得益于Vxworks具有很好的實(shí)時(shí)性,無(wú)需硬件定時(shí)器也能可靠的出觸發(fā)關(guān)報(bào)文的發(fā)送。CANFestival開源協(xié)議中各代碼結(jié)構(gòu)功能關(guān)系如圖9所示。
圖9 CANOPEN各代碼結(jié)構(gòu)功能關(guān)系圖
2.4.2 CANopen應(yīng)用層功能實(shí)現(xiàn)
CANopen應(yīng)用協(xié)議是基于CiA標(biāo)準(zhǔn)設(shè)計(jì)的,以為主從站的硬件連接、硬件接口定義,軟件接口定義給出明確的說(shuō)明。主從站的通訊報(bào)文及對(duì)象字典,采用結(jié)構(gòu)化的方法。數(shù)據(jù)的交互雙方設(shè)備按照對(duì)象字典的設(shè)定即可,而對(duì)象字典內(nèi)容可根據(jù)主索引與子索引來(lái)查詢。
2.4.2.1 從協(xié)議棧應(yīng)用主流程
程序上電后,首先是創(chuàng)建相關(guān)任務(wù)并初始化通訊參數(shù),對(duì)相應(yīng)的數(shù)據(jù)進(jìn)行更新。完成相關(guān)初始化后,從站設(shè)備會(huì)自動(dòng)發(fā)起啟動(dòng)設(shè)備報(bào)文(boot_up)給主站設(shè)備,接著從站設(shè)備按照協(xié)議規(guī)范進(jìn)入預(yù)操作模式。下一步從設(shè)備將進(jìn)入?yún)f(xié)議棧的主任務(wù),最后通過周期性查詢接收?qǐng)?bào)文并逐條解析,主任務(wù)根據(jù)解析內(nèi)容判斷該報(bào)文控制從設(shè)備運(yùn)行狀態(tài)。根據(jù)解析報(bào)文進(jìn)入不同的階段處理函數(shù),完成相應(yīng)的交互處理。如果主任務(wù)一直沒有收到主站設(shè)備請(qǐng)求報(bào)文,從站依然按照設(shè)備描述文件上傳相關(guān)PDO報(bào)文。主站接收到從站報(bào)文后,同樣會(huì)按照規(guī)則進(jìn)行解析后,進(jìn)入相關(guān)處理函數(shù)。
如果主站配置了節(jié)點(diǎn)守護(hù)功能,主站設(shè)備會(huì)按照設(shè)定的周期時(shí)間,向從站設(shè)備發(fā)送節(jié)點(diǎn)守護(hù)報(bào)文。節(jié)點(diǎn)守護(hù)報(bào)文實(shí)際就是CAN的遠(yuǎn)程幀,當(dāng)從設(shè)備被收到該報(bào)文后,進(jìn)行解析,判斷報(bào)文類型,再進(jìn)入相關(guān)的處理子函數(shù)進(jìn)行處理。該處理方式就是回復(fù)一個(gè)標(biāo)準(zhǔn)幀,數(shù)據(jù)長(zhǎng)度為一個(gè)字節(jié)。其中該字節(jié)的最高位每次會(huì)翻轉(zhuǎn)一次。如表1所示。
表1 節(jié)點(diǎn)守護(hù)
因協(xié)議棧程序是基于結(jié)構(gòu)化、模塊化的方式開發(fā)的,因此對(duì)于開發(fā)者而言移植及運(yùn)用比較簡(jiǎn)易方便。主流程圖如圖10所示。
圖10 主流程圖
2.4.2.2 對(duì)象字典的編寫
對(duì)象字典是CANopen協(xié)議最核心的部分,對(duì)于從站設(shè)備需要編寫TestSlav e.c源文件。其實(shí)現(xiàn)主要分為兩部分:CIA-301規(guī)定的設(shè)備通訊參數(shù)、設(shè)備參數(shù)、PDO及SDO的參數(shù)配置。關(guān)于CAN從站設(shè)備節(jié)點(diǎn)對(duì)象字典的設(shè)置是確定的,需要在設(shè)備運(yùn)行前將相關(guān)內(nèi)容配置完。
從站設(shè)備啟動(dòng)后,主站設(shè)備會(huì)向從設(shè)備發(fā)送SDO配置報(bào)文,從站設(shè)備收到請(qǐng)求報(bào)文后按照協(xié)議規(guī)定方式解析主索引和子索引數(shù)據(jù)后,在對(duì)象字典中找到相應(yīng)的內(nèi)容。
2.4.2.3 SDO服務(wù)數(shù)據(jù)對(duì)象處理
從站設(shè)備處理SDO請(qǐng)求報(bào)文,此類型的報(bào)文是配置通訊相關(guān)參數(shù)。當(dāng)從設(shè)備接收到SDO請(qǐng)求時(shí),首先會(huì)判斷該請(qǐng)求是對(duì)OD進(jìn)行讀操作還是寫操作。然后根據(jù)主索引和子索引找到相應(yīng)的位置對(duì)其進(jìn)行相應(yīng)的讀或?qū)懖僮鳌?duì)象字典的內(nèi)容也是按照既定協(xié)議規(guī)則進(jìn)行查找賦值的。處理完成后,會(huì)按照協(xié)議規(guī)范相應(yīng)操作成功或失敗。
2.4.2.4 PDO過程數(shù)據(jù)對(duì)象處理
在SDO配置完成后,過程數(shù)據(jù)對(duì)象處理就會(huì)按照該配置的通訊參數(shù)和映射參數(shù)進(jìn)行運(yùn)行處理。PDO通訊參數(shù):主要涉及PDO的傳輸類型、禁止時(shí)間、事件時(shí)間等,對(duì)于RPDO通訊參數(shù)范圍在1400H~15FFH,TPDO在1800H~19FFH之間;PDO映射參數(shù):映射應(yīng)用對(duì)象到PDO中是在設(shè)備對(duì)象字典中描述的,對(duì)于RPDO范圍在1600H~2000H,TPDO在1A00~1BFF之間。PDO的報(bào)文內(nèi)容是寫入預(yù)先定義好的映射字典中。
PDO的交互方式取決于SDO對(duì)其的配置,如同步類型可以配置PDO根據(jù)同步報(bào)文數(shù)量來(lái)控制PDO報(bào)文;如遠(yuǎn)程幀類型可以配置PDO按照是否收到遠(yuǎn)程幀來(lái)控制PDO報(bào)文;如事件類型則可以通過數(shù)據(jù)的值是否發(fā)生變化來(lái)控制
PDO報(bào)文。以同步類型為例,其控制PDO流程圖如圖11所示。
圖11 同步類型 PDO流程圖
主要涉及兩個(gè)接口:PDO數(shù)據(jù)發(fā)送和PDO數(shù)據(jù)接收App_PdoDataGet()、App_PdoDataSend();該接口是通過Codesys與Vxworks接口組件實(shí)現(xiàn)的。兩個(gè)接口函數(shù)設(shè)計(jì)的參數(shù)為:PDO通道值、PDO數(shù)據(jù)指針、PDO數(shù)據(jù)指針長(zhǎng)度。
數(shù)據(jù)接收接口對(duì)應(yīng)的是從站設(shè)備的RPDO,需要獲取相關(guān)的PDO數(shù)據(jù)時(shí),即可根據(jù)PDO通道值獲取對(duì)應(yīng)的PDO映射地址中的數(shù)據(jù)。當(dāng)需要發(fā)送數(shù)據(jù)時(shí)可根據(jù)相應(yīng)的PDO通道將數(shù)據(jù)傳到映射地址中完成數(shù)據(jù)發(fā)送。
在完成CANopen從站模塊的軟硬件設(shè)計(jì)與調(diào)試后,需要對(duì)CANopen從站的CANopen通訊協(xié)議進(jìn)行測(cè)試驗(yàn)證。系統(tǒng)硬件測(cè)試環(huán)境搭建完成后如圖12所示。系統(tǒng)中的主站功能由某廠家風(fēng)機(jī)控制器的主控模塊完成;同時(shí)利用第三方CAN工具及其上位機(jī)軟件在總線上進(jìn)行抓包,供過程分析與性能驗(yàn)證。
圖12 系統(tǒng)實(shí)物圖
系統(tǒng)搭建完成后,將各個(gè)單元上電運(yùn)行。待CAN設(shè)備完成初始化等任務(wù)后,系統(tǒng)即進(jìn)入運(yùn)行模式。整個(gè)通訊過程無(wú)需其他操作。通訊過程首先是從站設(shè)備發(fā)送Boot_up啟動(dòng)幀,表示從站設(shè)備已完成啟動(dòng)待配置;接著主站會(huì)按照EDS文件配置從站參數(shù),讀配置成功則響應(yīng)的包數(shù)據(jù)頭為0x4x開頭,對(duì)于寫配置成功后響應(yīng)的數(shù)據(jù)頭以0x60開頭。還有其他通訊如表2所示。
表2 測(cè)試數(shù)據(jù)
整個(gè)過程基本驗(yàn)證了通訊功能。并通過大量驗(yàn)證測(cè)試數(shù)據(jù)傳輸一直保持穩(wěn)定高效。因此,可證明該設(shè)計(jì)的CANopen從站系統(tǒng)滿足CANopen通訊協(xié)議。
本文設(shè)計(jì)部分首先介紹了CANopen系統(tǒng)搭建的總體設(shè)計(jì),并闡述了CANopen總線的基本概念,介紹了如何將CANopen開源協(xié)議棧應(yīng)用到風(fēng)機(jī)控制器上 。過程中并對(duì)軟軟硬件設(shè)計(jì)方案中的注意項(xiàng)進(jìn)行了說(shuō)明。如硬件設(shè)計(jì)給出了具體型號(hào)的芯片、功能介紹等;軟件設(shè)計(jì)則給出相關(guān)設(shè)計(jì)方法及思路,并通過各個(gè)軟件開發(fā)平臺(tái)進(jìn)行開發(fā)設(shè)計(jì)。設(shè)計(jì)完成后則通過實(shí)際硬件進(jìn)行驗(yàn)證,并對(duì)測(cè)試數(shù)據(jù)進(jìn)行分析注釋。實(shí)際結(jié)果表明CANopen總線控制可使系統(tǒng)控制線路簡(jiǎn)單、過程調(diào)試方便,提高了控制系統(tǒng)的可靠性和實(shí)時(shí)性 。