基于研華PCI_1680 的裁床專用通訊協(xié)議的實(shí)現(xiàn)

陳 波， 熊 金

（綿陽(yáng)市維博電子有限責(zé)任公司 四川 綿陽(yáng) 621000）

數(shù)控大型服裝裁剪機(jī)（以下簡(jiǎn)稱裁床系統(tǒng)）是服裝CAM設(shè)備中的高端產(chǎn)品，此設(shè)備的主要優(yōu)點(diǎn)是：服裝生產(chǎn)自動(dòng)化程度高，裁剪速度快，生產(chǎn)周期縮短，布料利用率高，節(jié)約成本，裁剪衣片質(zhì)量好，不會(huì)受人為因素影響。 盡管我國(guó)服裝產(chǎn)業(yè)憑借產(chǎn)量和規(guī)模創(chuàng)造出驕人的業(yè)績(jī)，但產(chǎn)業(yè)發(fā)展面臨的問(wèn)題也不容忽視。 與發(fā)達(dá)國(guó)家相比，我國(guó)服裝生產(chǎn)信息化、自動(dòng)化水平非常低。 以計(jì)算機(jī)、網(wǎng)絡(luò)、先進(jìn)制造等為代表的先進(jìn)技術(shù)，在發(fā)達(dá)國(guó)家服裝業(yè)已廣泛用于生產(chǎn)自動(dòng)化、信息采集傳遞、產(chǎn)品設(shè)計(jì)、生產(chǎn)管理、電子商務(wù)等環(huán)節(jié)。 目前，在工業(yè)控制系統(tǒng)中，CAN 總線在完成現(xiàn)場(chǎng)的控制器、 執(zhí)行器等底層設(shè)備間的數(shù)據(jù)通信方面正發(fā)揮著巨大的作用。

CAN 作為現(xiàn)場(chǎng)設(shè)備級(jí)的通信總線， 和其他總線相比，具有很高的可靠性和性價(jià)比。 CAN 接口芯片的生產(chǎn)廠家眾多，協(xié)議開(kāi)放，并且使用方便，由此看出CAN 總線將成為今后眾多領(lǐng)域的發(fā)展方向。 由于裁床系統(tǒng)在運(yùn)行過(guò)程中需要通信的數(shù)據(jù)通訊量大、通訊速度要求快，與一般的通訊總線相比，采用CAN 總線的進(jìn)行數(shù)據(jù)通訊具有更突出的優(yōu)點(diǎn)[1]。 基于上述原因本文主要應(yīng)用VC 開(kāi)發(fā)出供用戶調(diào)用的動(dòng)態(tài)鏈接庫(kù)文件，以驅(qū)動(dòng)研華CAN 卡PCI_1680，從而實(shí)現(xiàn)了工控機(jī)與CAN總線之間的數(shù)據(jù)傳輸， 然后通過(guò)CAN 總線連接上位機(jī)和下位機(jī)從站。

1 總體設(shè)計(jì)PCI_1680CAN 通訊卡簡(jiǎn)介

通信卡插在工控機(jī)的PCI 總線槽中，其整體結(jié)構(gòu)可以分為3 個(gè)部分， 即CAN 總線接口部分、PCI 總線接口部分和通信控制部分。研華公司生產(chǎn)的PCI_1680 為CAN_PCI 轉(zhuǎn)換卡，該卡支持CAN2. 0A 和CAN2. 0B 協(xié)議， 主要應(yīng)用于微機(jī)與CAN 總線的數(shù)據(jù)交換。 其附帶的動(dòng)態(tài)鏈接庫(kù)（DLL）封裝了共享資源和代碼，是一種基于Windows 的應(yīng)用程序模塊，它可以在程序運(yùn)行時(shí)被裝入和鏈接，使用DLL 封裝技術(shù)大大節(jié)約了內(nèi)存，提高了開(kāi)發(fā)的效率[2-3]。研華PCI_1680 CAN 通信卡如圖1 所示。

軟件工具包中的CANbus2.0.h 已經(jīng)聲明了控制該卡進(jìn)行CAN 數(shù)據(jù)收發(fā)的一些API 函數(shù)，用戶只需調(diào)用函數(shù)即可實(shí)現(xiàn)對(duì)CAN 總 線 的 數(shù) 據(jù) 讀 寫(xiě) 操 作。 將m_Port、m_DeviceNum、m_nBTR0、m_nBTR1 做為輸入?yún)?shù)，其中，m_Port 是所打開(kāi)CAN卡的端口號(hào)，m_DeviceNum 是所選設(shè)備編號(hào)，PCI- 1680 的波特率是由m_nBTR0 和m_nBTR1 兩個(gè)參數(shù)確定的。PCI_1680通信卡軟件包中的API 函數(shù)及其功能主要有以下一些：

圖1 研華PCI_1680 CAN 通信卡Fig. 1 Yanhua PCI_680 communication card

打開(kāi)CAN 通信端口

CANPortOpen（m_DeviceNum， m_ Port，hostID， Baudrate）

初始化CAN 端口

CANInit（m_ Port， m_nBTR0， m_nBTR1， IntMask）

設(shè)置輸出控制寄存器

CANSetOutCtrl（m_ Port， m_nOutCtrlCode）

設(shè)置掩碼寄存器

CANSetAcp（m_ Port， m_nAcpCode， m_nAcpMask）

設(shè)置CAN 通信協(xié)議類型

CANSetProtocolType（m_ Port， m_wProtocolType）

設(shè)置波特率大小

CANSetBaud（m_ Port， m_nBTR0， m_nBTR1）

設(shè)置端口為正常模式

CANSetNormal（m_ Port）

允許事件觸發(fā)機(jī)制

CANEnableEvent（m_ Port， TRUE）

允許接收中斷

CANEnableRxInt（m_ Port）

設(shè)置接收緩沖區(qū)

CANSetBufferPtr（m_ Port， TRUE）

等待CAN 總線上數(shù)據(jù)

CANWaitForFIFOEvent（m_ Port）

關(guān)閉CAN 通信端口

CANPortClose（m_ Port）

下面以CAN2.0A 為例介紹一下調(diào)用API 函數(shù)的流程。其中圖2（a）為發(fā)送數(shù)據(jù)流程，圖2（b）為接收數(shù)據(jù)流程。

圖2 調(diào)用API 函數(shù)順序流程圖Fig. 2 Flow chart of transfer API function

2 裁床系統(tǒng)中PCI_1680CAN 通信模塊的具體實(shí)現(xiàn)

一般來(lái)說(shuō)，CAN 通信協(xié)議規(guī)定了4 種不同的幀格式：數(shù)據(jù)幀、遠(yuǎn)程幀、錯(cuò)誤幀和超載幀。 其中數(shù)據(jù)幀用于攜帶數(shù)據(jù)從發(fā)送器至接收器；遠(yuǎn)程幀是由總線單元發(fā)出的，用于請(qǐng)求發(fā)送具有同一識(shí)別符的數(shù)據(jù)幀；任何單元檢測(cè)到總線錯(cuò)誤就發(fā)出錯(cuò)誤幀；超載幀用以在先行的和后續(xù)的數(shù)據(jù)幀（或遠(yuǎn)程幀）之間提供附加的延時(shí)。 裁床系統(tǒng)的體系結(jié)構(gòu)，決定了系統(tǒng)是以裁剪文件數(shù)據(jù)收發(fā)和工作模式管理為核心來(lái)工作的，這也決定了CAN 通信模塊作為信息交換的主導(dǎo)地位， 在系統(tǒng)運(yùn)行管理中起著非常重要的作用，同時(shí)也是提高系統(tǒng)工作安全性與可靠性的關(guān)鍵所在[4]。

使用PCI_1680 通信卡之前必須根據(jù)所使用的通信協(xié)議對(duì)CAN 端口進(jìn)行初始化操作，包括打開(kāi)CAN 端口、設(shè)置波特率大小、允許接收中斷等操作；其次是進(jìn)行CAN 數(shù)據(jù)交互操作，包括數(shù)據(jù)發(fā)送和數(shù)據(jù)接收；最后，在退出通信程序的時(shí)候關(guān)閉CAN 端口。 參數(shù)正確進(jìn)行初始化操作，這可以通過(guò)工具包中的函數(shù)調(diào)用來(lái)實(shí)現(xiàn)。 當(dāng)上述工作完成之后，可以通過(guò)下面2 個(gè)函數(shù)實(shí)現(xiàn)對(duì)CAN 總線的收發(fā)數(shù)據(jù)操作：

LRESULT FTYPE CANWriteFile（WORD Port，BOOL FAR*Ready， PVOID FAR SendBuf）；

LRESULT FTYPE CANWaitForFIFOEvent （WORD Port，ULONG timeout， BOOL * bReady ）；

在CAN 通信模塊中， 通信模塊在每個(gè)通信周期內(nèi)被調(diào)用一次。 因此，在模塊中定義一個(gè)初始化標(biāo)志位Init_sign，初始值為0（False），當(dāng)初始化后把該位置為1（True），以保證在下一個(gè)周期內(nèi)不會(huì)再次初始化變量， 而直接進(jìn)行CAN 數(shù)據(jù)交互。 具體流程圖如圖3 所示。

圖3 CAN 通信模塊的具體實(shí)現(xiàn)流程圖Fig. 3 Material flow chart of CAN communication module

CAN 參數(shù)初始化完畢后啟動(dòng)通信線程，首先由上位機(jī)向下位機(jī)發(fā)送復(fù)位命令，延時(shí)10ms 后再發(fā)送同步信號(hào)，然后根據(jù)裁床系統(tǒng)的工作模式及狀態(tài)進(jìn)行數(shù)據(jù)的交換。 根據(jù)初始化配置 CANWriteFile 往 CAN 總線上發(fā)送一幀數(shù)據(jù)，CANWaitForFIFOEvent 等待接收CAN 總線上發(fā)來(lái)的數(shù)據(jù)。具體的算法如下：

首先定義存儲(chǔ)CAN 2. 0A 信息幀的數(shù)據(jù)結(jié)構(gòu)如下：

typedef struct

{

UCHAR ff；

UCHAR rtr；

ULONG id；

UCHAR dlen；

UCHAR data[8]；

} CAN_MSG_T_EX， *PCAN_MSG_T_EX；

每一個(gè)MSG 變量記錄了CAN 的ID 號(hào)及8 字節(jié)的數(shù)據(jù)信息。由于CAN2. 0A 規(guī)定ID 為11 位，但是字符串中的每一個(gè)字符僅有8 位，因此應(yīng)該將ID 分為兩個(gè)字符來(lái)存儲(chǔ)，數(shù)據(jù)幀信息ID 的長(zhǎng)度為11 位，接收緩沖區(qū)可以定義成一個(gè)包含有1024 個(gè)MSG 變量的結(jié)構(gòu)體數(shù)組ReceiveMSG [1024]，同理， 發(fā)送緩沖區(qū)可以設(shè)計(jì)成SendMSG [1024]。 CAN 標(biāo)識(shí)符對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)定義如下[6]：

typedef union

{

struct

{

//通信命令

unsigned __int16Command :5；

//工作模式切換要求：1－－要求切換

unsigned __int16 WorkModeSwitch :1；

//幀標(biāo)記:0－－中間幀，1－－結(jié)束幀

unsigned __int16 FrameFlag :1；

//目標(biāo)地址

unsigned __int16 TargetAddr :2； //源地址

unsigned __int16 SourceAddr :2； //郵箱編號(hào)

unsigned __int16 MboxIV :5；

}bit；

unsigned __int16 all；

}CANCOMMAND；

當(dāng)CAN 總線上檢測(cè)到一幀新的數(shù)據(jù)之后， 先判斷它的ID 號(hào)，然后把ID 號(hào)和數(shù)據(jù)信息存入到數(shù)組相應(yīng)的位置。當(dāng)要發(fā)送一幀信息時(shí)，我們只要將數(shù)組中對(duì)應(yīng)的數(shù)值發(fā)送到總線上即可[7]，比如上位機(jī)向下位機(jī)發(fā)送回裁床系統(tǒng)參考點(diǎn)的命令，我們只要從CANCOMMAND 中取出相應(yīng)數(shù)值發(fā)到總線上。

//通信命令為回參考點(diǎn)

SendObj.id.bit.Command = CanCmd_Reference；

//數(shù)據(jù)類型為空

SendObj.id.bit.DataType = CanDataType_Empty；

//幀重復(fù)標(biāo)記位0

SendObj.id.bit.RepeatFlag = 0；

//幀結(jié)束標(biāo)記為1

SendObj.id.bit.FrameFlag = 1；

//數(shù)據(jù)長(zhǎng)度為0

SendObj.dlen = 0；

3 裁床系統(tǒng)數(shù)據(jù)交換相關(guān)命令字及內(nèi)容

3.1 裁床系統(tǒng)數(shù)據(jù)交換相關(guān)命令字

在本系統(tǒng)中， 考慮到上位機(jī)是基于Windows 操作系統(tǒng)，主要是以線程方式來(lái)完成數(shù)據(jù)的循環(huán)接收或發(fā)送；而下位機(jī)是基于DSP 的，可以方便的采用中斷方式完成數(shù)據(jù)的發(fā)送和接收，所以本協(xié)議中的信息交換主要以下位機(jī)為主，由下位機(jī)主動(dòng)向上位機(jī)發(fā)送數(shù)據(jù)信息；而上位機(jī)一般不主動(dòng)發(fā)送連續(xù)的信息，主要以單個(gè)命令的方式主動(dòng)向下位機(jī)發(fā)送，以完成簡(jiǎn)短的數(shù)據(jù)交換[4]。命令字（占報(bào)文ID 的D4～D0 位）主要包括以下內(nèi)容：

#define FirstSynchronization 0x0001

#define GetSlaveVersion 0x0002

#define ForbidEchoplexData 0x0003

#define PermitEchoplexData 0x0004

#define ParaTransmit 0x0005

#define ACK 0x0006

#define ResponseCommand 0x0007

#define SlaveSoftwareUpdate 0x0008

#define RequestEchoplexSpecifcData 0x0009

#define SlaveEchoplexData 0x000a

#define AutoDataTransimit 0x000b

#define ExitSys 0x000c

3.2 裁床系統(tǒng)數(shù)據(jù)交換內(nèi)容

裁床控制系統(tǒng)中，上下位機(jī)交換的內(nèi)容主要包括以下幾個(gè)方面：

1）上位機(jī)向下位機(jī)傳遞的命令字及命令參數(shù)；

2）上位機(jī)向下位機(jī)傳遞的參數(shù)信息；

3）下位機(jī)向上位機(jī)傳遞的坐標(biāo)信息；

4）下位機(jī)向上位機(jī)傳遞的報(bào)警信息；

5）下位機(jī)向上位機(jī)傳遞的當(dāng)前系統(tǒng)狀態(tài)信息。

上、下位機(jī)的系統(tǒng)控制程序啟動(dòng)后，下位機(jī)DSP 的程序先于上位機(jī)的程序運(yùn)行，且一直處于接收監(jiān)聽(tīng)狀態(tài)，在接到上位機(jī)允許回送數(shù)據(jù)的命令之前，禁止主動(dòng)向上位機(jī)發(fā)送信息，除非上位機(jī)有對(duì)下位機(jī)回送指定信息的要求。 該命令是由上位機(jī)主動(dòng)向下位機(jī)發(fā)起的， 只用在系統(tǒng)程序啟動(dòng)時(shí)，且只進(jìn)行1 次。 通過(guò)該命令的執(zhí)行，上下位機(jī)則完成通信鏈路的建立，完成正式通訊的同步[5]。

3.2.1 IPC 方的處理流程

以上位機(jī)向下位機(jī)傳遞參數(shù)為例，該命令屬于上位機(jī)主動(dòng)向下位機(jī)傳遞的控制命令。 該命令使用比較廣泛，除了在首次同步完成且獲得下位機(jī)版本號(hào)以后，首次完成所有參數(shù)向下位機(jī)的傳遞外，還可在中間完成實(shí)時(shí)修改的參數(shù)向下位機(jī)的傳遞。 上位機(jī)在發(fā)起該命令之前，必須保證下位機(jī)已經(jīng)停止了主動(dòng)向上位機(jī)回傳數(shù)據(jù)的過(guò)程，即是說(shuō)，上位機(jī)已經(jīng)向下位機(jī)成功發(fā)送了“ForbidEchoplexData”的命令，獲取了對(duì)通訊總線的控制權(quán)。

IPC 方按如下約定組織報(bào)文ID 和郵箱內(nèi)容如表1 所示。

表1 IPC 方報(bào)文ID 和郵箱內(nèi)容Tab. 1 IPC message ID and email content

注：

1）郵箱的第0、第1 個(gè)字節(jié)表示參數(shù)傳遞的子命令，與參數(shù)項(xiàng)相對(duì)應(yīng)（具體編碼參見(jiàn)前面的“ParaTransmit”子命令的定義部分），郵箱后續(xù)字節(jié)表示參數(shù)內(nèi)容。

2）如果該項(xiàng)參數(shù)的內(nèi)容超過(guò)6 個(gè)字節(jié)，則上位機(jī)需要繼續(xù)發(fā)送后續(xù)幀， 但后續(xù)幀的內(nèi)容則從郵箱的字節(jié)0 開(kāi)始存放。 即后續(xù)幀中，不再有表示參數(shù)編號(hào)的內(nèi)容；

3）上位機(jī)在設(shè)置本次幀傳遞長(zhǎng)度時(shí)需要根據(jù)本次理論要傳遞的字節(jié)數(shù)設(shè)置；

4）在準(zhǔn)備每一幀，上位機(jī)必須根據(jù)數(shù)據(jù)內(nèi)容長(zhǎng)度，正確設(shè)置標(biāo)識(shí)符的D6 位；

5）上位機(jī)傳遞完一幀后，必須在得到下位機(jī)的ACK 回復(fù)后，才繼續(xù)傳遞下一幀；上位機(jī)在超時(shí)檢測(cè)后或收到下位機(jī)的NAK 應(yīng)答，將自動(dòng)退出本項(xiàng)參數(shù)的傳遞；

6）多項(xiàng)參數(shù)，均要求上位機(jī)重復(fù)上述步驟1）～5），不同參數(shù)項(xiàng)的編號(hào)需要上下位機(jī)事先約定好。

3.2.2 下位機(jī)DSP 的處理流程

DSP 在識(shí)別到參數(shù)傳遞的命令幀后，根據(jù)幀內(nèi)容和幀狀態(tài)，立即向IPC 回送ACK 應(yīng)答幀，其格式如表2 所示。

表2 DSP 回送ACK 應(yīng)答幀格式Tab. 2 The DSP echo ACK response frame format

而下位機(jī)每傳送完一次， 必須在收到上位機(jī)的ACK 應(yīng)答后，方可繼續(xù)后續(xù)幀的傳送。 如果一個(gè)完整的數(shù)據(jù)信息包傳遞完成，則幀結(jié)束標(biāo)記應(yīng)置為1。 由于裁料在裁剪過(guò)程中，上位機(jī)向下傳遞自動(dòng)加工數(shù)據(jù)和下位機(jī)回送狀態(tài)數(shù)據(jù)是在連續(xù)交叉進(jìn)行的，必須控制好總線的爭(zhēng)用。 一方面上位機(jī)可以在向下會(huì)機(jī)傳遞自動(dòng)加工數(shù)據(jù)時(shí)，可以先禁止下位機(jī)回送狀態(tài)信息，在自動(dòng)加工數(shù)據(jù)傳送到一定量時(shí)，再允許下位機(jī)回送狀態(tài)數(shù)據(jù)；而下位機(jī)如果要回送狀態(tài)，也可根據(jù)狀態(tài)是否變化了來(lái)確定回送與否，且可以回送指定的數(shù)據(jù)，即下位機(jī)掌握回送內(nèi)容的主動(dòng)權(quán)。

4 結(jié)束語(yǔ)

CAN 總線是一種具有國(guó)際標(biāo)準(zhǔn)且性能價(jià)格比比較高的現(xiàn)場(chǎng)總線，在自動(dòng)控制領(lǐng)域的發(fā)展中起著中要作用[7]。 本文首先根據(jù)裁床控制系統(tǒng)自身的特點(diǎn)， 采用了研華PCI_1680 CAN 通信卡進(jìn)行數(shù)據(jù)的交互。 實(shí)踐證明，該通信卡完全能滿足通信要求，其附帶的API 函數(shù)設(shè)計(jì)簡(jiǎn)單，且使用方便，實(shí)時(shí)性強(qiáng)， 具備一定的抗干擾能力， 達(dá)到了預(yù)定的設(shè)計(jì)目的。

[1] 趙君，劉衛(wèi)國(guó)，譚博. 基于CAN總線的分布式多電機(jī)控制研究[J] .兵工自動(dòng)化，2010，29（12）:73－74.

[2] 魏長(zhǎng)軍，吳青，陳興寶，等. 基于工具包的研華PCI_1680通訊卡OPC服務(wù)器軟件的實(shí)現(xiàn)[J]. 河南理工大學(xué)學(xué)報(bào)，2008，27（4）:437－439.

[3] 孟詔，楊建武，孫樹(shù)文. 基于VC 供Labview 調(diào)用的CAN 卡驅(qū)動(dòng)設(shè)計(jì)[J]. 微計(jì)算機(jī)信息，2008，24（9）:177－179.

[4] 趙勇，黃大貴，吳獻(xiàn)剛. 開(kāi)放式數(shù)控裁床軟件系統(tǒng)的研發(fā)[J].微計(jì)算機(jī)信息， 2009，25（2）:163－165.

[5] 易軍.基于CAN總線技術(shù)的一類智能節(jié)點(diǎn)開(kāi)發(fā)及應(yīng)用.監(jiān)控技術(shù)，2003（7）:31－35.

[6] 章富元，方江龍，湯季安. 我國(guó)數(shù)控技術(shù)發(fā)展的思考[J]. 中國(guó)機(jī)械工程，1999（10）:1100－1103.

[7] 黃河. 高浪琴 基于CAN總線通訊智能節(jié)點(diǎn)的設(shè)計(jì)與實(shí)現(xiàn)[J].江西科學(xué)，2004:289－292.