最近，沿指令的几个贴子都比较热。根据大家的发贴的情况看，认为沿指令不好用、有问题的不在少数，也有重量级的工程师认为沿指令存在不可靠不稳定的问题。

对沿指令的偏见由来已久，根子很深，基础很实。但是没有见过真正经得起验证的例子来说明沿指令有问题。

一般的问题大概是这样的：在某个地方使用了沿指令，没有达到编程者的要求，或者期望的值没有出现；去掉沿指令、或者把沿指令移到别的地方，问题解决，就认定为是沿指令有问题，不可靠不稳定。

能不能把一些无关的程序段去掉，只留问题部分的程序？这样的例子有出现过吗？

本人也举不出这样的例子。因为沿指令根本不存在不可靠不稳定的问题。

本帖，在“公认”为沿指令再易出问题的地方，使用实例来证明沿指令的稳定与可靠，还原其本来面目。

举例之前，几个事情讲在前面：

1、这里讲的是200smart的指令，不作横向比较。横向比较，问题就偏重在使用习惯、可移植等上面。使用习惯不是指令的问题，没道理好讲；移值，就算是200和200smart之间，也只能做到大部分兼容。

2、为什么要用沿指令？完全可以不用，或自己写相同功能的程序段来代替。不错，大部分指令都不是必须，可以使用其它指令的组合来实现。就算当年很难取代的定时器，自从出了32位1ms的公共时基后，普通的T开头的定时器，也变得可有可无。所以这个，也不是本贴希望讨论的话题。

3、关于有意义、没意义。有人会提出来，这样做有意义吗？谁会这样写程序？

貌似没有“意义”的指令可以写出许多，如：

NOP指令，有多少人认为它的存在是有意义的？

ANDW AC0，AC0，自已和自己作与操作，值根本不会起变化，使用它有意义吗？

如果程序不是你写的，有没有意义无从谈起。

如果你是明明白白使用的，这些指令就是很有意义的。

一、第1个实例：沿指令在中断里

认为沿指令不能在中断里使用，是最讲不出道理的。

LAD程序：

主程序部分：

中断部分：

STL程序：

主程序部分：

中断部分：

在线监视VD0、VD4的变化，有没有同步？

如果你有机会看到VD0比VD4多1个计数，这个机率是1%。因为主程序上的 P（EU） 比中断中的 P（EU） 早工作10ms。

程序持续运行，中断内的 P 不会漏1个计数或多1个计数。32位长整数可以计49天的。你要不信邪，运行1个月以后看结果。

如果真出现中断内的 P 不可靠不稳定，你把这个CPU扔了吧。

附上源程序：

实例1：沿指令在中断.rar

别人拍不拍砖暂且不管，我先来点个赞，期待后续精彩的案例。沿指令用于切换信号时的复位就是个很好的例子，不用做什么脉冲，一个上升沿或下降沿就能轻松搞定了。

沿指令重要性不能小看了，特别是在置位复位操作中，不用这条指令可能都没办法用其他逻辑去替代，脉冲根本就不可能代替沿指令。

更正1楼文字中的错误：32位长整数，1ms增1，溢出时间是49天。1秒增1，溢出时间在100年以上。

可以让程序一直运行，观察变量的变动。

二、第2个实例：沿指令在多次调用的子程序里

多次调用会对边沿重复取吗？不会。

LAD程序：

主程序部分：

子程序部分：

STL程序：

主程序部分：

子程序部分：

在线监视VD0、VD4的变化，有没有同步？

程序刚开始时如果你有机会看到VD0比VD4多1个计数，这个机率不到0.1%。因为主程序上的 P（EU） 比子程序中的 P（EU） 早工作一点点时间。

程序持续运行，子程序内的 P 不会漏1个计数或多1个计数。32位长整数可以计100年的。

附上源程序：

实例2：沿指令在多次调用子程序_参数传入.rar

 假设一年366天    每秒加1

 2^32/(366*24*60*60)=135.8204088年

  每毫米加1

 2^32/(24*60*60*1000)=49.71026963天

谢谢分享  好

在置位复位当中我比较少用边缘触发。

一般置位前串联自己的常闭，复位前串联自己的常开，干嘛要用边缘指令？

本贴是为沿指令作无罪辩护。

至于沿指令能排上什么用场？就算它是酒囊饭袋能力低下，只要不作奸犯科规矩做事，就是个合格称职指令。

我表述的不太明确了，我指的复位是发生保护之后，排除故障后的复位。当时因为矿井的情况比较特殊，客户要求自动手动转换之外不允许其他的按钮，但控制板发生故障之后无法复位，所以在手动切自动的时候，加入一个上升沿，先给控制板复一次位。

我觉得要用好沿指令，首先要弄明白扫描周期，利用扫描周期也可以巧妙做沿指令

三、实例3：沿指令在多次调用的子程序内，信号在子程序内自取

多次调用会对边沿重复取吗？不会。

LAD程序：

主程序部分：

子程序部分：

STL程序：

主程序部分：

子程序部分：

在线监视VD0、VD4的变化，有没有同步？

程序刚开始时如果你有机会看到VD0比VD4多1个计数，这个机率不到0.1%。因为主程序上的 P（EU） 比子程序中的 P（EU） 早工作一点点时间。

程序持续运行，子程序内的 P 不会漏1个计数或多1个计数。32位长整数可以计100年的。

附上源程序：

实例3：沿指令在多次调用子程序_信号自取.rar

如果实例3把子程序的vd4改成in/out参数就好了。然后四个子程序都给不同的地址，你将会看见……咦？……哦！原来……。

这个效果，就是最后要总结的：沿指令不能一女二嫁！

四、实例4：沿指令在条件调用的子程序内

如果子程序是有条件调用的，不保证每周期都调用，那里面的沿指令会工作不正常吗？

担心是多余的，它一样稳定可靠，不会错过它应该捉到的每一个边沿。

LAD程序：

主程序部分：

子程序部分：

STL程序：

主程序部分：

子程序部分：

在线监视VD0、VD4的变化，有没有同步？

程序刚开始时如果你有机会看到VD0比VD4多1个计数，这个机率可能是10%。因为主程序上的 P（EU） 比子程序中的 P（EU） 早工作100ms。

程序持续运行，子程序内的 P 不会漏1个计数或多1个计数。32位长整数可以计100年的。

附上源程序：

实例4：沿指令在条件调用子程序.rar

三、实例3A：沿指令在多次调用的子程序内，SM0.5的发现

按 芳季 的建议，计数改为 IN/OUT 参数，所有IN/OUT的计数值加起来，应该和主程序的计数是一样的。

LAD程序：

主程序部分：

子程序部分：

STL程序：

主程序部分：

子程序部分：

在线监视VD0、VD4的变化，有没有同步？

原本以为，VD8、VD12、VD16、VD20均有机会获得计数，

但它们的总和应该和主程序的VD0相同。

短时内的观察得到：只有第一个调用的VD8有计数。

可以推测（手册上有没有？），SM0.5不在用户程序执行

的时段内更新，也是在扫描周期的系统处理的某个时刻更新。

这是短时间观察的结论，不能下结论的。观察几再说吧。

附上源程序：

实例3A：沿指令在多次调用子程序.rar

1：用单次中断而不是循环中断来测试一下沿指令

2：用形参传递而不是实参调用再来测试一下沿指令

3：循环中断的中断时间设置为500毫秒或以上，对应的SM0.5的加计数，看一下是什么结果？

4：示例2，示例3中子程序的调用实际是无条件调用，全扫描的

单次就变成……sm0.1类似。

形参实参没所谓。

大于500毫秒就相当于……扫描捕捉不到短于一个扫描周期的脉冲，要用高计。这般。

定时的中断可以看成是低速扫描周期。一样的分析。

 再重申一下我的观点，沿指令本身没有问题，问题是使用是否恰当。

比如，在中断或条件执行的子程序中，使用沿指令是毫无意义的，这是我执行的比较严格的标准。

换句话说，就是沿指令必须在OB1中被全扫描。

比较宽泛的标准是在事件中断和单次条件执行的子程序不使用沿指令。

目前，YANXIAO版主做的测试都是在周期性中断或周期性条件执行的状况下，其中例程2/3子程序调用是无条件的，相当于全扫描逻辑，这不能说明问题。

另外，在S7-1200上的模拟200SMART的程序测试，500ms的中断周期，按YANXIAO版主的测试方法，很快出现读数不一致现象，不可恢复。

猜测的：SM0.5是一个系统时基，每隔0.5秒状态翻转，但对用户程序而言只是在扫描周期开始时刷新状态，如果扫描周期很长就会漏掉一些状态，举个极端的例子：扫描周期是1秒，扫描开始时是OFF态，则下一扫描周期开始时由于经过了1秒，SM0.5按时差翻转两次又回到了OFF态，用户的程序中就检测不到SM0.5的ON态。当然扫描周期的波动和0.5秒不是严格同步，实际用户程序可能还是有微弱机会检测到ON。要想捕捉到SM0.5的每一次ON，OFF状态，至少扫描周期不能超过0.5秒，这个符合采样定理。假如扫描周期达到1.5秒，用户程序得到SM0.5的状态可能是OFF ON 交替变化，于楼主而言的边沿指令这时会检测到变化从而输出。

很久以前在感受200的0.1秒分辨率定时器时就发现某一扫描周期大于0.1秒时比如0.3秒，到下一扫描周期执行定时指令时当前时间增加的量就是3.扫描周期波动也不会漏计时间。但对于SM0.5而言由于它只有ON OFF两个状态记录时间，用户程序不能及时读取状态的话势必导致计时丢失。累加SM0.5计时的程序尤其要注意这一点，如果发生这种可能的话不如读取系统时钟来计时还更可靠一些。