馮建玉 韓 靜 劉 雄 姚 海 寧彥初
(中國船舶重工集團公司第七一一研究所,上海 201108)
無焰熱氧化(FTO)技術作為一種新興的有機廢氣無害化處理技術,得到了越來越廣泛的應用,其控制方式采用PLC-DCS協同控制,PLC與DCS之間通過RS485通信方式交換數據。但PLC采用循環掃描的方式進行數據處理的特點決定了其偏重于邏輯運算和簡單的模擬量處理,對于大量的通信數據處理會占用CPU的有限資源,使PLC循環掃描時間變長,影響其正常的邏輯運算實時性,并且其通信模塊價格不菲,無法跨廠家使用。因此利用PLC的工作特點開發一種新的通信數據處理方法顯得尤為重要。筆者利用工業領域使用較多的S7-300PLC,提出一種數據通信處理方法,避開PLC配套使用的通信模塊CP341中內置的硬件算法,而利用PLC循環掃描頻率高但單次掃描時間短、處理數據量有限的特點,使通信數據計算量巨大的CRC16校驗部分分散到各掃描周期中去。
FTO技術采用催化劑使有機廢氣在高溫下裂解。與傳統的熱力氧化焚燒技術相比,FTO技術具有一系列優點,尤其是在處理低熱值有機廢氣時,其優勢更加明顯:FTO能夠降低有機物氧化反應溫度,使低熱值的有機廢氣在不需要補充燃料的情況下即可發生氧化反應,在達到同樣有機物破除效果的同時與熱力焚燒工藝相比,節約了大量的能源;FTO省去了熱力焚燒工藝中操作復雜且危險的燃燒系統,具有操作簡單、安全性高的特點;FTO不需要熱力焚燒工藝中為保證有機物破除率而設置的大容量絕熱爐膛,從而節省了占地空間。
FTO工藝對催化劑的反應溫度控制和外圍輔助的工藝回路控制的一致性要求很高,否則不僅會造成因反應過程不徹底而無法達到環保要求,而且會縮短催化劑的使用壽命乃至于很快報廢。
FTO系統對催化裂解過程的控制一般采用現場控制盤和DCS分布控制。現場控制盤采用PLC作為控制核心器件,提供數據的采集、歸一化處理、通信和動作指令的執行。DCS系統負責工藝流程控制算法的執行和參數的計算。PLC系統和DCS系統之間的數據傳輸采用主從站通信方式,以節省電纜和電纜敷設的工程成本。PLC需要經常性地處理大量通信數據。目前一般系統都是直接采用PLC配套的硬件通信模塊處理通信數據,但是這種方式在通信方面存在缺陷,比如,硬件通信模塊對數據報文的處理必須在一個完整的掃描周期內完成,但PLC的CPU最大循環掃描時間有限(一般在100~200ms),若處理的報文數據量太大則容易造成報文數據出錯甚至CPU停機,而且硬件內置的通信處理過程不透明,增加了調試的難度。
S7-300PLC采用CP341進行數據通信,CP341應用最多的是Modbus RTU通信方式。Modbus RTU通信協議采取主從模式:由主站發出數據操作請求,從站進行響應。整個網絡可以有多個從站,但是必須有且只有一個主站。若主站不發出數據操作請求,則所有從站保持靜默狀態。PLC在Modbus RTU模式中一般作為從站響應上游的DCS主站請求。經分析,PLC從站的硬件通信模塊對總線數據的響應流程如圖1所示,此流程通過邏輯電路和通信處理器固化在通信模塊中。

圖1 PLC從站的硬件通信模塊響應流程
PLC從站對主站響應的報文格式見表1。

表1 從站響應報文格式 Byte
為保證FTO系統現場控制盤內的PLC與DCS主站通信成功,首先要確定從站能辨識主站的查詢請求,即滿足圖1所示的解析過程;其次要保證從站響應主站的報文格式正確,應符合Modbus RTU標準格式(表1)。
在FTO系統的就地PLC與DCS主站通信中,采用軟件結構化編程模擬傳統的硬件通信模塊固化的程序流程,主要的程序模塊有:OB1——主程序,程序組織塊,用于啟用主程序;OB80——程序組織塊,用于報告系統運行錯誤號;OB121、OB122——程序組織塊,用于程序容錯處理,防止PLC死機;FB7——子程序,程序功能塊,用于從總線上接收主機的請求數據;FB8——子程序,程序功能塊,用于把從站數據發送到總線上,以響應主機的請求;FB9——子程序,RTU SLAVE通信主程序,用于運行圖1所示的程序流程;FC10——子程序,程序功能函數,用于數據在不同數據塊間的移動;FC12——子程序,程序功能函數,用于CRC16的數據校驗;DB10、DB11、DB12、DB13——數據塊,分別用于存儲DI、DO、AI、AO類型的數據。
主程序和子程序之間的調用層次關系如圖2所示。

圖2 主程序和子程序之間的調用層次關系
程序組織塊OB80、OB121、OB122可直接從Step7中調用。CP341用功能塊FB7“P_RCV_RK”和FB8“P_SND_RK”分別從通信總線上接收和發送通信數據[1]。在本通信程序中被主程序FB9調用。
FB9是RTU SLAVE通信主程序,用于運行圖1中的程序流程,由其調用FB7、FB8、FC10和FC12。起始時,FB9調用FB7從總線上接收主站請求的報文,通過解析報文的第一字節內容(從站地址),判斷地址是否與本從站一致,若不一致則直接丟棄此報文,繼續監測總線數據;若報文請求地址與本從站地址一致,則調用FC12子程序對報文進行CRC16校驗,若校驗失敗則說明報文有誤,直接丟棄報文;若校驗通過,則繼續解析此報文請求的第二字節(功能碼),按功能碼的請求分別轉到對應的程序段執行;執行相應的請求功能后,調用FC10進行數據移動整理,并再次調用FC12對響應后的數據進行校驗,并將校驗碼附加到響應數據的最后兩個字節作為響應報文,調用FB8發送到總線供主機接收。
通信程序的容錯機制采用CRC16校驗。CRC16校驗程序由于要對通信的所有數據進行逐一字節的運算,因此極其耗費CPU運算資源,經實驗,采用PLC內置硬件模塊處理的通信數據量達到256Byte后CPU運算時間大于掃描周期時間的概率大為增加,容易導致通信錯誤和CPU死機。為了不使計算時間超出PLC的最大允許掃描時間,筆者設計將計算一串數據的CRC16校驗碼任務分散到各PLC周期中去。具體做法是:每個掃描周期只進行一個字節的通信數據CRC16校驗計算,一串通信數據則依字節數分散到多個周期去做,設置一個全局變量存儲當前的CRC16檢驗碼值,每個周期在當前CRC16校驗碼值的基礎上繼續下一個字節的計算,得到新的CRC16校驗碼值,當一串數據全部計算完畢后,當前CRC16校驗碼值即最終值。CRC16單個字節校驗編程的具體實現步驟如下[2]:
a. 設置CRC寄存器,并給其賦值FFFF(hex);
b. 將待校驗數據(起始位、停止位不參加計算)的第一個字節與16位CRC寄存器的低8位進行異或,并把結果存入CRC寄存器;
c. CRC寄存器向右移一位,MSB補零,移出并檢查LSB;
d. 如果LSB為0則重復c,若LSB為1就把CRC寄存器與A001H相異或;
e. 重復c與d直到8次移位全部完成,此時該字節數據處理完畢;
f. 重復b~e直到所有數據全部處理完成;
g. 最終CRC寄存器的內容即為CRC值。
FB9、FC10和FC12是通信程序核心,也是此方法的主要源代碼內容。此程序代碼實現的Modbus RTU支持的功能碼為01、02、03、04、05、06、15和16。
FTO系統中數字量為298點,模擬量為163點,單回路8個,復雜控制回路4個。為保證PLC的運行實時性,設置其極限循環掃描時間為150ms。對3種通信方式進行對比(測試結果見表2),軟件單次掃描循環方式是將通信過程中計算量最大的CRC校驗計算在一個掃描周期內運行,運行時間為198ms,遠超出了PLC極限循環掃描時間,引起CPU停機;采用傳統的硬件通信模塊時,掃描時間為142ms,比較接近150ms的極限,若考慮到模擬量控制回路運行時間的不確定性,則復雜工況下,也存在導致CPU停機的風險;利用多個掃描周期來計算CRC校驗碼值的方式,每次循環只要89ms,保證了CPU循環掃描時間的足夠裕量,有利于系統穩定可靠運行。
從通信成本投入看,尤其是對中小型PLC系統,軟件多次掃描循環方法是經濟的。

表2 3種通信方式測試結果對比
FTO系統運行至今,回路顯示、控制和通信數據的交換一直穩定、可靠,達到了預期目的。應用結果表明,該方法提高了PLC處理大量通信數據時的運行可靠性,保證了FTO系統的可靠運行,同時節省了購置PLC通信硬件的高額成本,應用前景廣闊。
[1] 王延年,陳紅,高霞.基于CP341模塊的Modbus RTU從站協議免驅動通信[J].西安工程大學學報,2010,24(6):786~790.
[2] 王華強,龍灝.基于Modbus與WinCC 的釜液位監控系統[J].儀表技術與傳感器,2014,(2):73~75.