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

而在PLC中，定時(shí)器的實(shí)現(xiàn)通常有兩種方法，一種是系統(tǒng)提供了一種軟的時(shí)間繼電器通常叫做TIMER，通常也還會(huì)有數(shù)量限制。比如S7-200會(huì)有256個(gè)（T0 到 T255），而S7-300根據(jù)具體的CPU型號(hào)不同會(huì)有256， 512乃至更多。等等。

另一種方法則是系統(tǒng)提供了一種專用的功能塊FB，專門(mén)用于定時(shí)器功能。而其實(shí)這是IEC61131-3標(biāo)準(zhǔn)所規(guī)定的。所以各PLC廠家只不過(guò)是實(shí)現(xiàn)了標(biāo)準(zhǔn)的要求而已。而對(duì)于S7-200這樣的沒(méi)有IEC定時(shí)器的系統(tǒng)，也只是因?yàn)槠錄](méi)有完全支持IEC標(biāo)準(zhǔn)?？梢?jiàn)IEC標(biāo)準(zhǔn)對(duì)PLC廠家雖然有一定的約束力，但極小。

我在幾年前就提出的，好的PLC程序，以及標(biāo)準(zhǔn)化的程序設(shè)計(jì)不要使用全局變量的M和T，前者M(jìn)的話題后來(lái)又延伸討論過(guò)多次，這回不涉及。這回主要探討定時(shí)器。我在講不用T的時(shí)候，指的是上面的TIMER定時(shí)器，即編號(hào)T0-T255這種。而有一些人腦回路可能有些多，看到我說(shuō)T就理解為T(mén)IMER，理解為定時(shí)器，理解為寫(xiě)程序中不用任何的延時(shí)功能，就跟我哭訴，不用延時(shí)功能都無(wú)法編程了。

我說(shuō)T不能用的時(shí)候可以用IEC定時(shí)器??！那個(gè)沒(méi)有編號(hào)，就不需要做編號(hào)規(guī)劃，就不會(huì)有編號(hào)沖突。而在沒(méi)有IEC定時(shí)器的PLC中怎么辦？那就需要自己設(shè)計(jì)自定義的定時(shí)器。到現(xiàn)在同行已經(jīng)普遍認(rèn)識(shí)到了這一點(diǎn)。比如在SMART 200中，包括官方的1847平臺(tái)中， 也都有自定義定時(shí)器實(shí)現(xiàn)的案例講座。

而到了博圖系統(tǒng)中，其實(shí)反而只有IEC定時(shí)器，而不再有時(shí)間繼電器TIMER了。我因?yàn)樽詮纳?jí)到PORTAL系統(tǒng)之后就沒(méi)再用過(guò)T， 所以反而很久之后才發(fā)現(xiàn)這一點(diǎn)。

PORTAL中將傳統(tǒng)的時(shí)間繼電器T取消了以后，其所提供的IEC定時(shí)器IEC_TIMER，其實(shí)機(jī)制原理與IEC標(biāo)準(zhǔn)的定時(shí)器還有一些差別，相當(dāng)于把兩者的功能給融合了。你如果仔細(xì)去研讀官方的文檔資料，會(huì)發(fā)現(xiàn)這一點(diǎn)。然而通常大多數(shù)人并沒(méi)有仔細(xì)貫通研讀官方文檔的習(xí)慣（也沒(méi)這個(gè)必要去浪費(fèi)太多的時(shí)間），有的時(shí)候就會(huì)掉到坑里被絆倒一下。

這是本文要探討的重點(diǎn)。

IEC定時(shí)器的好處在于，如果同一段程序用的是同樣的語(yǔ)言，比如SCL， 那么在不同廠家的PLC平臺(tái)之間是可以無(wú)縫移植的。這也是IEC標(biāo)準(zhǔn)設(shè)立的出發(fā)點(diǎn)。比如我在做西門(mén)子之外的其它品牌和平臺(tái)的標(biāo)準(zhǔn)化，ROCKWELL, CODESYS , MITSUBISH, OMRON, SCHNEIDER, B+R等等時(shí)，程序都是直接從PORTAL中移植到對(duì)方的平臺(tái)的。移植過(guò)程中對(duì)原有程序做了些語(yǔ)法適應(yīng)處理，但問(wèn)題主要出在西門(mén)子這一側(cè)功能太多，可以縱容不嚴(yán)謹(jǐn)?shù)恼Z(yǔ)法導(dǎo)致的。而那些程序如果倒過(guò)來(lái)要移植到PORTAL平臺(tái)，則會(huì)輕松許多。大部分程序塊都是直接復(fù)制過(guò)來(lái)就可以使用。

而有網(wǎng)友就抱怨，原本在其他某平臺(tái)中可以正常運(yùn)行的邏輯，移植（復(fù)制）到PORTAL中就不靈了，功能不能運(yùn)行了。

這個(gè)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類型，只不過(guò)是定義方法不同，然而運(yùn)行結(jié)果是相同的。

程序的初衷是，設(shè)定1S的周期，每到1S時(shí)間到，產(chǎn)生一個(gè)輸出，使用這個(gè)輸出進(jìn)行計(jì)數(shù)加1,然而當(dāng)定時(shí)器被再次調(diào)用時(shí)，又再次觸發(fā)定時(shí)器計(jì)時(shí)。

這個(gè)邏輯本身是正確沒(méi)有問(wèn)題的。在大部分的PLC平臺(tái)如CODESYS中執(zhí)行也可以得到正確的結(jié)果。

然而偏偏在TIA PORTAL中是不能正確運(yùn)行的。

其中的原因便是PORTAL中對(duì)這個(gè)定時(shí)器做了特別的處理。按照對(duì)官方資料的個(gè)人解讀， 程序的所有位置，只要對(duì)定時(shí)器的Q管腳執(zhí)行讀取， 系統(tǒng)都會(huì)在后臺(tái)默默執(zhí)行一次定時(shí)器邏輯，并刷新計(jì)算結(jié)果。

所以即便某一次Q為1，但在調(diào)用NOT Q的時(shí)候執(zhí)行一次，使得Q值從1刷新變?yōu)榱?，就導(dǎo)致IN管腳永遠(yuǎn)為1，沒(méi)有為0的機(jī)會(huì)，那么定時(shí)器就再也不會(huì)被重新觸發(fā)計(jì)時(shí)了。那么后面的計(jì)數(shù)值就不會(huì)有變化了。

所以，不可以把PORTAL中的IEC定時(shí)器簡(jiǎn)單當(dāng)做一個(gè)FB/SFB來(lái)看待。盡管它們?cè)贔B中都是同樣的多重背景存在。

上述邏輯，且不說(shuō)CODSYS中可以正常運(yùn)行，即便在STEP7 V5中，也是可以正常的。

看我在STEP7中用梯形圖搭出來(lái)的邏輯以及運(yùn)行結(jié)果：

在STEP7中， TON是一個(gè)SFB， 編號(hào)為SFB4，把其當(dāng)做一個(gè)普通的多重背景的FB來(lái)調(diào)用，即可實(shí)現(xiàn)定時(shí)器功能。這里用梯形圖演示了同樣的邏輯。對(duì)于看不懂前面的SCL語(yǔ)言的讀者，可以通過(guò)這里的LAD理解。

注意到，在定時(shí)器的前面的IN管腳我連續(xù)使用了2次Q輸出，效果是相同的。原因是如果只用一次，會(huì)報(bào)紅色錯(cuò)誤。說(shuō)明STEP7中很警惕這樣的用法。

由此，我們可以想到，如果在博圖中我們自定義一個(gè)自己的定時(shí)器TON FB，應(yīng)該就可以避免上述的錯(cuò)誤。

即：

建立FB:TON_W， 管腳如TON完全一致，程序中也只是簡(jiǎn)單調(diào)用一次TON。

然后正式的程序中，參數(shù)定義部分原本TON1的類型為T(mén)ON_TIME,全部更改為T(mén)ON_W，即可。

然后上述的從CODESYS移植過(guò)來(lái)的程序就都可以正常運(yùn)行了。

技能很簡(jiǎn)單，原理也很簡(jiǎn)單。

然而卻是一項(xiàng)基礎(chǔ)的工作，補(bǔ)上了從CODESYS等其它平臺(tái)向PORTAL平臺(tái)程序移植的坑。

所以，總的來(lái)說(shuō)，我是在積累記錄平臺(tái)之間程序移植的各種坑，并提前找到填坑的解決方案。那么，在做正式的項(xiàng)目的時(shí)候，因?yàn)橛羞@些積累的提前量，就會(huì)順利得多。短時(shí)間內(nèi)實(shí)現(xiàn)程序的跨平臺(tái)移植，才成為可能。

不知道有多少同行認(rèn)同這樣的做法。

審核編輯 ：李倩