S7-400程序丢失的教训

一台S7-400 PLC，在使用过程中出现网络故障，经过多次检查仍不能排除故障，维修人员就对PLC进行重新启动。

到现场后，发现CPU处于运行状态后，有一块CP443通讯卡始终处于STOP状态，且有一个子站连接不到DP网络上。后用编程器上载程序来检查，发现该子站DP地址不对，同时组态的硬件也不一样，发现运行的程序不是最终的程序了。检查S7 400PLC电池，两颗电池没有报警，且开关在1位置，排除电池弱造成程序丢失的可能，怀疑维修人员在处理过程中有人不小心将PLC的开关拨到了MRES，悲剧就这样发生了。

原来，该设备前一段时间进行了搬迁改造，增加了一块CP443通讯卡，硬件组态和程序进行了修改，但改造过程中，对最新程序没有进行写卡工作，造成存储卡里面的程序还是未搬迁前的程序，不能和整线设备通讯，设备联动运行不起来了。

找源程序来重新下载，但厂家提供给我们的程序通过S7编程软件打不开，再联系厂家，厂家备份的程序他们也打不开，厂家再找，找到一个原程序，传下去，设备能正常启动了，但PID调控参数不能修改数据，再检查，发现不是最终程序，操作屏上PID参数对应的数据块不是使用的数据块。此时，已经10个小时过去了，为保证生产，只好通过编程器按照原来记录的操作屏上PID参数硬写入数据块中，设备正常运行了。

设备运行起来了，只是每更改一个牌号，都需要对参数进行修改，但只要设备能正常运行起来，压力就小多了，再检查原来打不开的程序，发现缺少一个s7link，添加一个s7链接后可以打开了，但打开来检查，发现也不是最终的程序，厂家原来调试的技术人员变动，最新程序也找不着了，该设备还处于维保阶段，只好重新再来修改程序。

细节决定成败，该问题反映出几个没有做好的细节来：

一是该最终原程序厂家调试完成后没有进行写存储卡工作；

二是我们在使用过程中没有做好程序的备份工作；

三是我们的维修人员认识和经验不足，找不出故障就用复位的办法，而不是通过监控等查找最终原因。

四是生产厂家没有保存好最终源程序，造成最终源程序丢失。

这一看似不会发生的事情，就这样在几个环节只要做好其中任何一个细节就不会发生的情况下发生了。

实在值得总结了。