本項目就是解決傳統(tǒng)經濟型的數(shù)控機床的網(wǎng)絡通訊和控制技術問題，通過網(wǎng)絡來實現(xiàn)NC程序的*服務器集中管理及網(wǎng)絡通訊。從而適應現(xiàn)代先進制造技術的發(fā)展。

　　1、需求分析

　　1.1傳統(tǒng)經濟型數(shù)控機床存在的問題

　　傳統(tǒng)經濟型的數(shù)控加工設備按數(shù)控系統(tǒng)分類主要有：FANUC系統(tǒng)（其中包括3T、7M、HC-6、6MB等）、AB公司系統(tǒng)、國產3B線切割系統(tǒng)等：按數(shù)控程序輸入/輸出通訊接口類型分有三類：一類為僅有RS232/RS422串行口，二類為僅有紙帶閱讀機8/5單位并行口，三類同時包括前兩類接口。這三類機床同時還存在同樣的問題就是：內存容量較小，不適應復雜、大型面、高精度、長程序零件的加工：它們的對外接口能力差，沒有DNC功能，不能實現(xiàn)在線加工以及網(wǎng)絡控制等問題。

　　1.2希望的解決方案

　　本著滿足zui基本的應用需求、且留有一定的可擴充性及性能提高的潛力的前提，來改善數(shù)控加工技術應用環(huán)境。就此提出了以下解決方案：機床通訊接口的硬件改造，針對各類機床設計相應的通訊接口板卡：通訊控制軟件的開發(fā)，以實現(xiàn)各機床的單機通訊功能：開發(fā)其它輔助功能（如：數(shù)控程序中加工信息的提取、數(shù)控程序圖形模擬、長程序的在線加工等），彌補和增強原數(shù)控系統(tǒng)功能：網(wǎng)絡體系的選擇與通訊協(xié)議的定義及網(wǎng)絡系統(tǒng)控制軟件的開發(fā)，實現(xiàn)數(shù)控程序的*服務器集中管理和網(wǎng)絡通訊。

　　2、系統(tǒng)結構

　　2.1網(wǎng)絡系統(tǒng)構成及功能

　　整個網(wǎng)絡系統(tǒng)是由*服務器、網(wǎng)絡接口、雙向數(shù)據(jù)轉換器、現(xiàn)場服務器、1分N口并行數(shù)據(jù)收發(fā)器、數(shù)據(jù)接收器以及經濟型數(shù)控機床等組成。

　　*服務器是整個網(wǎng)絡的中樞部分，它主要完成的是對各級服務器的整體控制。它采用后臺中斷工作模式，不需要人的干預，而且其前臺還可以進行其他工作。

　　現(xiàn)場服務器是客戶端，既擔任起數(shù)控服務器的功能，又具有強大的網(wǎng)絡通訊功能，它接受*服務器下達的各項任務：從網(wǎng)絡上獲取由*服務器傳來的數(shù)控加工程序的數(shù)據(jù)信息，并把這些數(shù)據(jù)信息傳送到NC文件庫：將已加工過的數(shù)控程序反饋到*服務器。能從系統(tǒng)的NC文件庫中提取相應的數(shù)控代碼，并從中提取有關的加工零件數(shù)據(jù)和信息，對其進行處理，實現(xiàn)NC程序的圖形模擬等工作。另外，對需用長程序的零件加工，現(xiàn)場服務器還完成長程序的在線加工任務。

　　現(xiàn)場服務器可同時服務于多臺數(shù)控設備，根據(jù)需要在車間一定的空間范圍內（比如：一個小的工作間，一個小的局部區(qū)域）設置網(wǎng)絡節(jié)點，放置一臺PC機作為現(xiàn)場服務器，一臺服務器根據(jù)實際需要靠選用1分N口并行數(shù)據(jù)收發(fā)器來服務于多臺數(shù)控設備。

　　2.2系統(tǒng)網(wǎng)絡體系結構及通信協(xié)議的選擇

　　系統(tǒng)中的各種信息都是通過網(wǎng)絡來傳輸?shù)?。在計算機網(wǎng)絡發(fā)展上，影響較大的網(wǎng)絡體系主要有：OSI七層參考模型和TCP/IP體系結構模型。OSI參考模型是ISO7498標準。TCP/IP體系結構是當前流行的Internet網(wǎng)絡所使用的體系結構，盡管它不是標準，但在計算機網(wǎng)絡體系結構中卻占有非常重要的地位。這是因為雖然OSI的體系結構從理論上講比較完整，其各層協(xié)議也考慮得很周全，但事實上，*符合OSI各層協(xié)議的商用產品卻極少進入市場，遠遠不能滿足各種用戶的需求。然而使用TCP/IP協(xié)議的產品卻大量涌入市場，幾乎所有的工作站都配有TCP/IP協(xié)議，并已成為計算機網(wǎng)絡事實上的標準，通稱“工業(yè)標準”。為此，我們在數(shù)控機床的網(wǎng)絡通訊系統(tǒng)中，采用的是TCP/IP的網(wǎng)絡體系結構，該體系把計算機網(wǎng)絡分為四層，即應用層、傳輸層、網(wǎng)絡層和網(wǎng)絡接口層。

　　TCP/IP體系結構為傳輸層制定了兩種協(xié)議即：傳輸控制協(xié)議（TCP）和用戶數(shù)據(jù)包協(xié)議（UDP），UDP為用戶提供進程無連接的數(shù)據(jù)報協(xié)議，數(shù)據(jù)包以獨立包的形式傳送，服務不提供無錯保證，數(shù)據(jù)可能丟失、重復或失序：數(shù)據(jù)包的長度也受一次處理zui大長度的限制（默認值為8192字節(jié)，zui大值為32768字節(jié)），不進行包的拆分和重組操作：而TCP協(xié)議是一個可靠的全雙工的字節(jié)流的面向連接的協(xié)議，TCP和UDP相比傳輸可靠、數(shù)據(jù)無差錯、無重復，可按發(fā)送順序接收，數(shù)據(jù)為字節(jié)流，其長度不受限制，為用戶提供虛電路服務，并為數(shù)據(jù)的可靠傳輸提供檢驗。根據(jù)數(shù)控加工的特點，盡管數(shù)據(jù)包在傳輸量小于2048個字節(jié)時UDP可靠性更好，但數(shù)據(jù)包服務是單包、無序傳送，而系統(tǒng)的網(wǎng)絡通信顯然不能保證所有傳輸?shù)男畔⒍夹∮?048個字節(jié)，因此，只能選用TCP作為系統(tǒng)的傳輸層協(xié)議。

　　應用層的通訊協(xié)議的選擇既要考慮到數(shù)控加工的特點又要具備實時性、可靠性以及數(shù)據(jù)傳輸量大等特點。本系統(tǒng)另行開發(fā)了基于TCP/IP協(xié)議族的相應協(xié)議，制定了應用進程之間傳輸?shù)男畔⒌奶厥夂x。