作者 | 主题 |
---|---|
威师爷 至圣 经验值:37384 发帖数:5126 精华帖:47 |
楼主 2019-01-22 21:14:50
主题:程序BUG 的尴尬 还是说更换CPU的事情,一个运行了10年的老项目,由于CPU容量不足,需要更换一个性能更好的CPU,于是按照平常一样去操作,在线备份,备份好程序以后就操刀更换硬件。。。 接下来尴尬的事情就这样发生了,更换好CPU以后把备份的操作下载回去以后CPU出现SF故障,同时不能进入RUN模式,这个时候想应该是组态不对,确认了一下组态信息,没有问题,然后进入诊断缓冲区参考模块信息,出现信息说编程错误,这个时候发现事情不妙了,难道备份的程序有问题?打开备份的程序的DB块,大部分实际值都是 0 0 0 0 0 一大堆可怕的 0 于是找出前两年备份的程序,打开以后 发现前两年备份的程序很多DB都是有数据的,不像这次一样都是0 于是没有考虑那么多了,把以前备份的程序的DB下载到CPU,这个时候CPU还是不能进入RUN状态,还是提示编程错误,但是这次不同的是故障范围变小了,并且指向了FC909的功能块 这下子就好办了,先通过给CPU下载一个OB121 让CPU进入RUN状态,发现设备的所有功能都是可以正常运行的,说明问题只有一个了 那就是FC909 (这个是一个故障位检查的块,在系统出现故障时激活故障位输出的)接下来开足马力检查这个功能块到底是什么原因让他进入了STOP状态,通过检查发现是一个地址指针 出现了错误导致指向一个不存在的地址,导致出现编程错误故障。 这个时候还是不敢相信,正常运行了10年的程序居然会存在BUG?这个时候我还是告诉自己可能是我的判断有误,可能程序没有BUG,于是查来查去发现有一个地址指针 使用了TEMP ,没有初始化 直接就进行使用了,感觉这个地方不对,后来在程序开始时进行了初始化以后 程序正常了,同时在线把OB121删除掉,程序也可以正常的运行了。 这个问题主要是告诉大家,任何问题都可能会发生,运行了10年的程序又如何?该出现BUG时还是会出现。。。所以作为工程设计人员必须谨慎再谨慎。。。。 下面我就把这次有BUG的程序发上来 ,修改前的 修改以后的 都发上来: FC909的接口 这个是有BUG的程序: 有BUG的程序(FC909) 程序段1 L #datablock T #datablock1 L 0 T #TestBYTE AN #Reset JC byte SET R #Active 程序段2 byte: L 0 LAR1 L #Offset SLD 3 +AR1 OPN DB [#datablock1] L DBB [AR1,P#0.0] T #AlarmBYTE L 0 T #TestBYTE 程序段3 L #AlarmBYTE // exclusive OR of current and previous alarm word L #TestBYTE XOW T #TEMP L #TEMP // changes found L 0 ==I JC ok SET S #Active 程序段4 ok: NOP 0 L #Offset // Add offset by one L 1 +I T #Offset
L #Offset // Check offset L #Bytes >=I BEC JU byte 修改以后的程序如下: 程序段1 L #datablock T #datablock1 L 0 T #TestBYTE T #Offset //在这个位置增加了指针的初始化程序以后出现能够实现目的正常运行 AN #Reset JC byte SET R #Active 程序段2 byte: L 0 LAR1 L #Offset SLD 3 +AR1 OPN DB [#datablock1] L DBB [AR1,P#0.0] T #AlarmBYTE L 0 T #TestBYTE 程序段3 L #AlarmBYTE // exclusive OR of current and previous alarm word L #TestBYTE XOW T #TEMP L #TEMP // changes found L 0 ==I JC ok SET S #Active 程序段4 ok: NOP 0 L #Offset // Add offset by one L 1 +I T #Offset
L #Offset // Check offset L #Bytes >=I BEC JU byte 如果对这个程序的修改有什么意见的朋友,也不妨一起讨论讨论!!
工业起重机防摇摆 QQ:404136820 AntiSwayControl
|
Zane 版主 经验值:75765 发帖数:19245 精华帖:376 |
5楼 2019-01-22 23:25:24
主题:回复:程序BUG 的尴尬 哈哈,谈不上帮忙。 大致看了一下程序的,故障信息是数据块寻址出错,因此肯定是指针出问题了,再看程序关于指针定义的指令只有这几句: byte: L 0 LAR1 L #Offset SLD 3 +AR1 主变量#Offset是个临时变量,而且没有初始化过,应该是0,但出错的原因就是调用时#Offset里已经有值了,而且值还大于变量#bytes的值,第一次指针计算就是超范围的。 这个故障看起来比较蹊跷的,分析下来可能还是FC的工作机制的变化,即是否对临时变量的寄存器自动清零了。
Zane
注册自动化系统工程师
Always save before download
|
Zane 版主 经验值:75765 发帖数:19245 精华帖:376 |
16楼 2019-01-23 22:10:06
主题:回复:程序BUG 的尴尬 事出蹊跷必有妖。 楼主的这个事件给我们展现了两个方向的问题: 其一,就是前面讲的指针运算出错导致CPU故障,这个问题楼主通过增加初始化的指令予以解决了。 其二,这个程序上载上来肯定是没有#offset指针的初始化指令的,如果说编程软件的问题导致的,我觉得可能性是比较小的,如果是这样,喜欢上载备份的朋友们可是要小心了,(我只下载不上载体会不到,指做项目开发,维护是另一回事了),但似乎这样的事情很少发生,至少论坛这么多年这是头一遭遇见。 但这个带着BUG的或者说不严谨的程序居然工作了10多年了而且啥事儿没有(楼主的描述,我想楼主也不会骗我们的),这么多年没断过电?没重启过?只要有一次就会出问题呀! 解决楼主的当务之急,我觉得这些都是小事儿,但这另一个方向的问题却值得我们去探讨和深入地研究一下。这个有问题的程序为什么能正常工作?在楼主更换CPU前工作程序是如何初始化#OFFSET这个临时变量的。 楼主在微信里贴过程序,我记得有两次调用FC909(论坛里的程序看不到了),我怀疑原程序内有一次调用是被禁止了,即调用的条件被强制不满足了,如下图: 但就楼主贴出的程序清单分析倒也不是,这是个无论如何应该出问题的程序呀,如何可以坚持10年正常工作? 所以,我想到是不是新CPU固件系统支持的功能块对临时变量的处理机制发生了变化
Zane
注册自动化系统工程师
Always save before download
|
威师爷 至圣 经验值:37384 发帖数:5126 精华帖:47 |
17楼 2019-01-23 22:22:28
主题:回复:程序BUG 的尴尬 Z版! 首先这个程序过程中肯定有断电的情况,其他的就不多说,就这次更换CPU之前一天我们就进行过断电的操作,上电以后同样正常运行。不可能10年没有断过电的。 首先这个事情绝对是一个活生生的事实。不可能是无中生有!!同时我也把这个我认为的BUG反馈给了开发人员,目前还没有得到回复。。。。得到回复以后必定把回复内容发出来让大家看看的。。。 我现在唯一能够想到的是会不会是CPU版本升级以后导致一些数据发生了变化这个原因。 就如Z版说的那样。。。
工业起重机防摇摆 QQ:404136820 AntiSwayControl
|
威师爷 至圣 经验值:37384 发帖数:5126 精华帖:47 |
18楼 2019-01-23 22:28:35
主题:回复:程序BUG 的尴尬 的确是对FC909有两次的调用,不过其中一个调用是强制了,没有任何意义的,这次出现故障以后我直接//掉了,注释掉以后重启CPU还是一样的问题,为了不影响大家的判断,我只截图了有用的调用部分发出来。。。 无论如何,TEMP 没有初始化就进行了调用这个目前大家也是认为有问题的。就这一条就可以作为程序BUG的判断依据了吧??
工业起重机防摇摆 QQ:404136820 AntiSwayControl
|
volcanol 侠圣 经验值:4939 发帖数:790 精华帖:12 |
22楼 2019-01-24 09:07:33
主题:回复:程序BUG 的尴尬 我也遇到过一个因为Local变量没有初始化的问题,当时不知道,还是德国西门子设计的程序。只要程序运行起来后不会有问题。 但是当重新下载的时候,因为没有给出初始化的值,所以导致下载后检测通讯错误的时候为0了,导致报错停机。也是无语了。 很多时候程序就算跑了十几年有些非常微妙而妖孽的故障也是会存在的。 只能说明以前的编写程序的人没有真正的理解C语言的本质。 对于C语言的变量来说必须要初始化,否则就很容易game over。 话说Step 7 从本质上来说是一个C语言的编译器。
获取资料关注:https://www.cnblogs.com/volcanol/
|