生产线的停机时间是很宝贵的，设备的维护人员往往在停机之前就已经做好设备维护计划，根据每一天、每一周或每个月停机时间的长短，制定不同的维护计划。

         我们的工厂是食品饮料行业，每天都要对生产设备进行一次小的清洗，以保证食品清洁卫生的要求。那天停机清洗时，我的任务是对在线的一台检测设备增加一些新功能，调试更新程序。更新的程序其实在一周前就已写好了，就等停机调试了，我早早地就守在机器旁边，等待一天的生产结束。本以为只要下载更新程序，一切就按照预想的运行的，结果，下载了更新程序，只运行了一会，PLC的“stop”灯就亮起了，赶紧查看PLC的模块消息，提示“编程错误，数据长度超出”，打开相应的块，一时间真是检查不出哪里导致的出错，现场停机时间不容许反复推敲，只好恢复原版程序，结束调试。

         回到办公室，再打开程序，忽然想到：何不利用仿真重现故障？立即将更新程序下载到仿真，将外部触发器逐个触发，终于找到编程错误的地方，原来数组编号0-9，我编程时习惯地用1-10的序号了，改回来再仿真，PLC没有再停机。

          西门子的仿真功能确实很强大，不仅能仿真PLC，而且可以HMI和PLC同时仿真，有了刚才的教训，我想顺便把更新的触摸屏也一起仿真一下，结果检查到新增的报警居然不能正常显示！什么情况，连报警都不会用了？还不如一个新手吗？信心是真受打击啊！找来以前做好的项目，对比一下报警功能，没错啊！都是按照常规编写的。郁闷中……

         一个上午就在思虑中度过，直到中午吃完午饭，看见外面温暖的阳光，突然想到：会不会是报警事件持续时间太短啊？（这个项目报警事件只持续20ms时间）

         再次回到办公室，打开仿真，将报警事件的持续时间设到3000ms，OK！报警视图能正常显示报警了。原来报警触发变量一般默认采样时间为“1s，采集模式—循环连续”，我试着将报警触发变量采样时间为“100ms”，将报警事件的持续时间设到200ms，报警视图也能正常显示报警条目，但这个时间相对于原来的20ms太长了，不能满足现场要求，而且发现报警视图中不仅显示报警条目“激活”状态，也会同时显示报警条目的“激活/取消”状态，而我只需要“激活”状态。看来，我只好及早放弃用报警来记录事件消息了，赶紧用系统时间自己写一个记录了。

         上面的两个问题其实都是可以利用仿真就能及早发现的，只怪自己不够勤快啊！