基于Linux的開放式數(shù)控系統(tǒng)譯碼解釋器的研究

黃繼威，林述溫，周小宇

(福州大學 機械工程及自動化學院，福建 福州 350116)

0 引言

開放式數(shù)控系統(tǒng)的出現(xiàn)為智能數(shù)控技術的發(fā)展創(chuàng)造了有利條件。堅持走數(shù)控系統(tǒng)開放化的技術路線，跟蹤掌握數(shù)控技術的最新進展，解決其中的關鍵技術，有利于為新一代國產(chǎn)開放式數(shù)控系統(tǒng)的研制打下堅實的基礎[1-2]。解釋器是數(shù)控系統(tǒng)的核心部分之一，數(shù)控系統(tǒng)解釋器通過獲取ISO標準的數(shù)據(jù)指令，并將其轉換為內部命令用來控制機床和執(zhí)行數(shù)控系統(tǒng)的輔助功能。數(shù)控機床采用G代碼來完成這些操作[3-4]。如何準確、高效地對數(shù)控程序代碼進行譯碼就成為數(shù)控系統(tǒng)開發(fā)過程中的關鍵問題。

鑒于高速高精、大數(shù)據(jù)量處理要求和開放式數(shù)控系統(tǒng)發(fā)展趨勢，基于Linux平臺開發(fā)了一種低成本、柔性化、可配置的開放式數(shù)控系統(tǒng)?，F(xiàn)有的數(shù)控譯碼解釋器進行譯碼的方式主要有兩種：編譯式譯碼和解釋式譯碼。編譯式一次性解析所有加工程序，速度快，但占用較大的系統(tǒng)資源。解釋式每次只解析一段加工程序，結構簡單，要求譯碼速度足夠快以滿足后續(xù)插補模塊對加工數(shù)據(jù)的要求，這種方式對實時性的要求較為苛刻。

為滿足本數(shù)控系統(tǒng)粗精異步插補的需求，實現(xiàn)高速高精運動控制，通過對以上兩種方式的分析，結合其各自的優(yōu)點，采用緩沖區(qū)中斷機制進行分段預讀譯碼，避免了資源浪費和實時性要求高的問題，并開發(fā)不同類型的五軸譯碼解釋器以滿足數(shù)控系統(tǒng)的可配置功能要求。

1 譯碼的層次結構及譯碼方式的選擇

目前，國際上通用的數(shù)控機床的加工程序主要基于標準 ISO 6983 的G、M代碼語言編寫而成的。最常用的程序段字地址格式如下所示：

Nxxx Gxx Xxx Yxx Zxx Fxx Sxx Txx Mxx

1.1 譯碼的層次結構

解釋器譯碼流程如圖1所示。首先，在本數(shù)控系統(tǒng)中數(shù)控程序的文件格式為***.ncc，解釋器識別該格式文件的并初始化寄存器，然后逐行讀取數(shù)控程序代碼文件，經(jīng)預處理過濾去除掉多余的注釋信息和空格，得到有效的字符程序段；接著執(zhí)行詞法分析和語法分析，若出現(xiàn)錯誤則返回錯誤編號進行錯誤處理并在人機界面顯示錯誤信息，否則，將計算結果保存在預讀寄存器中。若有刀具補償指令就調用刀具補償模塊進行刀具補償；計算并將底層控制指令存儲到執(zhí)行寄存器中，最后將指令添加到命令緩沖區(qū)中，若命令緩沖區(qū)的數(shù)據(jù)未達設定的值，那么就繼續(xù)讀取下一行數(shù)控程序代碼，若緩沖區(qū)已滿，則譯碼模塊處于等待狀態(tài)，等待任務管理器的再次調用。

圖1 數(shù)控程序解釋器譯碼流程

1.2 譯碼方式的選擇

編譯式譯碼是一次性地將加工程序進行譯碼工作，譯碼完成后得到的數(shù)據(jù)全部交給后續(xù)模塊。當代碼量大時，一次性地將代碼進行譯碼處理需要耗費較多時間，對系統(tǒng)實時性要求較高，增加系統(tǒng)成本。

解釋式譯碼是將一行的數(shù)控程序代碼作為每一次譯碼的處理對象，完成當前代碼行的譯碼后，立即將譯碼數(shù)據(jù)交由后續(xù)模塊進行處理，機床執(zhí)行動作,如此往復,直至整個代碼文件翻譯完畢。整個譯碼的過程是以串行方式運行，譯碼模塊必須為插補模塊及時提供足夠的數(shù)據(jù)，如果某條指令譯碼過程耗費的時間比較長，而插補模塊已無數(shù)據(jù)可用，就會造成數(shù)控機床短時暫停。

經(jīng)過對編譯式和解釋式的分析比較，提出了中斷型預讀譯碼方式。如圖2所示，首先在數(shù)控系統(tǒng)中設置預讀段數(shù)(M+N)，數(shù)控加工時，譯碼模塊先讀取(M+N)段代碼，并將譯碼后的數(shù)據(jù)按順序存儲到軌跡命令環(huán)形緩沖區(qū)中，但執(zhí)行完N段數(shù)控代碼后，產(chǎn)生中斷命令，系統(tǒng)再次調用譯碼模塊進行譯碼，確保緩沖區(qū)不被插補模塊讀空，保證插補模塊運行的連續(xù)性。

為了確保命令的連續(xù)性，本研究中的M值由前瞻速度處理段數(shù)決定，為了使得指令獲取命令隊列連貫，實驗中的N選取為M的2倍；由于本數(shù)控系統(tǒng)前瞻速度處理段數(shù)為7，故設置1個先進先出的環(huán)形緩沖區(qū)，該緩沖區(qū)大小為21，緩沖區(qū)的管理采用指針來實現(xiàn)。當人機界面調用譯碼子模塊進行加工前軌跡模擬時則采用類似于編譯式譯碼方式逐段解析全部的數(shù)控代碼，但解析一行代碼后的數(shù)據(jù)并不進行存儲，而是直接將數(shù)據(jù)送到加工仿真界面進行顯示，如此反復直到所有刀位點連接為加工軌跡，提前檢查加工軌跡的正確性。

圖2 中斷型譯碼機制

中斷型預讀式譯碼的核心思想就是在數(shù)控加工流程中在譯碼模塊數(shù)據(jù)生產(chǎn)和插補模塊消費之間設置一定的緩存區(qū),并采用中斷機制，用緩存區(qū)的空間占有和中斷機制來降低譯碼模塊和插補模塊的同步要求,加大操作時域裕度，避免了整體式譯碼引起的系統(tǒng)資源浪費問題，并且克服了解釋式譯碼由于實時性差造成的譯碼數(shù)據(jù)獲取不連貫導致數(shù)控機床短時暫停的問題，提高了系統(tǒng)的運行效率。

2 數(shù)控程序解釋器的設計與實現(xiàn)

在解釋器中，設計了3個寄存器用于存儲譯碼數(shù)據(jù)。按照數(shù)據(jù)流方向分別為數(shù)控代碼預讀寄存器、當前狀態(tài)寄存器和執(zhí)行寄存器，這3個寄存器用來存儲解釋器執(zhí)行過程中產(chǎn)生的所有譯碼數(shù)據(jù)。其中，預讀寄存器是用來存儲將要執(zhí)行的下一行的數(shù)控程序代碼；當前狀態(tài)寄存器是用來存儲當前數(shù)控系統(tǒng)的運行狀態(tài)信息；執(zhí)行寄存器是用來存儲已完成分類封裝的可以用于控制層執(zhí)行的底層控制指令。

1) 預讀寄存器

如圖3所示，預讀寄存器中主要用來存儲經(jīng)過詞法分析和語法分析后，提取一行數(shù)控程序代碼的有效加工信息，存儲一行數(shù)控程序中出現(xiàn)的所有詞并保存相應的參數(shù)數(shù)值。在數(shù)控程序語言中最小的語法單位是一個“詞”,一個G代碼、M代碼、軸坐標或者其他加工參數(shù)都稱為一個詞。并且當前程序段的代碼、程序段說明等也將進行存儲,并保留了當前有效模態(tài)代碼、代碼和運動代碼的空間。由于在一行數(shù)控程序中所有的詞不太可能同時出現(xiàn),因此在數(shù)據(jù)結構中一個詞對應著兩個不同的變量,開關類型的變量表示該詞是否出現(xiàn),參數(shù)類型用來保存相應的參數(shù)值。

預讀寄存器中存儲的代碼段結構體CNC_LINECODE_STRUCT的基本定義如以下代碼所示：

typedef struct CNC_LINECODE_STRUCT

{

int nNumber; //行號

int gCodes[G_GROUP] ; // 存儲G代碼

int mCodes[M_GROUP] ; // 存儲M代碼

ON_OFF aFlag; //是否有A坐標值的標志

double aNumber; // A坐標值

…

char comment[COMMENT_LEN] ; // 存儲程序段注釋

}LineCodeStruct;

圖3 預讀寄存器結構

2) 當前狀態(tài)寄存器

如圖4所示，當前狀態(tài)寄存器是一個用來存儲解釋器的全局信息和所有加工參數(shù)的全局數(shù)據(jù)，解釋器內所有模塊都將對該數(shù)據(jù)進行相應的操作。主要的數(shù)據(jù)有：G代碼文件名、當前有效的模態(tài)G代碼和M代碼、加工點的當前坐標、當前編程坐標系原點偏移、刀位點所處平面等主要信息。

與該寄存器相對應的當前狀態(tài)數(shù)據(jù)結構體CNC_SETTING_STRUCT的基本定義如下：

typedef struct CNC_SETTING_STRUCT

{

char filename[NAME_LEN] ; // 程序文件名

int gCodes[G_GROUP] ; // G代碼

int mCodes[M_GROUP] ; // M代碼

double xCurrent; // 加工點當前x坐標

…

double xOriginOffset; //編程坐標系原點x軸偏移

ACTIVE_PLANE plane; //刀位點所處平面

}SettingStruct;

圖4 當前狀態(tài)寄存器結構

3) 執(zhí)行寄存器

如圖5所示，執(zhí)行寄存器中主要存儲控制層可以直接識別并執(zhí)行的命令消息，解釋器執(zhí)行過程中通過NML提供的append(NMLmsg) 函數(shù)將命令消息送到執(zhí)行寄存器中。其主要存儲了直線運動指令、圓弧運動指令、延時指令、換到指令、開關量控制指令等。以圓弧運動指令為例，

class CNC_TRAJ_CIRCLE_MOVE:public CNC_TRAJ_CMD_MSG

{

public:

CNC_TRAJ_CIRCLE_MOVE():

CNC_TRAJ_CMD_MSG(CNC_TRAJ_CIRCLE_MOVE_TYPE,

sizeof(CNC_TRAJ_CIRCLE_MOVE));

void update(CMS * cms); // 狀態(tài)更新函數(shù)

PoseStruct endPt; //圓弧終點

CartesianStruct center; //圓弧圓心

CartesianStruct normal; //圓弧法向

int turn; //圓弧方向

int type; //圓弧類型

double vel,maxVel,acc; //速度，最大速度，加速度

};

圖5 執(zhí)行寄存器結構

3 解釋器測試驗證

在Linux系統(tǒng)平臺上，搭建了基于PC+可編程IO卡的開放式數(shù)控系統(tǒng)。基于以上對解釋器譯碼的研究，對解釋器相應的寄存器、預處理模塊、詞法分析模塊、語法分析模塊等進行了擴展，開發(fā)了五軸X-Y-Z-A-C型、X-Y-Z-A-B型解釋器，用以支持五軸數(shù)控系統(tǒng)譯碼功能，并為數(shù)控系統(tǒng)的可配置功能提供配置項。

如圖6所示，數(shù)控系統(tǒng)解釋器正在執(zhí)行1個五軸數(shù)控加工程序的譯碼。將X-Y-Z-A-C型譯碼解釋器配置到所開發(fā)的數(shù)控系統(tǒng)中。從圖6(a)中可以看出，該數(shù)控程序解釋編譯并未發(fā)現(xiàn)錯誤。而當數(shù)控加工程序中出現(xiàn)“B”或“b”時，如圖6(b)所示，人機界面中出現(xiàn)錯誤提示“其他非法的數(shù)控代碼或符號存在”，并且準確定位到所處行數(shù)。這是由于所開發(fā)的解釋器是X-Y-Z-A-C型的，無法識別含“B”或“b”字符的數(shù)控加工程序，所以在詞析階段就顯示錯誤提示。

圖6 解釋器X-Y-Z-A-C型五軸譯碼結果比較

同樣，如圖7所示，在所開發(fā)的數(shù)控系統(tǒng)中的譯碼解釋器配置為X-Y-Z-A-B型。在圖7(a)中該解釋器能夠識別數(shù)控程序中的“B”代碼并完成譯碼功能。在圖7(b)無法識別“C”代碼，故在人機界面中提示第9行有錯誤：“其他非法的數(shù)控代碼或符號存在”。并且系統(tǒng)能夠及時地識別出不符合規(guī)則的代碼段，如第6行錯誤：“同一行中存在兩個字符B”，第8行錯誤：“B字符后面不存在數(shù)字”。

圖7 解釋器X-Y-Z-A-B型五軸譯碼結果比較

如圖8所示，以X-Y-Z-A-C型為例，將譯碼成功的五軸加工程序輸送到加工仿真模塊進行模擬仿真。實驗結果證明：所開發(fā)的解釋器符合預期的要求，能夠較好地實現(xiàn)五軸數(shù)控加工程序的譯碼并進行仿真加工。

圖8 解釋器X-Y-Z-A-C型五軸模擬仿真

為了驗證本譯碼解釋器能夠為后續(xù)的處理模塊提供正確的譯碼數(shù)據(jù)，采用圖8中的五軸數(shù)控程序，以直線加減速算法為例進行了仿真實驗。直線加減速參數(shù)設定為：進給速度F為500mm/min，各直線軸的最大允許速度為3 000mm/min，各軸最大加速度為1 000mm/s2。如圖9所示為所獲得的進給速度曲線圖?？芍忉屍鳛楹罄m(xù)的速度處理模塊提供了正確的譯碼數(shù)據(jù)，能夠滿足數(shù)控系統(tǒng)的加工需求。

圖9 進給速度曲線圖

4 結語

基于Linux平臺開發(fā)了數(shù)控程序解釋器，該解釋器采用緩沖區(qū)中斷機制進行分段預讀譯碼，避免了PC機資源浪費和由于實時性差導致的指令獲取不連續(xù)的問題；并且該解釋器根據(jù)模塊化設計思路，采用面向對象技術進行開發(fā)不同類型的五軸譯碼解釋器，滿足可配置功能需求。程序結構簡單明了，代碼簡潔高效，具有良好的開放性和通用性。經(jīng)過實驗證明，該解釋器實現(xiàn)了對數(shù)控機床各種指令和功能的正確解釋譯碼，完全可以用于計算機實際加工和仿真。該編譯器在開放式數(shù)控系統(tǒng)的開發(fā)、可配置功能的實現(xiàn)和數(shù)控虛擬仿真軟件的開發(fā)方面有很好的應用前景。