鄧有緯，盛玉林，嚴凡華

(1.國電南京自動化股份有限公司，南京 210032； 2.南京化學工業(yè)園熱電有限公司，南京 210047)

0 引言

在我國燃煤發(fā)電機組中，煤耗統(tǒng)計依據(jù)主要是入爐煤皮帶秤計量數(shù)據(jù)，但計量數(shù)據(jù)有些是通過可編程邏輯控制器(PLC)采集皮帶秤稱重顯示控制儀輸出的模擬量累計得到的，有些是通過PLC采集皮帶秤稱重顯示控制儀發(fā)出的脈沖值累計得到的，有些數(shù)據(jù)甚至是人工現(xiàn)場抄寫得到的。由于輸煤系統(tǒng)的強電磁干擾[1]以及人工抄寫時可能存在的差錯，使得數(shù)據(jù)的統(tǒng)計存在較大誤差，為了解決這一問題，本文探討如何對入爐煤皮帶秤計量數(shù)據(jù)進行準確遠傳，減少干擾及人工抄寫造成的誤差。

1 工程概況

南京化學工業(yè)園熱電有限公司一期工程為3臺220 t/h鍋爐，二期擴建工程為2臺1 025 t/h鍋爐，設(shè)置A/B兩側(cè)入爐煤皮帶，每條入爐煤皮帶各配置1臺電子皮帶秤進行入爐煤計量。

輸煤程控系統(tǒng)通過PLC+上位機來完成系統(tǒng)的監(jiān)控與操作。PLC為施耐德Unity Quantum 67160雙機熱備系統(tǒng)，上位機為iFIX4.0；入爐煤皮帶秤稱重顯示控制儀為拉姆齊Micro-TechTM2000系列。稱重顯示控制儀輸出4～20 mA信號，接入輸煤程控系統(tǒng)PLC，以顯示皮帶秤瞬時流量；輸出無源節(jié)點信號接入輸煤程控系統(tǒng)高速計數(shù)模塊，供輸煤程控系統(tǒng)進行累積值的計算，但皮帶速度未接入程控系統(tǒng)進行監(jiān)視。各班組上煤后，人工抄寫稱重顯示控制儀數(shù)據(jù)并與輸煤程控系統(tǒng)累計值進行比對，最終以人工抄表數(shù)值為準。為此，可以考慮將稱重顯示控制儀直接以通信的方式接入輸煤程控系統(tǒng)PLC，這樣就可以避免電流信號、無源節(jié)點信號受到干擾而造成誤差，也省去了人工抄表的麻煩。

2 通信接口及協(xié)議

2.1 稱重顯示控制儀通信接口及協(xié)議

拉姆齊Micro-TechTM2000系列稱重顯示控制儀是一種基于總線的微處理器儀表，可以根據(jù)需要選配1～2塊串口通信板，每塊串口通信板都有1個串行通道[2]，可根據(jù)表1進行配置；同時，該控制儀還支持多種軟件通信協(xié)議，見表2。拉姆齊Micro-TechTM2000系列稱重顯示控制儀選擇不同的串行通信標準時，需要更改串行通信板上跳線的位置，其端子上的連接也不一樣，具體參見儀表說明書。

表1 Micro-TechTM2000系列稱重顯示控制儀支持的通信標準Tab.1 Communication standards supported by the Micro-TechTM 2000 series weighing display controller

表2 Micro-TechTM2000系列稱重顯示控制儀支持的通信協(xié)議Tab.2 Communication protocols supported by the Micro-TechTM 2000 series weighing display controller

2.2 輸煤PLC通信接口及協(xié)議

Unity Quantum 67160支持標準的ModBus協(xié)議通信，ModBus端口位于中央處理器(CPU)的前面，接口為RJ45，如圖1所示。該ModBus端口既支持RS232串行通信標準，也支持RS485串行通信標準，不同的串行通信標準采用不同的網(wǎng)絡(luò)拓撲結(jié)構(gòu)，RJ45上的連接也不一樣，其引腳定義見表3。

2.3 輸煤PLC與稱重顯示控制儀的連接

由于RS232只支持點對點的訪問，因此PLC對2臺稱重顯示控制儀的通信不宜采用RS232通信標準。而RS485支持以處理器作為主站的一主多從總線拓撲結(jié)構(gòu)，且稱重顯示控制儀和PLC都支持ModBus協(xié)議，所以PLC與稱重顯示控制儀的通信標準選用RS485，協(xié)議選擇ModBus。根據(jù)稱重顯示控制儀說明書設(shè)置通信板跳線：op1：B，op2：A，op3：B，op4：B，op5：B，op6：C。PLC與稱重顯示控制儀通信接線如圖2所示。

圖1 ModBus 端口示意Fig.1 ModBus port schematic

表3 RJ45接口引腳定義Tab.3 RJ45 interface pin definition

注：在RS485通信標準，引腳 1和6，2和3必須短接。

圖2 PLC與稱重顯示控制儀通信接線Fig.2 Communication wiring of PLC and weighing display controller

在該通信接線中，雖然物理上存在2臺PLC，但在Quantum Hot Standby系統(tǒng)中，只有運行為主的CPU上的端口可用于ModBus，在默認情況下，發(fā)生主、備切換時，主、備CPU交換ModBus地址，因此在邏輯上主、備CPU為1個ModBus節(jié)點。

3 通信要求分析和軟件實現(xiàn)

3.1 通信要求分析

拉姆齊Micro-TechTM2000系列稱重顯示控制儀在通信中通常作為從站，接收主站的請求消息，而不主動發(fā)出消息。當通信線路中主站發(fā)出請求消息時，稱重顯示控制儀由中斷程序接收消息；接收完畢后，在周期性任務(wù)(100 ms/次)中核對消息中的設(shè)備地址；當消息中的地址與控制儀的地址匹配時，則檢查消息的正確性，若消息正確，則處理請求消息生成應(yīng)答消息，應(yīng)答消息最多為41個字[2]。因此，數(shù)據(jù)訪問時，主站發(fā)出請求消息的時間間隔必須大于100 ms且請求消息不得超過41個字。

然而，對于需要向顯示控制儀寫入數(shù)據(jù)的請求消息(對應(yīng)ModBus功能碼10H)，成功地返回響應(yīng)消息并不代表數(shù)據(jù)已寫入顯示控制儀，在顯示控制儀的當前任務(wù)周期中還需要核對地址、數(shù)據(jù)上下限、口令等，只有滿足要求后數(shù)據(jù)才會被寫入顯示控制儀，并將標志位置0，否則置1。因此，主站在向顯示控制儀發(fā)送寫入數(shù)據(jù)請求后還需等待100 ms，再發(fā)送一條查詢標志位的請求消息，以確認數(shù)據(jù)被成功地寫入顯示控制儀。

對于主站140CPU67160，UnityPro軟件提供了XXMIT功能塊，管理CPU上的ModBus端口通信。當采用RS485標準通信時，由于RS485是半雙工通信，任何時候只能有一點處于發(fā)送狀態(tài)，在不發(fā)送的時候都處于接收狀態(tài)[3]，因此，當某一節(jié)點需要發(fā)送時將自身狀態(tài)切換成發(fā)送，然后開始發(fā)送數(shù)據(jù)，發(fā)送完畢后再切換至接收狀態(tài)。雖然該切換由XXMIT進行內(nèi)部控制，不需要編程人員進行組態(tài)，但通信設(shè)計時仍需關(guān)注發(fā)送、接收之間的切換。

當XXMIT進行ModBus通信時，對于非廣播的ModBus消息，應(yīng)用程序需要在傳送消息后從其他設(shè)備獲得回答(請求-響應(yīng))[4]，則XXMIT 需要從傳送模式切換為接收模式，來讀取通信合作方的響應(yīng)。PLC將XXMIT 從傳送切換為接收模式的最早時刻是緊接傳送操作后的下一個掃描周期[5]，即使在最少消息最快傳遞時，主站PLC至少需要2個掃描周期才能完成1個非廣播的ModBus消息傳遞，如圖3所示。

圖3 XXMIT傳送、接收模式轉(zhuǎn)換及從站響應(yīng)示意Fig.3 XXMIT transmission,reception mode conversion and response from slave station

當主站的掃描周期長而從站的響應(yīng)速度快時，從站的響應(yīng)延時尤為重要[5]。否則，主站發(fā)送完數(shù)據(jù)后，XXMIT仍處于當前掃描周期中，未切換為接收模式，主站還處在發(fā)送狀態(tài)；而從站接收完數(shù)據(jù)后開始響應(yīng)，則從站已切換為發(fā)送狀態(tài)，導(dǎo)致RS485通信中有2點處于發(fā)送狀態(tài)。為了避免這種狀態(tài)，從站的ModBus消息響應(yīng)應(yīng)延時，延時時間=主站掃描周期-請求消息的發(fā)送時間，即使延時時間小于主站的掃描周期，為了保證通信順利，建議設(shè)置從站的延時時間為主站掃描周期。

當從站無法設(shè)置響應(yīng)消息延時時，應(yīng)讓主站的XXMIT盡快從傳送模式切換為接收模式，雖然縮短主站的掃描周期可以盡快完成模式切換，但由于主站的掃描周期受工藝過程即應(yīng)用程序的限制，所以通過縮短主站掃描周期來使切換時間縮短的幅度有限。

對RS485而言，雖然請求發(fā)送/清除發(fā)送(RTS/CTS)硬件控制流不受控制，但輸入的StartDly和EndDly值依然對通信產(chǎn)生影響：StartDly輸入的時間值確定了XXMIT在將消息發(fā)出PLC端口前等待的時間長度；EndDly輸入的時間值確定了 XXMIT 在將消息發(fā)出PLC端口后等待的時間長度[5]，如圖4所示(圖中：DCE為數(shù)據(jù)通信設(shè)備；TXD為發(fā)送數(shù)據(jù))。EndDly值的設(shè)置，將延遲主站的XXMIT從發(fā)送模式切換為接收模式。

圖4 RTS/CTS控制時序圖Fig.4 Sequence diagram with RTS/CTS control

在RS485通信時， 發(fā)送信號在EndDly時間內(nèi)保持為“1”，即節(jié)點的發(fā)送端口(TX)處于使能狀態(tài)，接收端口(RX)禁止。當主站非廣播的ModBus請求消息發(fā)送完畢EndDly結(jié)束前，由于無RTS/CTS硬件控制，異步掃描的從站會進行消息響應(yīng)，即從站發(fā)送消息，則從站的TX處于使能狀態(tài)，此時主站的TX也處于使能狀態(tài)，必然導(dǎo)致線路沖突(如圖5所示)，從而將丟失來自從站響應(yīng)的所有字符。因此，EndDly時間設(shè)置會導(dǎo)致以下問題：主站請求消息發(fā)送完畢后，從站消息響應(yīng)開始時，應(yīng)禁止的主站TX使能延時EndDly禁止，應(yīng)使能的主站RX延時EndDly使能，亦即XXMIT延時EndDly從發(fā)送模式切換為接收模式。對此，可將EndDly設(shè)置為0，以讓主站CPU盡快切換發(fā)送和接收。

圖5 無RTS/CTS控制的響應(yīng)沖突時序圖Fig.5 Sequence diagram of response conflict without RTS/CTS control

當主站對從站數(shù)據(jù)實時性要求不高，或由于生產(chǎn)實際情況導(dǎo)致從站數(shù)據(jù)變化率不快，亦或從站對于主站的請求周期有時間要求時，可對StartDly設(shè)置稍長的時間，以減少主站的請求頻率和從站的響應(yīng)頻率，例如設(shè)置為500 ms，則主站發(fā)出下一個請求時，至少需要等待500 ms。

3.2 軟件實現(xiàn)

該項目要求讀取2臺稱重顯示控制儀的瞬時流量、皮帶速度、累計流量至PLC并送上位機顯示。Micro-Tech 2001，2101系列稱重顯示控制儀數(shù)據(jù)定義見表4。

表4 稱重顯示控制儀數(shù)據(jù)定義Tab.4 Data definition of weighing display controller

由于地址400095～400144的長度超過了41個字，因此瞬時流量、皮帶速度、累計流量需要分2次讀取。根據(jù)ModBus請求-響應(yīng)的通信機制，同一時刻主站只能和一臺從站通信，所以，獲取2臺稱重顯示控制儀的數(shù)據(jù)需要4次ModBus通信才能完成。

首先，設(shè)定好稱重顯示控制儀的通信參數(shù)，包括設(shè)備地址、波特率、數(shù)據(jù)位、停止位、校驗方式等。然后在UntiyPro軟件中利用XXMIT功能塊進行組態(tài)編程：設(shè)置Port為1；Command為16#2100，即啟用RS485模式，選擇ModBus消息傳遞；MsgOut是主站PLC向從站稱重顯示控制儀發(fā)送ModBus消息的具體內(nèi)容，包括ModBus功能碼、讀取或?qū)懭氲臄?shù)據(jù)長度、從設(shè)備地址、從設(shè)備數(shù)據(jù)區(qū)起始地址、主設(shè)備數(shù)據(jù)區(qū)起始地址等；功能塊波特率、數(shù)據(jù)位、停止位、校驗方式與從站保持一致，如圖6所示。

圖6 XXMIT功能塊實例Fig.6 An example of XXMIT function module

在程序中定義Int型的標志Flag，初始值設(shè)置為1，系統(tǒng)初始化完成后XXMIT開始執(zhí)行，當Flag=1時，主站向A稱重顯示控制儀發(fā)送一條ModBus消息，讀取400095～400100的值，成功后(管腳Done為1)Flag自動加1變?yōu)?；當Flag=2時，主站再向A稱重顯示控制儀發(fā)送一條ModBus消息，讀取400141～00142的值，成功后Flag自動加1變?yōu)?；當Flag=3時，主站向B稱重顯示控制儀發(fā)送一條ModBus消息，讀取400095～400100的值，成功后Flag自動加1變?yōu)?；當Flag=4時，主站再向B稱重顯示控制儀發(fā)送一條ModBus消息，讀取400141～400142的值，成功后Flag復(fù)位為1，開始第2輪數(shù)據(jù)交換，如此循環(huán)。

如果某個ModBus通信出現(xiàn)故障(管腳Error為1)，F(xiàn)lag也需自動加1，讓程序跳過該故障繼續(xù)往下執(zhí)行，否則Flag數(shù)值不變，CPU每次都執(zhí)行這段通信故障程序，導(dǎo)致整個數(shù)據(jù)交換中斷，如圖7所示(圖中：X為1，2，3)。

圖7 數(shù)據(jù)交換循環(huán)控制邏輯Fig.7 Data exchange loop control logic

140CPU67160通過以上的程序組態(tài)讀取到了2臺稱重顯示控制儀的數(shù)據(jù)并傳送至上位機，省去了人工抄表的麻煩，避免了人工抄表的錯誤。上位機數(shù)據(jù)通過廠級監(jiān)控信息系統(tǒng)(SIS)讀取，直接傳送至數(shù)據(jù)分析部門及管理部門，為管理者及時決策提供了可靠的數(shù)據(jù)支撐。

4 結(jié)束語

通過上述分析和實施，實現(xiàn)了入爐煤皮帶秤數(shù)據(jù)準確可靠地遠傳至Quantum PLC，減少干擾造成的誤差，為煤耗計算提供了翔實的數(shù)據(jù)，降低了人工工作負荷；同時，也為拉姆齊Micro-TechTM2000系列稱重顯示控制儀與RockWell或Siemens PLC組成的輸煤控制系統(tǒng)采用相應(yīng)協(xié)議(AB DF1或3964R)通信提供了范例。