西门子PLC之计时器故障分析

定时器不工作

有些用户在使用定时器编程后,发现定时器并没有按照自己的意图去计时工作,出现了不计是错误,进而去怀疑硬件是否故障,CPU是否工作正常等等,浪费了大量的时间和精力.实际上这是由于用户对定时器特性不了解所造成的误解.下面的例子将说明这个问题.

例如:

程序原目的:

I4.2 的上升沿触发T50,T60的定时,并在T60定时结束后,复位M12.0.

故障现象:

I4.2可以触发T50,T60的定时,但有时即使I4.2 再次将M12.0置位为1,T50不计时

定时器错误:

故障分析:

首先要明确这个故障现象既不是硬件故障,也不是语句错误所引起的,而是对定时器使用不正确引起的故障.

现在我们分析此故障是如何产生的:

1.某个扫描周期,a.I4.2 的上升沿位置位M12.0 ，I4.2恢复为0。

2.

a.当T60计时到时，Network2中M12.0被复位（注意是 在SD T50语句的后面），此扫描周期末M12.0由1变为了0。

b.Network3 中T50，T60被复位。

3.扫描周期N+1

a.如果此时I4.2 恰恰出现上升沿置，尽管M12.0在上个扫描周期曾经变为0，但在本扫面周期开始就变为了1，定时器T50在上个扫描周期接受到的M12.0状态为1，定时器T50在本扫描周期接受到的M12.0状态也为1所以T50将不会工作

定时器正确使用示意：

定时器在扫描周期N与扫描周期N+ 1之间正确地接收到了上升沿的变化，所以能够常工作。

故障总结：

定时器计时需要正确地接收到输入端上升沿的变化，如果没有严格遵守这一逻辑顺序，常见的故障现象为定时器不计时工作。这种故障现象可能很隐蔽，本例的原始程序在实际工作中几天才会出现一次故障现象。由于原始程序包括大量的附加逻辑，子程序，语句位置也比较分散，所以排除此故障现象所用的时间超过了3天。

此程序改正的方法非常多，例如在位置M12.0指令前增加一些限制条件，用户可以自己尝试。

大家注意，这里t的时间是8S，我们知道，一个程序的扫描周期很短，可能才十几-----几十毫秒，在线时候可以监控到Scan Cycle Time 。

那这个时间不是远远超过了扫描周期么？

我们又知道，如果程序扫描周期大于最大扫描周期监控时间Scan Cycle Monitoring time，那么将会触发中断，甚至造成CPU进入STOP状态。

其实，计时器的执行是异步于OB1 循环扫描，只要计时器运行后，在每一周期扫描到计时器的触发端S信号如果为1，那么计时器就将在此周期继续计时。因此，它对于最大周期监控时间并没有太大的影响，只是调用语句时占用了少许US的时间。

----------------------------END-----------------------

每天进步一点点

Make small but daily progress