tft每日頭條

 > 生活

 > 西門子s7300輸入擴展模塊紅燈亮

西門子s7300輸入擴展模塊紅燈亮

生活 更新时间:2024-12-04 22:41:24

一 問題提出

淮安同方水務有限公司下屬淮安市第二污水處理廠處理能力10萬噸/日,采用BAF工藝。該廠自控系統采用西門子S7300系列PLC,全廠共有兩個S7300系列PLC站,分别稱為PLC1及PLC2,每個S7300PLC站主機架都有數個通過PROFIBUS-DP總線網絡(RS-485電平)連接的遠程I/O分站。這兩個PLC站都配有以太網模塊及以太網交換機。PLC1、PLC2、兩台監控上位機以環形光釺以太網形式連成網絡,見圖一所示(圖一中隻畫出了PLC1、PLC2站的主機架,PLC1及PLC2的遠程I/O站通過PROFIBUS-DP電纜與各自的主站以菊花鍊形式相連接):

西門子s7300輸入擴展模塊紅燈亮(西門子S7300遠程IO站所控制設備運行異常原因分析及解決方法)1

圖一中1、2、3為帶有光口及電口的工業以太網交換機,4、5為PLC1及PLC2站,6、7為監控上位機。交換機的光口分别插入多模光釺構成10/100Mps環形以太網,PLC1、PLC2站中的以太網模塊用普通網線插入交換機中的電口。PC1、PC2分别為工程師站及操作員站,這兩台監控PC都配有普通網卡,通過網線插入以太網交換機,所配組态軟件為杭州和利時自動化有限公司的FACVIEW 6.0。

該污水處理廠2006年6月通過環保驗收正式投入運行。全廠自控系統由杭州和利時自動化有限公司集成制作。

自2014年7月起,PLC1站及PLC2站所控制的設備都不同程度出現了異常現象,有些設備在遠程手動及遠程自動運行時出現不明原因停機現象,并且這些異常停機的設備都由PLC、PLC2的遠程I/O站所控制。有時一個班能停好幾次,有時好幾天又正常。我們還進一步觀察到,不明原因停機分兩種情況:一種停機現象發生後,必須中控室操作人員從上位機上手動重新啟動,才能正常運行;另外一種停機現象不需要中控室操作人員重新在上位機上啟動,設備在經過短暫非正常停止運行後,自己又恢複正常運行了。在設備現場印象非常深的是:PLC2站所控制的多台曝氣羅茨鼓風機,正常運行時聲音很大也很穩,突然之間可能某台風機會嘎然停止運行,很短時間後又自動恢複運行。

設備遠程手動或者遠程自動運行時,由PLC程序及中控室操作人員命令來決定設備的運行規律,遠程手動及遠程自動運行出現停機現象我們第一個想到的就是PLC站中控制該設備的梯形圖程序是否有問題。打開西門子STEP7進行程序監控,一切都很正常。又想想PLC1及PLC2中程序已經穩定運行8年多,沒有人修改過程序,PLC程序中不應該有邏輯及其他編程錯誤。

我們又懷疑PLC硬件出了問題,就幾乎把這兩個PLC站所有硬件從主機架CPU模塊、到各個遠程I/O站PROFIBUS-DP通信接口模塊IM153-2 、各個遠程站的I/O模塊、主機架及遠程I/O機架的底闆等用備品換了個遍,每次去現場這麼折騰一次,似乎能正常運行一段時間,但過一段不定的時間後,老問題又出現了,這個問題曾經在一段時間内讓我們很頭疼,百思不得其解,CPU模塊也沒有報硬件故障及與遠程站通信故障,似乎PLC系統硬件也是正常的。

圖二為PLC2站主機架及遠程I/0站。

西門子s7300輸入擴展模塊紅燈亮(西門子S7300遠程IO站所控制設備運行異常原因分析及解決方法)2

圖二

圖二中左上角标有(0)UR為主機架,主機架中有CPU 315-2DP模塊一隻、以太網通信模塊CP 343-1一隻、串行通信模塊CP340-RS422/485一隻。該CPU模塊上有兩個通信口,一個通信口可通過編程軟件選為MPI協議或者DP協議;另外一個通信口隻能為DP通信協議,但可通過STEP7選為DP主站或者從站協議。本例主機架中DP那一行左側拖出一根線連到PROFIBUS(1): DP master system(1)的通信口設置為DP 主站協議,各遠程I/O機架中的PROFIBUS DP通信接口模塊IM153-2隻有從站通信協議。主機架中CPU模塊 DP通信口做主站,與各遠程I/O站中通信模塊IM153-2做從站進行主從通信。

圖二中的各個遠程I/O站中的(6)、(7)、(8)、、、、、(14)為遠程IO/站号,站号旁邊的ET 20、或者ET 2 等全稱應該為ET 200M,不過在編程軟件STEP7中就是這樣顯示的。

每個遠程I/O站中第一槽為通信接口模塊IM153-2,然後是根據需要插入的若幹數字量及模拟量I/O模塊。

主站跟所有從站輪詢通信,主站周期地讀取從站的輸入信息并周期地向從站發送輸出信息,通信由主站發起,從站不主動跟主站通信,從站之間不通信。

二 設備異常停機原因分析

經過多次現場檢查、更換備件仍然無法解決問題後,我們用電腦連接PLC,用STEP7在線,打開PLC故障診斷緩沖區,查看故障診斷緩沖信息,這一看就發現了問題。該型CPU故障診斷緩沖區中最多可以保留120條信息,根據故障信息中的日期時間及值班人員記錄我們發現,每出現一次CPU跟某個遠程I/O站通信失敗,就有一些設備異常停機,并且從通信失敗到通信恢複之間時間一般就幾秒鐘,每一次通信失敗後都能自動恢複。

利用PLC故障診斷緩沖區信息結合相應設備梯形圖程序邏輯分析,我們發現正是CPU跟遠程I/O站通信失敗導緻了設備異常停機。

以下以2014年9月26日PLC2站的9号遠程I/O站所控制的一号二級提升泵異常停機為例,分析第一種停機即停止後需要中控室操作人員重新啟動才能運行情況:

值班記錄顯示當日晚上9點55分左右該泵出現了異常停機,并且中控室操作人員在上位機上重新手動啟動後才運行起來。

下圖三為導出的該時段PLC緩沖區部分信息:

從圖三中可以看出,2014年9月26日晚上9點55分48秒25毫秒時(event 2 of 10)CPU與9号遠程I/O通信失敗,2014年9月26日晚上9點55分50秒509毫秒(event 1 of 10)通信恢複,通信中斷時間2秒多一點。注意西門子PLC CPU故障診斷緩沖區最早的信息排列在後面。

西門子s7300輸入擴展模塊紅燈亮(西門子S7300遠程IO站所控制設備運行異常原因分析及解決方法)3

圖三

下圖四為該台水泵部分梯形圖程序。

西門子s7300輸入擴展模塊紅燈亮(西門子S7300遠程IO站所控制設備運行異常原因分析及解決方法)4

圖四中I0.0為該台提升泵控制櫃上的現場/遠程轉換開關,當該開關為遠程位置時I0.0為1,I0.1為故障信号,當水泵有故障存在時I0.1為1。M100.0及M100.1與上位機通信軟件相連,M100.0為上位機設定的提升泵工作模式,當在上位機選定為遠程自動模式運行時,M100.0為1,選定為遠程手動模式時為0;M100.1為上位機啟/停命令,當在上位機點動啟動水泵時M100.1為1,再次點動時M100.1為0,再次點動又為1,,,。

M200.0為遠程自動工作模式時啟/停命令,還有一段梯形圖邏輯程序專門用來根據工藝要求确定在自動模式時的M200.0,但該段程序與本論點關系不大,故未列出。Q0.0為輸出繼電器,控制提升泵啟/停。

從NETWORK 1 中可以看出,在現場/遠程開關轉換選定在遠程位置(I0.0為1),無故障(I0.1為0),上位機将該設備選定在遠程手動模式時(M100.0為0),在上位機上點動開/停機按鈕,則M100.1為1,Q0.0就為1,水泵就運行了,如果要停機,則需要再次點動開/停機按鈕,M100.1就為0 . Q0.0就為0,水泵就停止運行了。

本段梯形圖程序的輸入點現場/遠程I0.0、故障I0.1正好來自該9号遠程I/O站,輸出Q0.0來自另外一個遠程I/O站。從圖三PLC故障診斷緩沖區信息中我們看到,在2014年9月26日晚上9點55分48秒25毫秒時CPU與9号遠程I/O站瞬間通信失敗,9點55分50秒509毫秒通信又恢複了,通信中斷時間2秒多一點。如果從NETWORK 1 中看,CPU跟9号遠程I/O通信中斷2秒多一點時間,隻是在這2秒多一點時間内Q0.0輸出為0,水泵短時停機後就又自動恢複運行了。當從NETWORK 2看,短時間通信中斷,CPU讀不到該遠程站輸入模塊的信息,會自動将對應輸入映像區的值設定為0,從圖中可以看出I0.0一為0, 就将上位機開/停機指令M100.1清0,M100.1為0後,Q0.0就為0了,設備就停止運行了。要想設備重新運行,隻有在上位機上人為重新點動水泵啟/停按鈕将M100.1置位為1。我們将PLC故障診斷緩沖區中的通信中斷信息、相應異常停機設備的梯形圖程序、以及中控室值班記錄一起對照一一進行了檢查,每一台設備異常停機然後重新遠程人為啟動後又正常運行都是這個原因造成的。

經過分析後發現,第二類異常停機即設備短時停止很快又自動恢複運行也是由于CPU跟相應遠程I/O站通信中斷引起的。在此由于篇幅的原因沒有列出PLC故障診斷緩沖區信息及設備梯形圖程序,隻用語言描述一下。假如以某台曝氣鼓風機為例,風機梯形圖程序與圖四水泵程序相似。

由于鼓風機梯形圖程序中現場/遠程輸入點、故障點沒有處在中斷通信的這個遠程I/O站上,隻有控制設備運行命令的輸出點處在了通信中斷的這個遠程I/O站上了,從圖四梯形圖程序中可以看出,秒級時間的通信中斷會使命令輸出Q0.0秒級斷開,一旦通信恢複,設備又自動運行起來了,這跟我們在現場突然聽到某台鼓風機嘎然一聲停機又很快自動恢複運行這一現象是一緻的。我們也對PLC故障診斷緩沖區的信息及中控室設備運行記錄一一對照檢查,也印證了這一點。

短時間内通信中斷後又恢複,由于沒有任何規律,也許幾天一次也不出現,也許一天出現幾次。一旦出現CPU上的通信故障指示LED 燈也是一閃而過又恢複正常,維護人員在現場也無法用常規的萬用表等工具檢測捕捉這一過程。

三 CPU跟遠程I/O站通信中斷原因及解決方法

在确立了由于CPU與遠程I/0站通信中斷而引起設備異常停機這一因果關系後,我們就聯系西門子技術支持,詢問為什麼CPU與遠程I/O會出現無規律短時通信中斷,他們答複是電磁幹擾,因為電磁幹擾進入PROFIBUS-DP總線中而引起CPU與遠程I/O站瞬間或者短時間通信中斷,并且告訴我們減小電磁幹擾的途徑。我們按西門子技術支持的指導意見于2014年10月份從如下幾點進行了整改。經過整改後,從那時到現在,再也沒有出現設備異常停機現象。

具體進行了如下整改:

1、PLC CPU所在控制櫃及遠程I/O站所在控制櫃良好接地,等電位聯結CPU所在的控制櫃與所有遠程I/O站所在控制櫃接地

本廠PLC2号站CPU所在主機架在一個控制櫃中,其它6、7、8、9、10、11、12、13、14遠程I/0站分布在三個控制櫃中,四個控制櫃緊靠在一起,我們對每個櫃接地進行了檢查,發現個别接地不牢靠,重新進行了緊固;PLC1号站主機架跟遠程I/O機架在同一個控制櫃中,我們對其接地進行了檢查緊固。如果這些控制櫃距離較遠的話,在每一個櫃接地良好前提下,還應該把所有控制櫃接地做等電位連結起來。

2、 PLC主機架、遠程I/O機架接地

PLC上安裝模塊的機架有接地點,必須确保模塊機架跟本櫃體接地良好。

3、選用合格的PROFIBUS-DP電纜及接頭,PROFIBUS-DP電纜應盡可能遠離動力電纜

為了保證通信質量,應優先選用西門子生産的PROFIBUS-DP通信電纜及PROFIBUS-DP接頭。在制作PROFIBUS-DP接頭時,應輕輕剝開電纜外皮,不要損壞外包繞的電纜屏蔽層,按要求将電纜屏蔽層牢固地壓接在PROFIBUS-DP接頭外殼上。PROFIBUS-DP電纜應該盡可能遠離動力電纜,特别要遠離變頻設備的動力電纜。本廠PLC1、PLC2這兩個站都存在個别PROFIBUS-DP接頭處電纜屏蔽層斷裂、與接頭外殼接觸不好現象。

4、網絡兩端屏蔽接地

将網絡的起始兩頭站點PROFIBUS-DP接頭外殼接地。

5、采取杜絕電源幹擾措施

由于電網中變頻設備的應用、大功率動力設備的開關等形成的諧波、浪湧等沖擊會通過電源對通信造成幹擾,建議用UPS 給PLC供電,一般UPS都有減少電源諧波及浪湧、淨化電源的作用。

,

更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!

查看全部

相关生活资讯推荐

热门生活资讯推荐

网友关注

Copyright 2023-2024 - www.tftnews.com All Rights Reserved