发表于：2022/12/21 16:32:27
#0楼
1220 【万泉河】博图中的IEC定时器
定时器的应用在PLC应用中算是最基础的高级算法。 就好比在传统的继电器控制柜中，简单逻辑用继电器就可以搭成。然而如果有延时的需求，就需要加上几个时间继电器，然后整个柜子瞬间就显得高大上了。
而在PLC中，定时器的实现通常有两种方法，一种是系统提供了一种软的时间继电器通常叫做TIMER，通常也还会有数量限制。 比如S7-200会有256个（T0 到 T255），而S7-300根据具体的CPU型号不同会有256， 512乃至更多。等等。
另一种方法则是系统提供了一种专用的功能块FB，专门用于定时器功能。而其实这是IEC61131-3标准所规定的。所以各PLC厂家只不过是实现了标准的要求而已。而对于S7-200这样的没有IEC定时器的系统，也只是因为其没有完全支持IEC标准。可见IEC标准对PLC厂家虽然有一定的约束力，但极小。
我在几年前就提出的，好的PLC程序，以及标准化的程序设计不要使用全局变量的M和T，前者M的话题后来又延伸讨论过多次，这回不涉及。这回主要探讨定时器。我在讲不用T的时候，指的是上面的TIMER定时器，即编号T0-T255这种。 而有一些人脑回路可能有些多，看到我说T就理解为TIMER，理解为定时器，理解为写程序中不用任何的延时功能，就跟我哭诉，不用延时功能都无法编程了。
我说T不能用的时候可以用IEC定时器啊！那个没有编号，就不需要做编号规划，就不会有编号冲突。而在没有IEC定时器的PLC中怎么办？那就需要自己设计自定义的定时器。到现在同行已经普遍认识到了这一点。 比如在SMART 200中，包括官方的1847平台中， 也都有自定义定时器实现的案例讲座。
而到了博图系统中，其实反而只有IEC定时器，而不再有时间继电器TIMER了。 我因为自从升级到PORTAL系统之后就没再用过T， 所以反而很久之后才发现这一点。
PORTAL中将传统的时间继电器T取消了以后，其所提供的IEC定时器IEC_TIMER，其实机制原理与IEC标准的定时器还有一些差别，相当于把两者的功能给融合了。你如果仔细去研读官方的文档资料，会发现这一点。 然而通常大多数人并没有仔细贯通研读官方文档的习惯（也没这个必要去浪费太多的时间），有的时候就会掉到坑里被绊倒一下。
这是本文要探讨的重点。
IEC定时器的好处在于，如果同一段程序用的是同样的语言，比如SCL， 那么在不同厂家的PLC平台之间是可以无缝移植的。这也是IEC标准设立的出发点。比如我在做西门子之外的其它品牌和平台的标准化，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,然而当定时器被再次调用时，又再次触发定时器计时。
这个逻辑本身是正确没有问题的。 在大部分的PLC平台如CODESYS中执行也可以得到正确的结果。
然而偏偏在TIA PORTAL中是不能正确运行的。
其中的原因便是PORTAL中对这个定时器做了特别的处理。按照对官方资料的个人解读， 程序的所有位置，只要对定时器的Q管脚执行读取， 系统都会在后台默默执行一次定时器逻辑，并刷新计算结果。
所以即便某一次Q为1，但在调用NOT Q的时候执行一次，使得Q值从1刷新变为了0，就导致IN管脚永远为1，没有为0的机会，那么定时器就再也不会被重新触发计时了。那么后面的计数值就不会有变化了。
所以，不可以把PORTAL中的IEC定时器简单当做一个FB/SFB来看待。尽管它们在FB中都是同样的多重背景存在。
上述逻辑，且不说CODSYS中可以正常运行，即便在STEP7 V5中，也是可以正常的。
看我在STEP7中用梯形图搭出来的逻辑以及运行结果：
在STEP7中， TON是一个SFB， 编号为SFB4，把其当做一个普通的多重背景的FB来调用，即可实现定时器功能。 这里用梯形图演示了同样的逻辑。 对于看不懂前面的SCL语言的读者，可以通过这里的LAD理解。
注意到，在定时器的前面的IN管脚我连续使用了2次Q输出，效果是相同的。 原因是如果只用一次，会报红色错误。说明STEP7中很警惕这样的用法。
由此，我们可以想到，如果在博图中我们自定义一个自己的定时器TON FB，应该就可以避免上述的错误。
即：
建立FB:TON_W， 管脚如TON完全一致，程序中也只是简单调用一次TON。
然后正式的程序中，参数定义部分原本TON1的类型为TON_TIME,全部更改为TON_W，即可。
然后上述的从CODESYS移植过来的程序就都可以正常运行了。
技能很简单，原理也很简单。
然而却是一项基础的工作，补上了从CODESYS等其它平台向PORTAL平台程序移植的坑。
所以，总的来说，我是在积累记录平台之间程序移植的各种坑，并提前找到填坑的解决方案。 那么，在做正式的项目的时候，因为有这些积累的提前量，就会顺利得多。 短时间内实现程序的跨平台移植，才成为可能。
不知道有多少同行认同这样的做法。
更多关于PLC标准化编程烟台方法的知识，可以关注公众号获取文章了解
要加入自动化俱乐部或者群侠纯技术微信群的，也可以在公众号中获取加群方法。
定时器的应用在PLC应用中算是最基础的高级算法。 就好比在传统的继电器控制柜中，简单逻辑用继电器就可以搭成。然而如果有延时的需求，就需要加上几个时间继电器，然后整个柜子瞬间就显得高大上了。
而在PLC中，定时器的实现通常有两种方法，一种是系统提供了一种软的时间继电器通常叫做TIMER，通常也还会有数量限制。 比如S7-200会有256个（T0 到 T255），而S7-300根据具体的CPU型号不同会有256， 512乃至更多。等等。
另一种方法则是系统提供了一种专用的功能块FB，专门用于定时器功能。而其实这是IEC61131-3标准所规定的。所以各PLC厂家只不过是实现了标准的要求而已。而对于S7-200这样的没有IEC定时器的系统，也只是因为其没有完全支持IEC标准。可见IEC标准对PLC厂家虽然有一定的约束力，但极小。
我在几年前就提出的，好的PLC程序，以及标准化的程序设计不要使用全局变量的M和T，前者M的话题后来又延伸讨论过多次，这回不涉及。这回主要探讨定时器。我在讲不用T的时候，指的是上面的TIMER定时器，即编号T0-T255这种。 而有一些人脑回路可能有些多，看到我说T就理解为TIMER，理解为定时器，理解为写程序中不用任何的延时功能，就跟我哭诉，不用延时功能都无法编程了。
我说T不能用的时候可以用IEC定时器啊！那个没有编号，就不需要做编号规划，就不会有编号冲突。而在没有IEC定时器的PLC中怎么办？那就需要自己设计自定义的定时器。到现在同行已经普遍认识到了这一点。 比如在SMART 200中，包括官方的1847平台中， 也都有自定义定时器实现的案例讲座。
而到了博图系统中，其实反而只有IEC定时器，而不再有时间继电器TIMER了。 我因为自从升级到PORTAL系统之后就没再用过T， 所以反而很久之后才发现这一点。
PORTAL中将传统的时间继电器T取消了以后，其所提供的IEC定时器IEC_TIMER，其实机制原理与IEC标准的定时器还有一些差别，相当于把两者的功能给融合了。你如果仔细去研读官方的文档资料，会发现这一点。 然而通常大多数人并没有仔细贯通研读官方文档的习惯（也没这个必要去浪费太多的时间），有的时候就会掉到坑里被绊倒一下。
这是本文要探讨的重点。
IEC定时器的好处在于，如果同一段程序用的是同样的语言，比如SCL， 那么在不同厂家的PLC平台之间是可以无缝移植的。这也是IEC标准设立的出发点。比如我在做西门子之外的其它品牌和平台的标准化，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,然而当定时器被再次调用时，又再次触发定时器计时。
这个逻辑本身是正确没有问题的。 在大部分的PLC平台如CODESYS中执行也可以得到正确的结果。
然而偏偏在TIA PORTAL中是不能正确运行的。
其中的原因便是PORTAL中对这个定时器做了特别的处理。按照对官方资料的个人解读， 程序的所有位置，只要对定时器的Q管脚执行读取， 系统都会在后台默默执行一次定时器逻辑，并刷新计算结果。
所以即便某一次Q为1，但在调用NOT Q的时候执行一次，使得Q值从1刷新变为了0，就导致IN管脚永远为1，没有为0的机会，那么定时器就再也不会被重新触发计时了。那么后面的计数值就不会有变化了。
所以，不可以把PORTAL中的IEC定时器简单当做一个FB/SFB来看待。尽管它们在FB中都是同样的多重背景存在。
上述逻辑，且不说CODSYS中可以正常运行，即便在STEP7 V5中，也是可以正常的。
看我在STEP7中用梯形图搭出来的逻辑以及运行结果：
在STEP7中， TON是一个SFB， 编号为SFB4，把其当做一个普通的多重背景的FB来调用，即可实现定时器功能。 这里用梯形图演示了同样的逻辑。 对于看不懂前面的SCL语言的读者，可以通过这里的LAD理解。
注意到，在定时器的前面的IN管脚我连续使用了2次Q输出，效果是相同的。 原因是如果只用一次，会报红色错误。说明STEP7中很警惕这样的用法。
由此，我们可以想到，如果在博图中我们自定义一个自己的定时器TON FB，应该就可以避免上述的错误。
即：
建立FB:TON_W， 管脚如TON完全一致，程序中也只是简单调用一次TON。
然后正式的程序中，参数定义部分原本TON1的类型为TON_TIME,全部更改为TON_W，即可。
然后上述的从CODESYS移植过来的程序就都可以正常运行了。
技能很简单，原理也很简单。
然而却是一项基础的工作，补上了从CODESYS等其它平台向PORTAL平台程序移植的坑。
所以，总的来说，我是在积累记录平台之间程序移植的各种坑，并提前找到填坑的解决方案。 那么，在做正式的项目的时候，因为有这些积累的提前量，就会顺利得多。 短时间内实现程序的跨平台移植，才成为可能。
不知道有多少同行认同这样的做法。
更多关于PLC标准化编程烟台方法的知识，可以关注公众号获取文章了解
要加入自动化俱乐部或者群侠纯技术微信群的，也可以在公众号中获取加群方法。
附件:
[本地下载]PLC标准化编程
