一个看似诡异的程序分析过程

  昨天同事电话求助说有一台压力机设备（西门子400系统），前天还好好的运行，昨天设备保养后试运行就异常了，主要表现为主滑块在手动模式下，无法下降运行，其它动作目前还没有发现问题。

  动作没有，除了外部硬件（液压、电气）原因外，具体程序控制也是“问题”查询的基本方法。于是，我到现场后，拿同事的电脑监控相关程序的输出，监控结果确实没有输出，那么，顺着这个控制程序查找到2个安全的必要条件是机器人在安全区域没有使能，另外一台辅助设备的原点显示已经到达，问题锁定在机器人搬运的原点信号没有通过总线给到压力机设备中。无论我让同事在总线上发送或者关闭机器人原点信号，这台设备的机器人原点判断信号就是没有反应。交叉引用看程序应用，这个信号点居然没有线圈驱动，难怪，总线的信号切换无法反应到压力机设备的相关信号上。

  由于是安全信号，这些信号均是压力机的关键信号点，得需要先理解信号的来龙去脉。首先查阅整体信号之间的传递，该总线为profibus DP通讯，通讯数据交换在I/O区域，而我监控到的信号是M地址区域，说明这个系统应该需要有一些传送指令，把通讯数据传递到M区，查看交叉引用，这个M点地址没有线圈，也没有类似的传送指令，那么，它是如何传递的呢？其次，话说这个设备之前运行一直正常，而设备保养后异常的可能原因会有那些？一时也无法追根溯源到现状，只能先放弃再说。手头着手分析相关的机器人原点信号，确实这个设备系统上也应用到这些关键信号，我又让同事通过手动切换信号的通断，确认这些信号的作用后，我大胆尝试着给这个机器人在原点的M信号，做线圈驱动控制。将程序编辑后下载，让同事再次切换信号的通断，信号切换正常。让同事启动设备，在手动状态下，试着运行设备正常，再继续做单循环也正常，说明本次问题的根源是这个机器人M信号，没有得到信号的传递，就是我开始交叉引用那里看到的没有线圈及指令的驱动，这个是这个程序的怪异之处。

小结：

1）  之前正常而目前出现问题，关键问题是这个M信号点没有得到一个需要的状态值，而之前一直运行正常。这个问题不亚乎这个程序不是最终版本的，可能由于同事经验上的欠缺或者操作失误，造成程序的丢失。

2）  如果程序没有丢失，那这个M点又将是如何使能的呢？很显然，在日常验证程序时，经常性的会遇到一些所谓的诡异情况，假设我使能一个M点线圈地址，然后我删除这个线圈，其结果这个M线圈所驱动的触点仍然会保持删除前的状态值。在此，可以想到可能出现问题的出处、及初始化的重要性了。

3）  就此另外一个根本原因就是程序逻辑方面的基础问题，对一些程序的基本知识点的缺乏，造成一些问题出现时，无法判断问题关键点出自哪些？说到底还是基本功问题了。

  我也经常性的看到某一些同事，在处理简单故障时，急于就成，通过简单粗暴的修改程序或者直接强制某一些点，来判断可能存在的问题，这样的处理非常不可取，也不理智、也无利于安全。所谓诡异的程序原本就没有，有，也大多是人为原因造就的。今天看到论坛上有一个问题，有感而发的想起刚刚昨天的那件事情。

感谢分享，受益匪浅

 经验老到，思维开阔。

点赞楼主爱岗敬业，技术一流，钻研精神超一流。原创好帖不仅优质，而且源源不断。

最终说明还是程序本身有问题，并不是PLC的问题，也就不要再赖人家M了(M：我招谁惹谁了)。

再反观，为啥以前那么多人用M都没问题，现在用M的就这么多问题？到底是程序问题？还是西门子软件编译出问题？或者现在的编译器不是以前的编译器了？

是的，就是自己编程或者维保过程中没有关注到的问题，我的标题缺少一个引号。

这个问题我在小结中也说了，可能是用户自己程序被“无意”丢失，或者在修改程序时，压根没有注意到这个问题。总之，也说明对编程这门学问理解层面尚欠一些“火候”，是这个故障引发的要因。

至于，经常性看到有对M区域应用层面的讨论，那是另外一个话题，不在这个层面。我也经常性看到动不动就是软件的bug，对这个我非常反感，也非常感冒这个。不是说软件一定没有bug，而是一般应用真的很难遇到bug的，就是遇到了也早有解决方案了。一款软件自推出到大家的应用，已经经过无数次验证人员的各自应用，相对到实际用户手里bug问题基本是被排除了的。

看来还需学习啊

 感觉写一段程序，修改的时间比写的时间多！

那是一定的，开始写是我根据具体工艺起的一个框架，洋洋洒洒一天可以列举很多项目。

而到了实际的调试阶段，就是增加一个点或者减去一个点，那种推敲反反复复的进行，可能需要很长一段时间，最后定下来。

我上面的案例实际上就可以真实反映出几个问题，如果我是忽悠的心态，那么，这个本“不是问题”，加加减减一处理，很快就可以所谓的修复设备，但这样的处理会埋下很大的安全隐患，对设备对人身很不利。而针对于一个点反反复复的推敲，对每一个点认真细致的判断，尽可能想到自己掌握的工艺和操作，这样的点应用就需要一段时间了。为什么要加，加的理由是什么？为什么要减，减的理由是什么？这样经过推敲出来的程序经得起考验。

跟着大佬学习

楼主也在冲压行业啊。不过冲压行业能上400系统的，都是大家伙吧。我见过的国产，湾湾冲床，1000T以下的，各种PLC都有。以三菱，欧姆龙，台达居多。

不是冲压行业，是汽车制造行业，锻造。

是压力机近W吨位的，现在W吨以上的压力机比比皆是，已经不稀奇了。

是的，是大家伙，你说的1000吨的吨位太小了，可能冲床行业算是比较大的了。

最终是m没有得到状态转换信号，楼主自己做了一个线圈，给m信号。一般的维保都是硬件上的，很少会动系统的。维保可能会动某些sensor后者接头，导致程序不能正常进行而且不报警，但维保后程序里没线圈反馈信号的没见过。

怀疑是维保之前，这个M值一直是置on的，重要不断电，程序就继续。甚至维保前，就有安全隐患在，只是没发生事故。断电维保后m不再保持，导致故障出现。

一个事物都有两方面

楼主的个人能力在一个管理十分混乱的环境中得到了锻炼，乱世出英雄的话是有道理的。

所有的故事，其实就是源于缺少一条设备维护程序修改的记录