6ES7313-6CG04-0AB0庫存充足
6ES7313-6CG04-0AB0
PLC現(xiàn)場硬件模塊的組態(tài)和軟件調(diào)試
對于各種PLC的現(xiàn)場硬件組態(tài)和軟件調(diào)試,通常有經(jīng)驗的工程師應該先花一些時間對自己的現(xiàn)場工作進行一個簡單的規(guī)劃,通常應當采取如下的步驟:
(1) 系統(tǒng)的規(guī)劃
首先,必須深入了解系統(tǒng)所需求的功能,并調(diào)查可能的控制方法,同時與用戶或設計院共同探I/O模塊型式。
(2) I/O模塊選擇與地址設定
當I/O模塊選妥后,依據(jù)所規(guī)劃之I/O點使用情形,由PLC的CPU系統(tǒng)自動設定I/O地址,或由使用者自定I/O模塊的地址。
(3) 梯形圖程序的編寫與系統(tǒng)配線
在確定好實際的I/O地址之后,依據(jù)系統(tǒng)需求的功能,開始著手梯形圖程序的編寫。同時,I/O之地址已設定妥當,故系統(tǒng)之配線亦可著手進行。
(4) 梯形圖程序的仿真與修改
在梯形圖程序撰寫完成后,將程序?qū)懭隤LC,便可先行在PC與OpenPLC系統(tǒng)做在線連接,以執(zhí)行在線仿真作業(yè)。倘若程序執(zhí)行功能有誤,則必須進行除錯,并修改梯形圖程序。
(5) 系統(tǒng)試車與實際運轉(zhuǎn)
在線上程序仿真作業(yè)下,若梯形圖程序執(zhí)行功能正確無誤,且系統(tǒng)配線亦完成后,便可使系統(tǒng)納入實際運轉(zhuǎn),項目計劃亦告完成。
(6)程序注釋和歸檔
為確保日后維修的便利,要將試車無誤可供實際運轉(zhuǎn)的梯形圖程序做批注,并加以整理歸檔,方能縮短日后維修與查閱程序之時間。這是職業(yè)工程師的良好習慣,無論對今后自己進行維護,或者移交用戶,這都會帶來的便利,而且是你的職業(yè)水準的一個體現(xiàn)。
以上工作中,復雜的系統(tǒng)規(guī)劃可能需要幾天甚至更長的時間,但一個簡單的系統(tǒng)規(guī)劃在一個具有良好的職業(yè)習慣的編程工程師手中,可能只需要幾個小時
然后將所需的值送入初始值和預置值控制寄存器。執(zhí)行HSC指令。使用PTO/PWM發(fā)生器的功能應使用什么類型的CPU。
形成以現(xiàn)場總線網(wǎng)基礎的,以智能I/O模塊構(gòu)成的分布式控制站。也就是說,將過去DCS中集中式的I/O控制站變成分布式的控制站。采用現(xiàn)場總線網(wǎng)技術只有在I/O控制站這一層進一步分散化是明確的在傳統(tǒng)DCS網(wǎng)絡的下一層再引入一層現(xiàn)場網(wǎng)絡,形成設備級網(wǎng)絡,控制級網(wǎng)絡和管理級網(wǎng)絡這樣三層網(wǎng)絡結(jié)構(gòu),以此來滿足不斷提高的應用需求。
輕故障都有哪些?輕故障包括:變壓器超溫報警、柜溫超溫報警、柜門打開、單元旁路,系統(tǒng)對輕故障不作記憶處理,僅有故障指示,故障消失后報警自動。變頻器運行中出現(xiàn)輕故障報警,系統(tǒng)不會停機。停機時出現(xiàn)輕故障報警,變頻器可以繼續(xù)啟動運行。失壓保護與緊急停車措施PLC外部負載的供電線路應具有失壓保護措施,當臨時停電再恢復供電時,不按下“啟動"按鈕PLC的外部負載就不能自行啟動。這種接線方法的另一個作用是,當特殊情況下需要緊急停機時,按下“停止"按鈕就可以切斷負載電源,而與PLC毫無關系。
重故障具體都有哪些?
系統(tǒng)發(fā)生下列故障時,按照重故障處理,并在監(jiān)視器左上角顯示重故障類型:外部故障、變壓器過熱、柜溫過熱、單元故障、變頻器過流、高壓失電、接口板故障、控制器不通訊、接口板不通訊、電機過載、參數(shù)錯誤、主控板故障。單元故障包括:熔斷器故障、單元過熱、驅(qū)動故障、光纖故障、單元過壓。新動向:西門子模塊6ES7 417-4HT14-0AB0外部故障必須先解除高壓分斷(柜門按鈕或外部接點)狀態(tài)再系統(tǒng)復位,才能使系統(tǒng)恢復到正常狀態(tài);除外部故障以外的重故障發(fā)生后,直接系統(tǒng)復位即可使系統(tǒng)恢復到正常狀態(tài),但在再次上電前一定要找出故障原因。單元故障發(fā)生后,只有再次上高壓電源方能檢測到單元狀態(tài)。若故障較難分析且無法確定能否二次上高壓時,請向廠商咨詢。注意:切忌在未查明故障原因前貿(mào)然二次上電,否則可能嚴重損壞變頻器!有些PLC通過里邊的電池保持數(shù)據(jù),電池電壓低于某個閥值的時候,會有電池報警提示燈亮,這時候需要更換電池,而且需要帶電來更換,如果電池*沒有電了,或者更換電池的時候沒有帶電操作,往往會造成RAM的數(shù)據(jù)丟失,這時候需要重新刷新程序和數(shù)據(jù),所以PLC平時維護保養(yǎng)時候,要有程序和數(shù)據(jù)備份的慣,否則到了關鍵時候沒有了,只有重新編程和調(diào)試了。
SIMATIC S7-300,CPU 313C-2 DP帶MPI的緊湊型CPU,16DE/16DA,3個快速計數(shù)器(30 kHz),集成DP接口,集成電源24VDC,工作存儲器128KB,前連接器(1x40極)和需要微型存儲卡。
西門子CPU6ES7313-6CG04-0AB0是緊湊型 CPU,可用于具有分布式結(jié)構(gòu)的系統(tǒng)。集成數(shù)字量 I/O,支持與過程的直接連接;PROFIBUS DP主站/從站接口支持與分布式 I/O 的連接。因此,CPU 313C-2 DP 既可以用作分布式單元進行快速預處理,也可以用作帶下位現(xiàn)場總線系統(tǒng)的上位控制器。
問:兩臺314-2DP,怎么把主站的REAL數(shù)據(jù)傳到從站去?例如,主站MD100里數(shù)據(jù)我通過觸摸屏輸入是1.5,把MD100通過MOVE傳送到QD50,主站QD50對應從站ID50,怎么在從站里完整的讀到1.5,放到從站MD80里面?
問題補充:還有一問題,我主站上帶觸摸屏,從站也帶觸摸屏,主站與從站配置都*一樣,包括觸摸屏,目的就是控制一臺電機正反轉(zhuǎn),來控制閘門上升下降,那我在從站那里可以輸入預置高度1.5米,動了以后再在主站里預置1.9米,也動。當我再在從站輸入預置高度時一直是主站給的數(shù)據(jù)了,請問,怎么來規(guī)避這個問題呢?就是對同一個MD120通過兩個觸摸屏都能設置,而又不相互影響,再怎么輸入都是后一次在觸摸屏上輸入有效,不管哪個觸摸屏。
答:實現(xiàn)Profibus主從站之間的MS通訊
通過圖解,說明2個CPU之間通過Profibus實現(xiàn)主從站之間的MS通訊。這個例子是結(jié)合某現(xiàn)場的實際情況來的,實際情況是在2套300系統(tǒng)之間進行數(shù)據(jù)通訊,由于每個CPU300都帶有ET200M從站,所以317的主DP口和315的DP口都只能是主站而不能配置為從站。并且2套系統(tǒng)之間距離較遠,MPI不行,于是就利用了317的MPI/DP口配置成DP口來和315通訊。
1.首先,在STEP7中新建一個Project,分別插入2個S7-300站。
這里我們插入的一個CPU315-2DP,作為主站;一個CUP317-2作為從站,并且使用317-2的個端口MPI/DP端口配置成DP口來實現(xiàn)和315-2DP的通訊。然后分別對每個站進行硬件組態(tài):首先對從站CPU317-2進行組態(tài):將317的個端口MPI/DP端口組態(tài)為PROFIBUS類型,并且創(chuàng)建一個不同于CPU自帶DP口的PROFIBUS網(wǎng)絡,設定地址。在操作模式頁面中,將其設置為DPSLAVE模式,并且選擇“Test,commissioning,routing",是將此端口設置為可以通過PG/PC在這個端口上對CPU進行監(jiān)控,以便于我們在通訊鏈路上進行程序監(jiān)控。下面的地址用默認值即可。
然后選擇Configuration頁面,創(chuàng)建數(shù)據(jù)交換映射區(qū)。這里我們創(chuàng)建了2個映射區(qū),圖中的紅色框選區(qū)域在創(chuàng)建時是灰色的,包括上面的圖中的Partner部分創(chuàng)建時也是空的,在主站組態(tài)完畢并編譯后,才會出現(xiàn)圖中所示的狀態(tài)。由于我們這里只是演示程序,所以創(chuàng)建的交換區(qū)域較小。組態(tài)從站之后,再組態(tài)主站。插入CPU時,不需要創(chuàng)建新的PROFIBUS網(wǎng)絡,選擇從站建立的第二條(也就是準備用來進行通訊的MPI/DP端口創(chuàng)建的那條)PROFIBUS網(wǎng)絡即可。組態(tài)好其它硬件,確認CPU的DP口處于主站模式,從窗口右側(cè)的硬件列表中的已組態(tài)的站點中選擇CPU31X,拖放到主站的PROFIBUS總線上,
這時會彈出鏈接窗口,選擇以組態(tài)的從站,點擊Connect按鈕,然后進入Configuration頁面,可以看到前面在從站中設定的映射區(qū)域,逐條進行編輯(Edit…),確認主從站之間的對應關系。主站的輸入對應從站的輸出,主站的輸出對應從站的輸入。至此,硬件的組態(tài)完成,將各個站的組態(tài)信息下載到各自的CPU中。通過NetPro可以看到整個網(wǎng)絡的結(jié)構(gòu)圖。
2.編寫程序。
硬件組態(tài)完畢,下載,PLC運行之后,數(shù)據(jù)并不會自動交換。需要通過程序來執(zhí)行。在組態(tài)中,input和output區(qū)域,也并不是實際硬件組態(tài)中的硬件地址,也就是說,input和output并不代表I/O模塊的地址和數(shù)據(jù)。但是映射區(qū)域組態(tài)用到的input和output地址,同時也占用了I/O模塊的組態(tài)地址,就是說,映射區(qū)的地址和I/O地址是并行的,不能重復使用。所以在硬件的I/O模塊全部組態(tài)完畢之后再組態(tài)映射區(qū)。
西門子CPU6ES7313-6CG04-0AB0映射區(qū)的數(shù)據(jù)交換是通過系統(tǒng)功能塊SFC14(DPRD_DAT——ReadConsistentDataofaStandardDPSlave)和SFC15(DPWR_DAT——WriteConsistentDatatoaStandardDPSlave)實現(xiàn)的。SFC14和SFC15是成對使用的,一個發(fā)送一個接收,缺一不可。數(shù)據(jù)的通訊也是交互的,可以相互交換數(shù)據(jù)。本例中,我們通過簡單的數(shù)據(jù)來驗證通訊結(jié)果。
首先,我們在程序中插入數(shù)據(jù)區(qū)DB1,前面我們只建立了2個字(2Word)的映射區(qū),于是我們建立如下內(nèi)容的DB1,為了查看的方便,DB1的前半部分作為接收數(shù)據(jù)的存儲區(qū),后半部分用作發(fā)送數(shù)據(jù)的存儲區(qū)。在317和315中我們插入同樣的DB1,然后分別在OB1中編寫通訊程序。其中,程序的LADDR地址,對應的是硬件的映射區(qū)組態(tài)時本站的LocalAddr中的地址,從站的LocalAddr我們組態(tài)的是0,對應的PartnerAddr也就是主站的地址是4。需要注意的是這里的地址是需要用16進制的格式來表示的,我們組態(tài)時是用10進制表示的。
完成之后,我們在各站中插入OB82、OB86、OB122等程序塊,這些是為了保證當通訊的一方掉電時,不會導致另一方的停機。完成之后,將所有的程序分別下載到各自的CPU中,個站切換到運行狀態(tài),通過PLC監(jiān)控功能,設定數(shù)據(jù)之后,我們監(jiān)控的結(jié)果如下:上面的表格內(nèi)容為主站315的數(shù)據(jù),下面的是從站317的數(shù)據(jù)。可以看到,兩個站都分別將各自的DBB4—DBB7數(shù)據(jù)發(fā)送出去并被另一方成功接收后存儲在各自的DBB0—DBB3中。驗證中,我們將一個站的CPU切換到STOP狀態(tài),可以看到,另一個站的CPU硬件SF指示燈報警,但PLC正常運行不停機。待該站恢復之后,報警自動消失。
擴展問題:在一個站的CPU掉站之后,另一個站的接收數(shù)據(jù)區(qū)顯示的仍然是后一次接收到的數(shù)據(jù),并且,即使在這種狀態(tài)下,居然仍然無法修改該數(shù)據(jù)區(qū)內(nèi)容。這樣就存在一個問題,當前站需要知道當前接收數(shù)據(jù)存儲區(qū)的內(nèi)容是否是實時的數(shù)據(jù)。如何判斷。
大概思路:
方法1,用以前的方法,在每個數(shù)據(jù)接收周期開始前,將已接收數(shù)據(jù)清空。這樣當接收周期內(nèi)接收不到新的數(shù)據(jù)時,就可以察覺到。但是問題是,SFC14和SFC15沒有接收是否完成、是否成功等標識位,并且,在接收不到新的數(shù)據(jù)時,原有數(shù)據(jù)不能修改。此方法不通。
方法2,通過別的方式方法檢測兩個站之間的通訊狀態(tài)。在SIEMENS的文檔中,有這樣的描述:主站:主站掌握總線中數(shù)據(jù)流的控制權(quán)。只要它擁有訪問總線權(quán)(令牌),主站就可在沒有外部請求的情況下發(fā)送信息。在PROFIBUS協(xié)議中,主站也被稱作主動節(jié)點。從站:從站是簡單的輸入、輸出設備。典型的從站為傳感器,執(zhí)行器以及變頻器。從站也可為智能從站,入S7-300/400帶集成口的CPU等。從站不會擁有總線的訪問授權(quán)。從站只能確認收到的信息或者在主站的請求下發(fā)送信息。從站也被稱作被動節(jié)點。另外,SIEMENS對SFC14/15的描述也分別是:用于讀取Profibus從站的數(shù)據(jù)/用于將數(shù)據(jù)寫入Profibus從站。
根據(jù)這些描述,通過CPU集成口通訊這種方式下,作為從站的CPU應該屬于“智能從站",但是SIEMENS的描述中,卻沒有說智能從站和普通的從站之間有什么區(qū)別。那么根據(jù)上面的主從站的描述,主站可以主動的獲取到從站的數(shù)據(jù),并可以自主的將數(shù)據(jù)寫入從站;而從站必須在主站的指令下獲取或者發(fā)送數(shù)據(jù)。而在本例中,這些說法似乎無法成立。
本例中,SFC14、SFC15是成對使用的,不論在主站上還是從站上,主從站之間的SFC14和SFC15必然是需要成對出現(xiàn)的。也就是說,任何一方?jīng)]有SFC15運行的的話,另一方的SFC14都讀不到數(shù)據(jù)。而任何一方?jīng)]有SFC14的話,另一方的SFC15發(fā)送出來的數(shù)據(jù)也無人接收。至少從這點看來,看不出主從站有什么區(qū)別。不過,聯(lián)想到以前曾經(jīng)做過S7-300和MM430的Profibus通訊,該通訊方式中,顯然MM440是作為從站出現(xiàn)的,所以在正確組態(tài)之后,只需要在主站(CPU)中寫好SFC14/15即可,當然,MM440中我們也寫不進去程序。那么在這種方式中,可以說是*的遵守了SIEMENS文檔中的說法。同時也說明,在“智能從站"這種方式下,并不遵守SIEMENS文檔中對從站的描述。再次研究SFC14/15的收發(fā)狀態(tài),發(fā)現(xiàn),可能是因為數(shù)據(jù)的存在是過程映像中,所以只要SFC15發(fā)送過一次,數(shù)據(jù)即存在于過程映射中,SFC14隨時都從映像中讀取數(shù)據(jù),所以存在前面說的,SFC14運行過程中,是無法修改接收數(shù)據(jù)存儲區(qū)的數(shù)據(jù)的。脫離SFC14/15,而使用MOVE方法的研究:不使用SFC14/15,而是利用組態(tài)的時候產(chǎn)生的I/O地址來傳數(shù)據(jù)。根據(jù)創(chuàng)建過程映射區(qū)時的組態(tài)信息,我們寫寫出了如下的程序:在主站315-2DP中:在從站317中:其中,M位的使用是測試程序的不同情況下使用的臨時點,和本程序功能無關。由此可見,在這種方式下,因為組態(tài)時組態(tài)的地址是系統(tǒng)的I區(qū)和Q區(qū),所以是可以用MOVE來實現(xiàn)通訊的,但是同時也存在的問題是,這種方式下,通訊所用的I/Q區(qū)占用了S7-300的系統(tǒng)區(qū),而S7-300的系統(tǒng)區(qū)可使用范圍是有限的,所以在系統(tǒng)的實際I/O模塊較多時,通訊的數(shù)據(jù)量將會變得更加有限