吳棟棟 周向東

華中科技大學國家數(shù)控系統(tǒng)工程技術(shù)研究中心，武漢，430074

0 引言

現(xiàn)代的數(shù)控系統(tǒng)廣泛采用主從模式［1］，即采用上位機加下位機的結(jié)構(gòu)［2－4］，因而具有分布式系統(tǒng)的特征。這種體統(tǒng)結(jié)構(gòu)支持用戶的二次研發(fā)和自主升級，既具有PC端的開放性，又具有控制端的開放性，可以說它具有前后兩端的開放性。然而要實現(xiàn)基于上下位機結(jié)構(gòu)的CNC系統(tǒng)，就必須要實現(xiàn)上下位機間的通信。目前上下位機之間主要的通信方式有串口通信方式、以太網(wǎng)通信方式以及現(xiàn)場總線通信方式。三種通信方式各有優(yōu)缺點：串口通信最大的優(yōu)點是實現(xiàn)簡單、成本低，但卻存在可靠性差、效率低等缺點［5］；以太網(wǎng)通信具有的標準性和開放性是其最大的優(yōu)點，但也存在實時性不強、抗干擾能力差等缺點［5］；現(xiàn)場總線通信具有操作方便、開放性好的特點，同時也存在結(jié)構(gòu)復雜、結(jié)構(gòu)層次過多等問題［6］。因此，針對具體的情況，選擇相應的通信方式才能實現(xiàn)上下位機之間有效的通信。同時，目前上下位機所選用的操作系統(tǒng)往往不同，于是如何實現(xiàn)上下位機之間的跨平臺通信也是一個亟待解決的問題［7］。本文研究的上下位機間的通信通過合理的劃分通信層次結(jié)構(gòu)，既能夠?qū)崿F(xiàn)跨平臺通信，又能夠屏蔽通信介質(zhì)的差異，同時還能根據(jù)數(shù)據(jù)的類型提供不同的通信服務。

1 上下位機通信的層次結(jié)構(gòu)

由于Windows操作系統(tǒng)具有開發(fā)資源豐富、操作方便等優(yōu)點；Linux和Dos操作系統(tǒng)都具有強實時性，通常數(shù)控系統(tǒng)的上位機（HMI端）采用Window平臺，下位機（NCU端）采用Linux和Dos平臺。因此，通信層次的劃分要合理，為上層應用軟件提供通用的通信服務接口，屏蔽底層平臺的差異、通信引擎的差異和操作系統(tǒng)的差異。

本文中的上下位機間通信采用客戶端／服務器的模式［8］：其中上位機為客戶端，負責向服務器端發(fā)起通信請求；下位機為服務器端，提供數(shù)據(jù)的上傳和下載服務。服務器端分為4個層次：通信引擎層、通信抽象層、通信服務層、數(shù)控控制單元；客戶端分為通信引擎層、通信抽象層、通信服務層、通信接口層、NCAPI層、人機交互界面。通信服務結(jié)構(gòu)層次如圖1所示。

圖1 通信服務層次示意圖

通信引擎層實現(xiàn)網(wǎng)絡通信、串口通信、總線通信三種通信方式，同時屏蔽操作系統(tǒng)的差異。不同的操作系統(tǒng)中，網(wǎng)絡通信、串口通信、總線通信程序的開發(fā)主要是相應功能的函數(shù)接口不同，因此通過條件編譯的方式，每一種通信方式的實現(xiàn)程序中包含多個操作系統(tǒng)中該通信方式實現(xiàn)的代碼程序。這樣就實現(xiàn)了通信引擎的跨平臺。

通信抽象層主要管理網(wǎng)絡通信、串口通信、總線通信三種通信引擎。抽象出一系列統(tǒng)一的接口供上層使用，從而屏蔽通信引擎的差異，該層主要維護一個已注冊的通信引擎數(shù)組，保存每個通信引擎數(shù)據(jù)結(jié)構(gòu)的指針。通信抽象層利用一個指針保存當前使用的通信引擎。每一個通信引擎的數(shù)據(jù)結(jié)構(gòu)定義了該通信引擎的一些信息，比如說連接是否建立的判斷，以及發(fā)送數(shù)據(jù)接口、接收數(shù)據(jù)接口、初始化通信接口、退出通信接口的信息提示等。通信抽象層的實現(xiàn)過程如圖2所示。

圖2 通信抽象層的實現(xiàn)過程示意圖

服務器端的通信服務層提供不同類型數(shù)據(jù)的通信服務，客戶端的通信接口層提供使用服務器端相應通信服務的接口。這兩層都是在通信抽象層之上的，因此它們不用關(guān)心操作系統(tǒng)和通信引擎的差異。

客戶端NCAPI層通過調(diào)用通信接口層中相應的接口獲取數(shù)控系統(tǒng)中對應的數(shù)據(jù)供人機交互界面使用。

2 通信服務層各功能實現(xiàn)

通信服務層是一種面向服務的應用接口，通過調(diào)用通信抽象層提供的接口實現(xiàn)通信服務，它不必關(guān)心操作系統(tǒng)的差異、通信引擎的差異。通信服務的內(nèi)容主要包括變量服務、命令服務、文件服務、報警服務等內(nèi)容。

2.1 變量服務的設計及實現(xiàn)

數(shù)控系統(tǒng)中有些數(shù)據(jù)是需要在上下位機之間經(jīng)常動態(tài)更新的，例如加工位置值、進給速度值、加工誤差值等，這一類數(shù)據(jù)對傳輸?shù)目煽啃詻]有很高的要求，但是需要周期的上傳和下載。

變量服務主要功能就是在服務器端（或NCU端）和客戶端（或HMI端）傳遞需要經(jīng)常動態(tài)更新的數(shù)據(jù)。變量服務的原理如圖3所示，NCU端數(shù)據(jù)服務器監(jiān)控變量存儲區(qū)的數(shù)據(jù)變化的情況，有變化就通過通信接口發(fā)送到HMI端；HMI端數(shù)據(jù)服務器監(jiān)控服務端口，如果有數(shù)據(jù)就解析報文，并調(diào)用數(shù)據(jù)訪問接口向本地的變量鏡像區(qū)寫數(shù)據(jù)。因此在一個時間片內(nèi)，總可以保證HMI端保留有NCU端數(shù)據(jù)的一個鏡像，這樣就能保證HMI端變量鏡像區(qū)和NCU端變量存儲區(qū)數(shù)據(jù)的一致性。HMI訪問數(shù)據(jù)只面對本地數(shù)據(jù)，而不用考慮數(shù)據(jù)從何而來。

圖3 變量服務原理圖

2.2 命令服務的設計及實現(xiàn)

數(shù)控系統(tǒng)中有些數(shù)據(jù)由HMI端發(fā)送給NCU端后，NCU端是需要作出相應動作響應的，例如數(shù)控系統(tǒng)中的手動功能。這類數(shù)據(jù)就是命令，它需要NCU給HMI返回響應，從而使HMI知道NCU端對命令的處理情況。

命令服務就是上下位機之間實現(xiàn)數(shù)控系統(tǒng)的命令控制，由HMI端發(fā)起，NCU端響應。HMI端組裝命令數(shù)據(jù)報文，通過網(wǎng)絡發(fā)送到NCU端，NUC端接收到命令包后，進行相應的數(shù)據(jù)報文解析，根據(jù)數(shù)據(jù)報文解析的結(jié)果進行相應的命令操作，最后再向HMI端發(fā)送命令處理成功與否的響應消息數(shù)據(jù)報文。HMI端在設定的時間內(nèi)進行超時檢查，確認是否收到成功的響應報文，命令服務的通信模式如圖4所示。

圖4 命令服務通信模式

2.3 報警服務的設計及實現(xiàn)

數(shù)控系統(tǒng)中的報警信息對于數(shù)控機床的維護和保證其加工的安全性至關(guān)重要，因此HMI端必須顯示數(shù)控系統(tǒng)的報警信息。

上下位機的報警服務是將NCU端的提示、報警等信息傳遞給HMI端。在NCU端和HMI端，采用統(tǒng)一的消息管理器。在NCU端的報警服務器監(jiān)控消息隊列，如果有新的消息，則通過報警服務端口將新報警信息發(fā)送到HMI端。HMI端監(jiān)聽報警服務端口，如果有新的報警，則調(diào)用消息管理接口，并添加到HMI消息隊列中。報警服務的處理過程如圖5所示。

圖5 報警服務處理過程

2.4 文件服務的設計及實現(xiàn)

上下位機之間經(jīng)常需要傳輸加工程序、參數(shù)文件和PLC程序等，因此文件服務必不可少。文件服務主要提供目錄的上傳、文件的上傳和下載。

文件服務總是由HMI端提出請求，經(jīng)NCU響應后進入具體的文件服務。在文件下載服務狀態(tài)，由HMI發(fā)送文件頭，分塊發(fā)送文件體和文件結(jié)束標識，NCU端接收文件頭、文件體，并將其儲存在文件中。在文件上傳服務狀態(tài)，由HMI發(fā)送文件頭，分塊接收文件體和文件結(jié)束標識，NCU端接收到文件頭后，發(fā)送相應的文件體，直至文件結(jié)束發(fā)送文件結(jié)束標識。在目錄服務狀態(tài)，將目錄轉(zhuǎn)換成文件進行傳輸。在傳輸過程中，如果超時或有與狀態(tài)不匹配的操作碼出現(xiàn)，則進入復位處理，文件服務重新進入空閑狀態(tài)。文件服務器的狀態(tài)機如圖6所示。

圖6 文件服務器的狀態(tài)機

3 實驗驗證

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

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

圖8 上下位機串口通信方式測試現(xiàn)場

圖9 上下位機總線通信方式測試現(xiàn)場

4 結(jié)語

本文給出的數(shù)控系統(tǒng)上下位機之間的通信服務設計不僅可以實現(xiàn)跨平臺，還可以根據(jù)具體的應用環(huán)境，選擇不同的通信介質(zhì)。實驗驗證表明，所研制的通用上下位機通信模型，大大縮短了基于上下位機模式數(shù)控系統(tǒng)的開發(fā)周期，設計方案滿足實際要求，且簡便可行。

［1］楊旭東，孫凌逸，王永軍，等.基于上下位機的拉彎機數(shù)控系統(tǒng)研究［J］.制造業(yè)自動化，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)平臺的研究與應用［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］.機床與液壓，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運動控制器的開放式數(shù)控實驗系統(tǒng)研究［D］.杭州：浙江工業(yè)大學，2008.

［5］楊萍，劉飛，張旭梅，等.CAN總線型DNC系統(tǒng)通信技術(shù)研究［J］.制造技術(shù)與機床，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)絡數(shù)控系統(tǒng)設計及實現(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)平臺的研究［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)的跨平臺通信處理機制［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.