1220 【萬泉河】博圖中的IEC定時器
定時器的應用在PLC應用中算是最基礎的高級算法。 就好比在傳統(tǒng)的繼電器控制柜中，簡單邏輯用繼電器就可以搭成。然而如果有延時的需求，就需要加上幾個時間繼電器，然后整個柜子瞬間就顯得高大 1220 【萬泉河】博圖中的IEC定時器.pdf (310 K) 下载次数:83 上了。 
而在PLC中，定時器的實現(xiàn)通常有兩種方法，一種是系統(tǒng)提供了一種軟的時間繼電器通常叫做TIMER，通常也還會有數量限制。 比如S7-200會有256個（T0 到 T255），而S7-300根據具體的CPU型號不同會有256， 512乃至更多。等等。
另一種方法則是系統(tǒng)提供了一種專用的功能塊FB，專門用于定時器功能。而其實這是IEC61131-3標準所規(guī)定的。所以各PLC廠家只不過是實現(xiàn)了標準的要求而已。而對于S7-200這樣的沒有IEC定時器的系統(tǒng)，也只是因為其沒有完全支持IEC標準。可見IEC標準對PLC廠家雖然有一定的約束力，但極小。
我在幾年前就提出的，好的PLC程序，以及標準化的程序設計不要使用全局變量的M和T，前者M的話題后來又延伸討論過多次，這回不涉及。這回主要探討定時器。我在講不用T的時候，指的是上面的TIMER定時器，即編號T0-T255這種。 而有一些人腦回路可能有些多，看到我說T就理解為TIMER，理解為定時器，理解為寫程序中不用任何的延時功能，就跟我哭訴，不用延時功能都無法編程了。
我說T不能用的時候可以用IEC定時器��！那個沒有編號，就不需要做編號規(guī)劃，就不會有編號沖突。而在沒有IEC定時器的PLC中怎么辦？那就需要自己設計自定義的定時器。到現(xiàn)在同行已經普遍認識到了這一點。 比如在SMART 200中，包括官方的1847平臺中， 也都有自定義定時器實現(xiàn)的案例講座。 
而到了博圖系統(tǒng)中，其實反而只有IEC定時器，而不再有時間繼電器TIMER了。 我因為自從升級到PORTAL系統(tǒng)之后就沒再用過T， 所以反而很久之后才發(fā)現(xiàn)這一點。 
PORTAL中將傳統(tǒng)的時間繼電器T取消了以后，其所提供的IEC定時器IEC_TIMER，其實機制原理與IEC標準的定時器還有一些差別，相當于把兩者的功能給融合了。你如果仔細去研讀官方的文檔資料，會發(fā)現(xiàn)這一點。 然而通常大多數人并沒有仔細貫通研讀官方文檔的習慣（也沒這個必要去浪費太多的時間），有的時候就會掉到坑里被絆倒一下。
這是本文要探討的重點。 
IEC定時器的好處在于，如果同一段程序用的是同樣的語言，比如SCL， 那么在不同廠家的PLC平臺之間是可以無縫移植的。這也是IEC標準設立的出發(fā)點。比如我在做西門子之外的其它品牌和平臺的標準化，ROCKWELL, CODESYS , MITSUBISH, OMRON, SCHNEIDER, B+R等等時，程序都是直接從PORTAL中移植到對方的平臺的。 移植過程中對原有程序做了些語法適應處理，但問題主要出在西門子這一側功能太多，可以縱容不嚴謹的語法導致的。而那些程序如果倒過來要移植到PORTAL平臺，則會輕松許多。 大部分程序塊都是直接復制過來就可以使用。
而有網友就抱怨，原本在其他某平臺中可以正常運行的邏輯，移植（復制）到PORTAL中就不靈了，功能不能運行了。 
這個SCL程序腳本大致是：#TON1(IN:=NOT #TON1.Q,PT:=T#1s);IF #TON1.Q THEN    #AAAA := #AAAA + 1;END_IF;
或者：#TON2.TON(IN := #TON2.Q,          PT := T#1S);IF #TON2.Q THEN    #BBBB := #BBBB + 1;END_IF;其中TON1定義為TON_TIME類型， 而TON2定義為IEC_TIMER類型，只不過是定義方法不同，然而運行結果是相同的。  程序的初衷是，設定1S的周期，每到1S時間到，產生一個輸出，使用這個輸出進行計數加1,然而當定時器被再次調用時，又再次觸發(fā)定時器計時。
這個邏輯本身是正確沒有問題的。 在大部分的PLC平臺如CODESYS中執(zhí)行也可以得到正確的結果。
然而偏偏在TIA PORTAL中是不能正確運行的。 
其中的原因便是PORTAL中對這個定時器做了特別的處理。按照對官方資料的個人解讀， 程序的所有位置，只要對定時器的Q管腳執(zhí)行讀取， 系統(tǒng)都會在后臺默默執(zhí)行一次定時器邏輯，并刷新計算結果。
所以即便某一次Q為1，但在調用NOT Q的時候執(zhí)行一次，使得Q值從1刷新變?yōu)榱?，就導致IN管腳永遠為1，沒有為0的機會，那么定時器就再也不會被重新觸發(fā)計時了。那么后面的計數值就不會有變化了。 
所以，不可以把PORTAL中的IEC定時器簡單當做一個FB/SFB來看待。盡管它們在FB中都是同樣的多重背景存在。
上述邏輯，且不說CODSYS中可以正常運行，即便在STEP7  V5中，也是可以正常的。
看我在STEP7中用梯形圖搭出來的邏輯以及運行結果： 
在STEP7中， TON是一個SFB， 編號為SFB4，把其當做一個普通的多重背景的FB來調用，即可實現(xiàn)定時器功能。 這里用梯形圖演示了同樣的邏輯。 對于看不懂前面的SCL語言的讀者，可以通過這里的LAD理解。 
注意到，在定時器的前面的IN管腳我連續(xù)使用了2次Q輸出，效果是相同的。 原因是如果只用一次，會報紅色錯誤。說明STEP7中很警惕這樣的用法。
由此，我們可以想到，如果在博圖中我們自定義一個自己的定時器TON FB，應該就可以避免上述的錯誤。 
即： 建立FB:TON_W， 管腳如TON完全一致，程序中也只是簡單調用一次TON。然后正式的程序中，參數定義部分原本TON1的類型為TON_TIME,全部更改為TON_W，即可。 
然后上述的從CODESYS移植過來的程序就都可以正常運行了。 
技能很簡單，原理也很簡單。 
然而卻是一項基礎的工作，補上了從CODESYS等其它平臺向PORTAL平臺程序移植的坑。 
所以，總的來說，我是在積累記錄平臺之間程序移植的各種坑，并提前找到填坑的解決方案。 那么，在做正式的項目的時候，因為有這些積累的提前量，就會順利得多。 短時間內實現(xiàn)程序的跨平臺移植，才成為可能。 
不知道有多少同行認同這樣的做法。 

更多關于PLC標準化編程煙臺方法的知識，可以關注公眾號獲取文章了解
要加入自動化俱樂部或者群俠純技術微信群的，也可以在公眾號中獲取加群方法。  1220 【萬泉河】博圖中的IEC定時器.pdf (310 K) 下载次数:83