吳棟棟 周向東
華中科技大學(xué)國家數(shù)控系統(tǒng)工程技術(shù)研究中心,武漢,430074
現(xiàn)代的數(shù)控系統(tǒng)廣泛采用主從模式[1],即采用上位機(jī)加下位機(jī)的結(jié)構(gòu)[2-4],因而具有分布式系統(tǒng)的特征。這種體統(tǒng)結(jié)構(gòu)支持用戶的二次研發(fā)和自主升級(jí),既具有PC端的開放性,又具有控制端的開放性,可以說它具有前后兩端的開放性。然而要實(shí)現(xiàn)基于上下位機(jī)結(jié)構(gòu)的CNC系統(tǒng),就必須要實(shí)現(xiàn)上下位機(jī)間的通信。目前上下位機(jī)之間主要的通信方式有串口通信方式、以太網(wǎng)通信方式以及現(xiàn)場(chǎng)總線通信方式。三種通信方式各有優(yōu)缺點(diǎn):串口通信最大的優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單、成本低,但卻存在可靠性差、效率低等缺點(diǎn)[5];以太網(wǎng)通信具有的標(biāo)準(zhǔn)性和開放性是其最大的優(yōu)點(diǎn),但也存在實(shí)時(shí)性不強(qiáng)、抗干擾能力差等缺點(diǎn)[5];現(xiàn)場(chǎng)總線通信具有操作方便、開放性好的特點(diǎn),同時(shí)也存在結(jié)構(gòu)復(fù)雜、結(jié)構(gòu)層次過多等問題[6]。因此,針對(duì)具體的情況,選擇相應(yīng)的通信方式才能實(shí)現(xiàn)上下位機(jī)之間有效的通信。同時(shí),目前上下位機(jī)所選用的操作系統(tǒng)往往不同,于是如何實(shí)現(xiàn)上下位機(jī)之間的跨平臺(tái)通信也是一個(gè)亟待解決的問題[7]。本文研究的上下位機(jī)間的通信通過合理的劃分通信層次結(jié)構(gòu),既能夠?qū)崿F(xiàn)跨平臺(tái)通信,又能夠屏蔽通信介質(zhì)的差異,同時(shí)還能根據(jù)數(shù)據(jù)的類型提供不同的通信服務(wù)。
由于Windows操作系統(tǒng)具有開發(fā)資源豐富、操作方便等優(yōu)點(diǎn);Linux和Dos操作系統(tǒng)都具有強(qiáng)實(shí)時(shí)性,通常數(shù)控系統(tǒng)的上位機(jī)(HMI端)采用Window平臺(tái),下位機(jī)(NCU端)采用Linux和Dos平臺(tái)。因此,通信層次的劃分要合理,為上層應(yīng)用軟件提供通用的通信服務(wù)接口,屏蔽底層平臺(tái)的差異、通信引擎的差異和操作系統(tǒng)的差異。
本文中的上下位機(jī)間通信采用客戶端/服務(wù)器的模式[8]:其中上位機(jī)為客戶端,負(fù)責(zé)向服務(wù)器端發(fā)起通信請(qǐng)求;下位機(jī)為服務(wù)器端,提供數(shù)據(jù)的上傳和下載服務(wù)。服務(wù)器端分為4個(gè)層次:通信引擎層、通信抽象層、通信服務(wù)層、數(shù)控控制單元;客戶端分為通信引擎層、通信抽象層、通信服務(wù)層、通信接口層、NCAPI層、人機(jī)交互界面。通信服務(wù)結(jié)構(gòu)層次如圖1所示。

圖1 通信服務(wù)層次示意圖
通信引擎層實(shí)現(xiàn)網(wǎng)絡(luò)通信、串口通信、總線通信三種通信方式,同時(shí)屏蔽操作系統(tǒng)的差異。不同的操作系統(tǒng)中,網(wǎng)絡(luò)通信、串口通信、總線通信程序的開發(fā)主要是相應(yīng)功能的函數(shù)接口不同,因此通過條件編譯的方式,每一種通信方式的實(shí)現(xiàn)程序中包含多個(gè)操作系統(tǒng)中該通信方式實(shí)現(xiàn)的代碼程序。這樣就實(shí)現(xiàn)了通信引擎的跨平臺(tái)。
通信抽象層主要管理網(wǎng)絡(luò)通信、串口通信、總線通信三種通信引擎。抽象出一系列統(tǒng)一的接口供上層使用,從而屏蔽通信引擎的差異,該層主要維護(hù)一個(gè)已注冊(cè)的通信引擎數(shù)組,保存每個(gè)通信引擎數(shù)據(jù)結(jié)構(gòu)的指針。通信抽象層利用一個(gè)指針保存當(dāng)前使用的通信引擎。每一個(gè)通信引擎的數(shù)據(jù)結(jié)構(gòu)定義了該通信引擎的一些信息,比如說連接是否建立的判斷,以及發(fā)送數(shù)據(jù)接口、接收數(shù)據(jù)接口、初始化通信接口、退出通信接口的信息提示等。通信抽象層的實(shí)現(xiàn)過程如圖2所示。

圖2 通信抽象層的實(shí)現(xiàn)過程示意圖
服務(wù)器端的通信服務(wù)層提供不同類型數(shù)據(jù)的通信服務(wù),客戶端的通信接口層提供使用服務(wù)器端相應(yīng)通信服務(wù)的接口。這兩層都是在通信抽象層之上的,因此它們不用關(guān)心操作系統(tǒng)和通信引擎的差異。
客戶端NCAPI層通過調(diào)用通信接口層中相應(yīng)的接口獲取數(shù)控系統(tǒng)中對(duì)應(yīng)的數(shù)據(jù)供人機(jī)交互界面使用。
通信服務(wù)層是一種面向服務(wù)的應(yīng)用接口,通過調(diào)用通信抽象層提供的接口實(shí)現(xiàn)通信服務(wù),它不必關(guān)心操作系統(tǒng)的差異、通信引擎的差異。通信服務(wù)的內(nèi)容主要包括變量服務(wù)、命令服務(wù)、文件服務(wù)、報(bào)警服務(wù)等內(nèi)容。
數(shù)控系統(tǒng)中有些數(shù)據(jù)是需要在上下位機(jī)之間經(jīng)常動(dòng)態(tài)更新的,例如加工位置值、進(jìn)給速度值、加工誤差值等,這一類數(shù)據(jù)對(duì)傳輸?shù)目煽啃詻]有很高的要求,但是需要周期的上傳和下載。
變量服務(wù)主要功能就是在服務(wù)器端(或NCU端)和客戶端(或HMI端)傳遞需要經(jīng)常動(dòng)態(tài)更新的數(shù)據(jù)。變量服務(wù)的原理如圖3所示,NCU端數(shù)據(jù)服務(wù)器監(jiān)控變量存儲(chǔ)區(qū)的數(shù)據(jù)變化的情況,有變化就通過通信接口發(fā)送到HMI端;HMI端數(shù)據(jù)服務(wù)器監(jiān)控服務(wù)端口,如果有數(shù)據(jù)就解析報(bào)文,并調(diào)用數(shù)據(jù)訪問接口向本地的變量鏡像區(qū)寫數(shù)據(jù)。因此在一個(gè)時(shí)間片內(nèi),總可以保證HMI端保留有NCU端數(shù)據(jù)的一個(gè)鏡像,這樣就能保證HMI端變量鏡像區(qū)和NCU端變量存儲(chǔ)區(qū)數(shù)據(jù)的一致性。HMI訪問數(shù)據(jù)只面對(duì)本地?cái)?shù)據(jù),而不用考慮數(shù)據(jù)從何而來。

圖3 變量服務(wù)原理圖
數(shù)控系統(tǒng)中有些數(shù)據(jù)由HMI端發(fā)送給NCU端后,NCU端是需要作出相應(yīng)動(dòng)作響應(yīng)的,例如數(shù)控系統(tǒng)中的手動(dòng)功能。這類數(shù)據(jù)就是命令,它需要NCU給HMI返回響應(yīng),從而使HMI知道NCU端對(duì)命令的處理情況。
命令服務(wù)就是上下位機(jī)之間實(shí)現(xiàn)數(shù)控系統(tǒng)的命令控制,由HMI端發(fā)起,NCU端響應(yīng)。HMI端組裝命令數(shù)據(jù)報(bào)文,通過網(wǎng)絡(luò)發(fā)送到NCU端,NUC端接收到命令包后,進(jìn)行相應(yīng)的數(shù)據(jù)報(bào)文解析,根據(jù)數(shù)據(jù)報(bào)文解析的結(jié)果進(jìn)行相應(yīng)的命令操作,最后再向HMI端發(fā)送命令處理成功與否的響應(yīng)消息數(shù)據(jù)報(bào)文。HMI端在設(shè)定的時(shí)間內(nèi)進(jìn)行超時(shí)檢查,確認(rèn)是否收到成功的響應(yīng)報(bào)文,命令服務(wù)的通信模式如圖4所示。

圖4 命令服務(wù)通信模式
數(shù)控系統(tǒng)中的報(bào)警信息對(duì)于數(shù)控機(jī)床的維護(hù)和保證其加工的安全性至關(guān)重要,因此HMI端必須顯示數(shù)控系統(tǒng)的報(bào)警信息。
上下位機(jī)的報(bào)警服務(wù)是將NCU端的提示、報(bào)警等信息傳遞給HMI端。在NCU端和HMI端,采用統(tǒng)一的消息管理器。在NCU端的報(bào)警服務(wù)器監(jiān)控消息隊(duì)列,如果有新的消息,則通過報(bào)警服務(wù)端口將新報(bào)警信息發(fā)送到HMI端。HMI端監(jiān)聽報(bào)警服務(wù)端口,如果有新的報(bào)警,則調(diào)用消息管理接口,并添加到HMI消息隊(duì)列中。報(bào)警服務(wù)的處理過程如圖5所示。

圖5 報(bào)警服務(wù)處理過程
上下位機(jī)之間經(jīng)常需要傳輸加工程序、參數(shù)文件和PLC程序等,因此文件服務(wù)必不可少。文件服務(wù)主要提供目錄的上傳、文件的上傳和下載。
文件服務(wù)總是由HMI端提出請(qǐng)求,經(jīng)NCU響應(yīng)后進(jìn)入具體的文件服務(wù)。在文件下載服務(wù)狀態(tài),由HMI發(fā)送文件頭,分塊發(fā)送文件體和文件結(jié)束標(biāo)識(shí),NCU端接收文件頭、文件體,并將其儲(chǔ)存在文件中。在文件上傳服務(wù)狀態(tài),由HMI發(fā)送文件頭,分塊接收文件體和文件結(jié)束標(biāo)識(shí),NCU端接收到文件頭后,發(fā)送相應(yīng)的文件體,直至文件結(jié)束發(fā)送文件結(jié)束標(biāo)識(shí)。在目錄服務(wù)狀態(tài),將目錄轉(zhuǎn)換成文件進(jìn)行傳輸。在傳輸過程中,如果超時(shí)或有與狀態(tài)不匹配的操作碼出現(xiàn),則進(jìn)入復(fù)位處理,文件服務(wù)重新進(jìn)入空閑狀態(tài)。文件服務(wù)器的狀態(tài)機(jī)如圖6所示。

圖6 文件服務(wù)器的狀態(tài)機(jī)
將通信模塊的客戶端和服務(wù)器端的程序分別集成到數(shù)控系統(tǒng)的上位機(jī)和下位機(jī)中進(jìn)行網(wǎng)絡(luò)通信、串口通信和總線通信的測(cè)試。上下位機(jī)采用的都是基于ARM S3C2440的微處理器+FPGA的嵌入式數(shù)控系統(tǒng),上位機(jī)主要負(fù)責(zé)人機(jī)交互界面,下位機(jī)主要負(fù)責(zé)運(yùn)動(dòng)控制。實(shí)驗(yàn)結(jié)果表明,上下位機(jī)之間能夠高效、快速和穩(wěn)定地完成文件、變量、命令和報(bào)警等信息的傳輸。上下位機(jī)之間以太網(wǎng)通信的測(cè)試現(xiàn)場(chǎng)如圖7所示,串口通信的測(cè)試現(xiàn)場(chǎng)如圖8所示,總線通信的測(cè)試現(xiàn)場(chǎng)如圖9所示。

圖7 上下位機(jī)以太網(wǎng)通信方式測(cè)試現(xiàn)場(chǎng)

圖8 上下位機(jī)串口通信方式測(cè)試現(xiàn)場(chǎng)

圖9 上下位機(jī)總線通信方式測(cè)試現(xiàn)場(chǎng)
本文給出的數(shù)控系統(tǒng)上下位機(jī)之間的通信服務(wù)設(shè)計(jì)不僅可以實(shí)現(xiàn)跨平臺(tái),還可以根據(jù)具體的應(yīng)用環(huán)境,選擇不同的通信介質(zhì)。實(shí)驗(yàn)驗(yàn)證表明,所研制的通用上下位機(jī)通信模型,大大縮短了基于上下位機(jī)模式數(shù)控系統(tǒng)的開發(fā)周期,設(shè)計(jì)方案滿足實(shí)際要求,且簡(jiǎn)便可行。
[1]楊旭東,孫凌逸,王永軍,等.基于上下位機(jī)的拉彎?rùn)C(jī)數(shù)控系統(tǒng)研究[J].制造業(yè)自動(dòng)化,2005,27(4):19-26.Yang Xudong,Sun Linyi,Wang Yongjun,et al.Research of CNC System of Stretch-wrap Former Based on Main-subordinate Unit[J].Manufacturing Automation,2005,27(4):19-26.
[2]張志燕,李斌,朱國力,等.基于PC+NC的開放式數(shù)控系統(tǒng)平臺(tái)的研究與應(yīng)用[J].機(jī)械與電子,2005(5):6-8.Zhang Zhiyan,Li Bin,Zhu Guoli,et al.Research and Applications of Open CNC System Platform Based on PC+NC[J].Machinery & Electronics,2005(5):6-8.
[3]李剛,楊繼東.基于PC的開放式數(shù)控系統(tǒng)的開發(fā)[J].機(jī)床與液壓,2006(4):82-83.Li Gang,Yang Jidong.Development of the PC-based Open Architecture Numerical Control System[J].Hydromechatronics Engineering,2006(4):82-83.
[4]朱雙勝.基于GT運(yùn)動(dòng)控制器的開放式數(shù)控實(shí)驗(yàn)系統(tǒng)研究[D].杭州:浙江工業(yè)大學(xué),2008.
[5]楊萍,劉飛,張旭梅,等.CAN總線型DNC系統(tǒng)通信技術(shù)研究[J].制造技術(shù)與機(jī)床,1998(12):7-9.Yang Ping,Liu Fei,Zhang Xumei,et al.Communication Technique for DNC System Based on CAN Fieldbus[J].Manufacturing Technology & Machine Tool,1998(12):7-9.
[6]梁志鋒,解翔,唐小琦.基于工業(yè)以太網(wǎng)的網(wǎng)絡(luò)數(shù)控系統(tǒng)設(shè)計(jì)及實(shí)現(xiàn)[J].現(xiàn)代制造工程,2006(1):38-40.Liang Zhifeng,Xie Xiang,Tang Xiaoqi.Design of the Networked Numerical Control System Based on Industrial Ethernet[J].Modern Manufacturing Engineering,2006(1):38-40.
[7]鄧太林,朱文,閻春平,等.一種開放式數(shù)控系統(tǒng)平臺(tái)的研究[J].現(xiàn)代制造工程,2006(6):33-36.Deng Tailin,Zhu Wen,Yan Chunping,et al.Research on a Kind of Open Numeric Control System Platform[J].Modern Manufacturing Engineering,2006(6):33-36.
[8]丁鍵生,蔣澤軍,王麗芳.一種基于C/S結(jié)構(gòu)的跨平臺(tái)通信處理機(jī)制[J].微電子學(xué)與計(jì)算機(jī),2005,22(4):23-29.Ding Jiansheng,Jiang Zejun,Wang Lifang.A Cross-Platform Communication Processing Mechanism Based on C/S Structure[J].Microelectronics &Computer,2005,22(4):23-29.