还是说更换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
如果对这个程序的修改有什么意见的朋友,也不妨一起讨论讨论!!