基于CAN總線(xiàn)的電梯主控系統(tǒng)軟硬件設(shè)計(jì)

　　圖5 繼電器輸出電路。

　　3 控制系統(tǒng)軟件設(shè)計(jì)

　　控制系統(tǒng)軟件設(shè)計(jì)時(shí)采用了當(dāng)前主流的keil 集成開(kāi)發(fā)環(huán)境。軟件設(shè)計(jì)以搶占式多任務(wù)實(shí)時(shí)操作系統(tǒng)μC/OS 為平臺(tái)實(shí)現(xiàn)［5］了電梯主控系統(tǒng)的調(diào)度分配、CAN通信、液晶顯示三個(gè)任務(wù)，如圖6 所示。

　　圖6 系統(tǒng)控制通信圖。

　　任務(wù)之間通信以消息隊(duì)列和郵箱方式進(jìn)行通信。

　　在與硬件接口上根據(jù)LPC2294 芯片手冊(cè)和應(yīng)用的需要，完成了CAN 模塊的驅(qū)動(dòng)、I2C 的總線(xiàn)模塊的驅(qū)動(dòng)、和GPIO 的模式的按鍵和12864 點(diǎn)陣液晶驅(qū)動(dòng)，這樣使得在μC/OS 的任務(wù)中無(wú)需關(guān)注LPC2294 芯片板上資源的具體使用，而只需要調(diào)用相應(yīng)的接口函數(shù)，方便了系統(tǒng)軟件的升級(jí)和改動(dòng)。

　　3.1 主控調(diào)度任務(wù)

　　在主控調(diào)度任務(wù)中完成當(dāng)前梯呼梯信號(hào)的整合，然后再根據(jù)當(dāng)前收集到的群控正常等輸入信號(hào)判斷當(dāng)前梯的運(yùn)行狀態(tài)（如自動(dòng)狀態(tài)、消防狀態(tài)、鎖梯狀態(tài)等），做出當(dāng)前狀態(tài)的處理；在電梯處在可調(diào)度的狀態(tài)下，根據(jù)相應(yīng)的調(diào)度算法完成對(duì)電梯的呼梯的合理配置；并通過(guò)消息隊(duì)列和郵箱與CAN 通信任務(wù)、液晶顯示任務(wù)進(jìn)行任務(wù)間通信，完成數(shù)據(jù)的交互。

　　3.2 CAN 通信任務(wù)

　　原則上對(duì)4 路CAN 控制器的資源分配為：CAN0外呼通信、CAN1 內(nèi)召通信、CAN2 變頻器通信、CAN3群控子系統(tǒng)通信［7］。但系統(tǒng)中可以在軟件上進(jìn)行相應(yīng)的配置，然后使得任意CAN 控制器可以與任意的外部子系統(tǒng)相連，這樣就增加了系統(tǒng)的靈活性，也給操作人員帶來(lái)了方便。在CAN 通信任務(wù)調(diào)用之前，需要調(diào)用相應(yīng)的CAN 控制器初始化函數(shù)，對(duì)CAN 控制器中斷、波特率、驗(yàn)收過(guò)濾器等進(jìn)行相關(guān)的設(shè)置。在CAN通信任務(wù)中，一方面需要完成4 路CAN 控制器通過(guò)中斷方式接收到緩沖區(qū)中的數(shù)據(jù)再驗(yàn)證無(wú)誤后交付給主控調(diào)度任務(wù)，令一方面需把主控會(huì)把給群控調(diào)度器、變頻器、內(nèi)召板、轎廂板發(fā)送的信號(hào)或者命令交付給CAN 通信任務(wù)。CAN 通信任務(wù)再接收到主控的數(shù)據(jù)做相應(yīng)的驗(yàn)證，封裝成相應(yīng)的協(xié)議格式的幀，然后發(fā)送給相應(yīng)的子系統(tǒng)。

　　在CAN 通信中，發(fā)送數(shù)據(jù)的封裝和接收數(shù)據(jù)的解封遵循的格式除了變頻器部分參考第三方提供的CAN 總線(xiàn)通信協(xié)議，其他模塊與主控系統(tǒng)的通信完全依靠下述自定義協(xié)議。在電梯控制系統(tǒng)中，CAN 通信全部采用CAN2.0 所規(guī)定的擴(kuò)展數(shù)據(jù)幀［5-7］，其格式如表1 所示。傳輸?shù)膸?9 位ID 按下表劃分（全0 或者全1 將被舍棄）。

　　表1 擴(kuò)展幀ID 格式

　　CAN總線(xiàn)的電梯主控系統(tǒng)軟硬件設(shè)計(jì)" src="http://www.elecfans.com/upload