定時器的應用在PLC應用中算是最基礎的高級算法。就好比在傳統(tǒng)的繼電器控制柜中，簡單邏輯用繼電器就可以搭成。然而如果有延時的需求，就需要加上幾個時間繼電器，然后整個柜子瞬間就顯得高大上了。

而在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)程序的跨平臺移植，才成為可能。

不知道有多少同行認同這樣的做法。

審核編輯 ：李倩