前两天使用其他plc编写了一个程序，调试过程中发现了一个“奇怪”的问题，开始感觉很不理解，找到原因后恍然大悟。今天共享出来，大家一起探讨。
1.怪异事实——遇到问题
有一天有人告诉你，他遇到了一件“怪事”：plc输出点y0常开点闭合启动时间继电器t30，计时时间未到，y0断开，t30 计时器不会停止，一直保持工作状态。相信大家听到以上事实后第一反应可能与我一样，冒出一句“不可能”后就会猜测是不是t30重复使用，是不是 plc坏了……各种各样的猜测被一一否定后，看到以下实时监控到的信息（图一），相信大家都会感到吃惊，感觉问题比较怪异，一时找不到原因，最后只能无奈的宣布“plc坏了”。
我就是这么干的！
理由很充分，y0常开点没有闭合（已经断开，有监控为证），t30还能继续计时？没有理由啊！
可是更换了一台新的plc，问题依旧。
悲催！囧！
想起前辈说过，“当你怀疑plc有问题时，大多是你自己出了问题”，于是开始老老实实找原因。
图一：实时监控t30
ps：朋友们，当你实时监控看到y0没有闭合，但后面时间继电器t30不断地计时到设定值，然后t30有输出，你当时会怎么想？
2.见怪不怪——分析问题
毋庸置疑，显然问题出在编制的plc程序上，这台plc程序只有简单的177步，很好分析，但由于判断失误，更换了plc没有解决问题，在嘈杂与喧嚣的氛围中，我实在无法静下心来思考问题究竟出在哪里，只得放弃现场寻找原因“打道回府”。
当天晚上躺在床上一直想着这个怪异的问题。突然间脑洞大开：会不会是顺序扫描造成的结果呢？如果图一之前有输出y0，图一之后输出y0断开不正是会出现以上遇到的问题吗？
3.原来如此——解决问题
第二天赶紧实际验证，整个程序与此问题有关的逻辑段有如下两处，见以下截图二，图三。
图二：实时监控set y0（set y0 位置在tmr t30 d586之前）
图三：实时监控rst y0（rst y0 位置在tmr t30 d586之后）
仔细分析以上三个监控截图，问题真相不难发现。前面set y0 条件一直存在（图二），虽然后面x3接通执行了rst y0（图三），导致最终扫描结果输出y0关闭（plc 实际y0没有输出），但这并不能说明图一中 y0的常开点没有闭合。事实上顺序扫描执行到程序段tmr t30 d586（图一）时，由于之前有 set y0 执行，所以y0常开点闭合，计时器t30自然会不断地继续计时了。
表面看来，好像计时器一旦启动就失控，不能随启动条件消失而停止计时并且自行复位，监控看到的这一事实着实让人不可思议，但是仔细推究，还是有其道理。
找到了原因，解决问题很容易。在图一程序段y0常开点后面加上x3常闭点问题马上解决，或者在图二程序段中将m500常开点改为上升沿触发set y0。
plc由上到下由左到右顺序扫描执行指令，又一次领教了规则的严肃性。