拉邊機控制系統的兩種通訊方式比較

許新林,楊華龍

(蚌埠凱盛工程技術有限公司,蚌埠233010)

浮法玻璃的錫槽工藝為玻璃液浮動在錫液上面成型,在表面張力和重力的作用達到平衡時,玻璃液在錫液面上形成自然厚度約7 mm 的玻璃帶。適當增加拉引力(即退火窯拉引速度),可使玻璃帶沿縱向被拉伸,厚度逐漸減薄,寬度也相應收縮,在不增加其它措施的情況下,可以比較容易生產出厚度5～6 mm 的玻璃。但拉引更薄或者更厚的玻璃就存在一定困難,在拉薄和堆積的過程中,拉力使玻璃厚度減薄或者增加,而表面張力有使玻璃增厚、帶寬收縮的趨勢。所以,要使拉薄或者堆積過程有效、順利地進行,必須選擇拉薄的適宜粘度和采取合理的工藝參數。

拉薄采用的溫度制度有重新加熱法和徐冷法兩種。目前普遍采用徐冷法,玻璃冷卻到一定溫度后,進入拉薄區拉薄。在拉薄區設置拉邊機并控制其速度,利用拉邊機的節流作用,阻止向拋光區傳遞。浮法玻璃拉邊機控制系統是通過拉邊輪牽引在錫液上面的玻璃帶前進,通過調整拉邊輪的線速度及水平擺角、平面傾角,用來達到控制玻璃帶前進以達到需要的厚度同時使玻璃帶穩定的目的。

拉邊機操作的數值監控實時性和操作的快速性在生產中尤為重要,特別是在多對拉邊機使用的情況下,如果無法將下位數據及時上傳給上位控制系統,就會出現數值上傳緩慢而導致所調節對應的拉邊機滯后于自己實際所需要達到的效果,就可能會引起拉邊機輪脫邊,那么就需要新的一輪調節。

該文對拉邊機控制系統兩種常用通訊方式的組態方式、編程方式、通訊模式進行對比,對兩種通訊方式做一個闡述。

1 組態方式

基于西門子300PLC所選用的常用315-2DP型CPU,組態分為兩個部分,一是主CPU 中進行組態,二是對應主CPU 還需要對分CPU 進行組態。在主從CPU 間進行通訊方式中選擇Profibus-DP和MPI兩種方式來進行說明和闡述。

1.1 Profibus-DP通訊方式的組態

采用Profibus-DP 進行通訊,所需要的配置:帶有Profibus-DP 通訊口的315-2DP 型CPU 作為主站CPU；313-2C型CPU 同時添加擴展卡CP342-5擴展模塊作為通訊從站；Profibus總線連接器以及電纜。

在主站CPU 中將從站的CPU 生成為一個西門子本身的GSD 文件,然后將從站組態到Profibus-Dp通訊網絡下面,如圖1所示共組態了16個從站,每一個從站和主站之間都有自己的通訊地址,將主站所需發送給從站的命令和從站反饋給主站的通訊信息,通過組態通訊地址對應的字節傳輸給對方。這樣就能夠實時的進行信息傳輸,然后在程序中對相互傳輸的信息進行處理,對不同的內容進行不同的處理,將所傳輸的問題解決,采用這樣的傳輸,傳輸的速率最快能夠達到12 Mb/s?？紤]到通訊的距離以及通信的數據量,在通常情況下采用1.5 Mb/s就足夠實現網絡信息的實時性傳輸了。

采用Profibus-DP通訊方式的從站,只要將所需的擴展連接卡CP342-5模塊連接上即可,自身生成的GSD 文件只要安裝在主PLC中,在主PLC的DP通訊網絡下面將從站組態安裝上,再將從站里面所組態的擴展模塊設置與主站對應長度的通訊字節數,即可實現數據的通訊交互,在組態地址列表中能夠看到CP342-5模塊組態的字節為288～303,那么對應的主站PLC中需要組態對應的長度為6個字節,設置一個可用的地址用來與從站進行通訊。從站同時還具有一個很重要的任務,將現場的所有驅動裝置的實時位置、運行狀態、以及現場類似于水溫水壓等所有信息采集進入從CPU,同時將這些信息傳輸給上位系統,讓上位系統操作人員通過這些信息來判斷當前所需做出的處理和應對方式。

1.2 MPI通訊方式的組態

采用MPI進行通訊,所需要的配置:帶有MPI通訊口的315-2DP型CPU 作為主站CPU；帶有MPI通訊口的315-2DP型CPU 作為通訊從站；Profibus總線連接器以及電纜。

采用MPI通訊方式的主站CPU 組態比較方便,無需在硬件回路上對從站CPU 進行什么組態,所有信息的傳輸都是在主PLC中通過“SFC68的X_PUT”系統功能塊來虛擬調用實現主PLC和從PLC之間的數據傳輸。這種沒有硬件通訊模塊的通訊方式通常速度比較慢,采用這種虛擬調用的通訊方式最高的通訊速度只能夠到達187.5 kb/s,而且傳輸的數據量相對于Profibus-DP通訊數據量要少很多。采用這種方式進行主從CPU 通訊時,主CPU 中通過虛擬調用組態的從CPU 數量比較少,如果組態的從站超過MPI通訊網絡所能處理的數量后,會引起網絡延遲滯后。也就是當你在主CPU 中發出一個指令后,從站CPU 不能夠實時收到主站CPU 傳輸過來的信息,執行主CPU 的指令延遲比較嚴重,同時反饋給主CPU 的信息也會出現滯后,經過驗證,當所組對數大于10個從站時,就比較容易產生通訊滯后的情況。

通過MPI方式通訊時,從站同樣所做的處理比較簡單,沒有擴展模塊的使用,那么在組態的情況本身不需要考慮對應的通訊字節,也不用對其進行組態。只是在使用主CPU 發過來的信息時,所需使用的地址是在主PLC已經定義好了,只需要按照主CPU 中定義的地址進行使用即可。同時當有需要傳輸給主CPU 信息時,也是通過虛擬調用的方式,將自身的信息、現場采集的信息傳輸給主CPU。在這種通訊方式下從站也是通過Profibus-DP的方式與下位驅動裝置、以及現場傳感器進行通訊,將現場的數據采集進入從站CPU然后傳輸給主CPU。

2 通訊對應程序的說明

程序處理通常分為兩個部分,一個是在主PLC 中做出對從PLC 發出指令的處理,另外一種就是在從PLC中做出對主PLC信息接收的處理。當采用的通訊方式不一樣時,所需采用的程序也不一樣。

2.1 Profibus-DP通訊方式程序說明

在采用Profibus-DP通訊方式時,在主CPU 中對從站進行了硬件模塊組態,并填寫了映射的地址,那么在主CPU 中只要將所需發出的指令程序編寫完成即可,無需做其他程序處理。在從CPU 中需要添加對應的“DP_Receive”系統功能塊來接收主程序傳輸過來的信息。圖2為從站CPU 所調用的系統功能塊,其中CPLADDR 代表的是本身從站模塊與主站CPU 通訊的地址；RECV 代表的是從站接收主站的數據輸入區,圖2中顯示與主站通訊字節長度為4,從I10.0為初始位置進行計算；NDR 為接收完成一次產生一個脈沖,可將這個信息回傳給主CPU 告知從站是否在實時接收；ERROR 表示錯誤位,產生錯誤時會產生置1信號,用來告知是否有錯誤信號的產生；STATUS是指示在使用這個通訊塊時,所處的狀態提示的狀態字,DPSTATUS是用來反饋與主CPU 進行通訊所出現的狀態字,通過這個狀態字的反饋可以查狀態代碼得知通訊是處于正常傳輸狀態還是處于故障狀態,如果處于故障狀態通過代碼來得知解決的方法。

2.2 MPI通訊方式程序說明

通過MPI方式進行通訊數據傳輸時,主CPU 以及從CPU 都沒有相應的硬件模塊需要組態,所采取的數據傳輸方式都是使用虛擬調用的方式。所調用的系統功能塊主要是在主CPU 的程序塊中完成,在主CPU 程序中關于每一個從CPU 都需要進行一次系統功能塊的調用,每一個系統功能塊的調用對應一個分CPU,并與對應的分CPU 進行數據的交互。那么在主程序中需要完成指令程序的編寫,也需要完成調用程序的編寫。調用的“X_PUT”系統功能塊如圖3所示,圖3截取的是與其中兩個分CPU 進行通訊的程序塊。在圖3所示的程序中,REQ 為數據發送請求位,只有在該變量為1時數據才能夠正常的傳輸；CONT 表達發送的數據是否為一個整體,正常情況下將其置1,作為連續整體傳輸即可；DEST_ID 為從站CPU 在本身組態時對應的MPI地址,在從站組態時設置的MPI地址一定要與這里所寫的地址一致,否則無法連接；VAR_ADDR 為從站CPU 接收的起始地址和接收的字節長度；在從站中需要讀取主站的指令內容就在這個地址范圍內查找；SD 表述的是主站發給對應從站CPU 內容的起始地址以及通訊字節長度,發送的長度要與接收的長度一致,發送的內容才能夠準確的在對應的從站地址中顯示；RET_VAL 顯示的是發送的狀態字,是提示當前發送處于何種狀態,如果發送失敗的話,也會將發送失敗的代碼顯示在這個內容中,通過查詢代碼來解決相應的問題；BUSY 表示發送的進程,當為1時表達正在發送內容,為0時是空閑狀態。在程序運行狀態下,監控程序,當有數據傳輸時能夠觀察到這個數據位在1和0中間不停的切換。

3 兩種通訊方式的比較

3.1 Profibus-DP通訊方式

通過Profibus-DP的通訊,傳輸的速度快,實時響應性好,能夠組態的從站數量多,并且組態較多的從站時,不會出現通訊中斷滯后的現象。因為通過實際的硬件模塊進行通訊,通訊狀態較為穩定,只要不是硬件模塊出現問題,或者是指令程序編寫錯誤,主站CPU 所有的信息內容都能夠準確的到達從站CPU,不存在延遲滯后或者丟失通訊數據包的事件。所存在的難點是在通訊中組態硬件模塊較為麻煩,要將從站CPU正確的生成GSD 文件才能夠將其組態進入主站CPU 的DP通訊網絡上面,然后才能實現與從站CPU 進行通訊。在程序處理這一塊相對于MPI較為簡單,只要在從站CPU 中按照硬件組態的地址填寫就可以讀取到主站傳輸過來的信息。同時采用這種通信方式需要額外的增加CP342-5通訊擴展卡件,這樣也增加項目執行的成本,增加通訊組態難度,增加工作的內容,不過能夠很穩定的進行數據傳輸,保證傳輸內容的實時、準確、快速。

3.2 MPI通訊方式簡述

MPI通訊方式,在主站CPU 連接數量較少的從站CPU 時也能夠實現數據傳輸的實時性,但當通訊的從站CPU 數量過多時就會出現傳輸延時滯后的現象,嚴重時甚至出現通訊中斷的情況,這樣勢必會影響正常的生產,給生產帶來巨大的隱患。這種通訊方式相對于編程者來說操作簡單,不需要進行什么額外的通訊模塊組態,只需要調用對應系統功能塊來進行數據的傳輸即可。使用MPI這種通訊方式進行通訊時,程序的編輯會稍難于DP的通訊方式。在生產中對于從站CPU 數量沒有那么多的時候,可以采用這種通訊方式,這樣可以減少通訊組態的麻煩,也能夠節約一定量的成本,同時也不影響數據傳輸的實時性。

4 結 語

在實際使用中,當所需要的拉邊機對數較少時,那么所需通訊從站數量也相對較少,這時可以使用MPI通訊方式,在通訊從站數量少的情況下,MPI通訊方式能夠滿足數據傳輸的實時性的需求。通訊的從站數量不多,不會存在數據丟包現象,也能夠減少編程者的工作內容,減少項目成本,減少通訊的硬件故障節點。如果在實際生產中所需要生產超薄或者超厚玻璃時,那么所需要的拉邊機數量較多,所需要通訊的從站數量較多。這時為了生產穩定性考慮,優先選擇Profibus-DP 通訊方式。在通訊數量較多的情況下,通過這種DP的通訊方式能夠實現數據傳輸的實時性、準確性和快速性,也能夠保證通訊數據不丟包。使用這種通訊方式雖然給編程者增加一定的難度,但是能夠保證生產的穩定。

通過對兩種通訊方式的比較,可以得出在通訊從站數量少,傳輸內容少的時候選擇MPI通訊；當通訊數量多,傳輸數據內容多時選擇Profibus-DP通訊方式。