很高兴，我的程序能有网友做出积极的响应，能有不同的想法和观点无论对错我觉得都是正常的，我希望大家看了楼主的程序后能有一些思考，各方面的。

首先，关于变量的间址访问，楼主采用的是POKE/PEEK指令，而我采用的是数组寻址方式，那么差别在于楼主的方式只能使用SCL编程，并且只能是非优化访问，而我的方案是LAD/SCL通用，优化数据访问与非优化数据访问均可。

其次，楼主的变量基本单位是字节，而我变量基本单位是字，对于西门子的触摸屏，WINCC ADV RT来说无论是否数据优化访问均是支持的，WINCC PRO RT我不清楚V7.5怎么样，至少博途版的肯定没问题，传统版前面的版本非优化也是支持的，对于第三方的触摸屏与组态软件来说，也是大多数支持以字为单位的报警变量的，只是注意顺序即可。那么同样的报警数量，以字为单位的处理次数是以字节为单位的处理次数的一半，当然处理速度也会快一倍。当然也会有人说为啥不用双字呢，这不是用的次数更少速度更快吗？为啥不用？有得有舍，大家自己可以体会一下。

第三，我认为报警集中管理程序的ALARM_OP与ALARM_BUF应该是配套存在的，所以在我的程序中ALARM，ALM，ALARM_OP，ALARM_BUF的数据长度都是一样的，结构变量作为输入确保了功能块调用时输入变量的正确性；而楼主的程序，看似灵活，但存在很多出错的可能性，比如长度输入不小心超过了BUF数组的长度，这个还要人为的去确认，是不是有些不方便？DBNUMBER变量与实际的DB块是没有联系的，也存在输错的可能性，更改DB块后，还是要人工确认并同步修改DBNUMBER，如果遗漏，系统编译是不会检查出错误来的。还有程序简单的话，我的程序直接调用功能块即可，管脚可以不输入，楼主的程序不行，是不是又是一点不方便呢？

第四，我的程序开发的初衷是一个报警的集中管理程序，报警的产生是由控制对象的逻辑产生的，同样报警的消除也是由控制对象的逻辑来控制的，与报警集中管理程序无关，所以我的程序并没有清楚报警标志位的执行逻辑，最多就是发出一个总的复位指令而已。我认为，楼主比较暴力地把报警标志位统一清零，是否能够起到作用？会不会重复触发?按住复位按钮是不是就不报警了？

第五，看了我的程序，我想应该不会再有人去用I/Q/M做报警的标志位了，唯一的选择DB。

暂时说这些吧，欢迎拍砖！