在一个礼拜前的中午正按惯例睡午觉呢，接到一个好久未连系的前同事电话，我们以前相处的还是不错的也算半师半友。他对我说有个客户的一套300的plc运行了五六年了都正常，但今天早上无征兆的突然变红灯，系统都停运，上位机的数据全部成阴影连不上PLC。业主很着急，费用都好说，能不能通过他找到人排除故障让系统尽快恢复正常。他简单介绍完情况后问我愿不愿意走一趟，我实话实说类似这种情况能大能小但不能保证百分百的立竿见影有效果，别说是别人的项目，就是我亲手做的项目有时短时间内还不能保证手到病除。交流继续中。。。。。。

    既然我应承了而且业主强调越快越好，那我就立即订了高铁票，想想不保险看时间还够就回镇上的基地准备点备品备件，有总比没有强。坐在回镇上的公交车上我捋了捋整个过程，也看看现场传回来的短视频和相片。可能业主着急乱了分寸，我呢也没睡醒被带了节奏，忘了提醒对方既然系统都趴窝了有没有重新上一下电试试呢。就我调试的经历确实有莫名其妙的问题是可以通过重新上电来排除的。我在微信上交代业主备份一下重要数据（哪怕拍照或截屏都行）后不行的话就重新上一下电看看什么情况。过了半个小时后业主传来信息通过重新上电系统已经恢复运行了，就看问题能不能昨日重现了。虽然没找出真正原因但先恢复生产以观后效也不失为一种不错的选择。

    通过这件事我再一次印证了一位前辈对我说过的话：急事缓办。非常有道理。不然退票费也可以晚上加个菜了，哈哈哈。附图看样子是有点慌的。

    上升指令本是一条简单指令，和常开、常闭指令一样都是常用的基本指令。以前在使用S7-200的时候基本不会去过多关注上升沿指令，因为那时候不需要自己分配边缘存储器。现在在S7-1200中每次用到上升沿指令都需要自己分配边缘存储器，在编程上感觉确实不爽，由此开始想有没有什么捷径，心想“不就是一个简单的上升沿指令，用上一个扫描周期的状态和当前状态做一个比较吗?"。(下面的程序是参考论坛网友优化过的！)

    程序：首先创建一个FB块，里面添加几行SCL代码。

测试1 ：在主程序OB1中调用FB块程序如下，测试效果正常，变量上升沿触发正常！ 

    测试二：同样在主程序中调用FB块程序如下，

    步骤一：当M30.2置1时，测试正常，上升沿正常触发 。

    步骤二：当 M30.2置0，再将M30.0置1，间隔一个扫描周期以上再将M30.2置1，这时突然触发一个上升沿。结果是测试失败！

        测试三：使用系统的上升沿指令程序如下。

        步骤一：和测试二的步骤二一样，先将M30.2置0，再将M30.0置1，间隔一个扫描周期以上，再将M30.0置1，这是并没有出现测试二的情况。

    总结：在测试三中，不管M30.2是否为1，边缘存储器 M30.3的状态都随 这M30.0的状态发生变化。在测试二中，当M30.2的状态为0时，FB块中的边缘存储器并不随M30.0变化，保持不变！

通过上面的测试得到的结果是：并不能通过FB块编辑程序来代替系统的上升沿指令。