报警块所实现的功能与Zane版主的功能类似，但是更加贴近于我个人的使用习惯；

1.有报警灯亮，有新报警声响，消音后声灭，报警不除灯不灭，报警消除灯自动灭，声自动灭

2.报警的数据的获取，采用 PEEK_BYTE 指令，可以不需要在FB块中修改数组的长度，使能够读到的区域更加广泛，DB，I，Q，M均可使用。

3.Zane版主 功能块静态变量ALARM_OP数组，是可以在 HMI中使用的，但是到了WinCC就不好使了，因为WinCC不支持报警变量是一个数组；

4.INPUT 接口中

      DBNumber : 等同于 PEEK指令中的 DBNUMBER；

      Area : 等同于 PEEK指令中的 AREA；

      Length :为报警区域的长度，但是要减去一；

            例如：一个DB块的报警变量地址为0.0~5.7则Length的值等于5

    特别注意报警区域的长度必须为Byte的整倍数；

    PEEK指令的使用可以参照 TIA Portal 帮助系统；

6.在此还是顺带提一下我做报警的一些观念；

    我做报警的时候一般分为三个DB块，

    DB1127为警告，当设备发生一些不影响设备运行的警告（例如温度过高），或者某个设备启动时的联锁条件不满足时产生的报警。此时黄灯会闪烁。

    DB1128为错误，当某些设备发生停机时，但是又不影响整线停机的报警。例如一个变频电机的散热风扇热继跳闸了。此报警会引起红灯闪烁。

    DB1129为故障，当某些设备发生故障会引起整线停机的故障。例如变频通讯故障；此报警会引起红灯常亮。

7.送上代码，复制粘贴的代码会有关键字被屏蔽，现在上传源文件；

30004.pdf

30004.报警过程.zip

2021年06月13日

8.送上改版后的Word程序，但是我怎么觉得还是Byte好！中间省略若干心路历程；具体看代码这里面有几个坑；

30004.报警过程 Word 版本.pdf

9.回答某位网友的问题 ：FOR循环是在一个扫描周期内执行完毕的，so...!

       感谢分享！一般而言一个小项目都有几百上千种报警要做；一个安全，规范，清晰，全面，人机交互良好，软硬件逻辑完备的报警系统做好了一个项目就结尾了，成功了；我还是更倾向版主以前的版本；实用而言对于报警的类型，等级，时序等的信息的规划可能还要更细致，细致到考虑任何情况，估计一个结构体数组不一定能搞定。

建议，报警区域的长度还是以字为单位

建议用字,,,你都说了不支持数组,,,用个swap做个转换,,,,,转换完再用poke填充到某个区域关联wincc好了...

还有总觉得这个复位不够严谨....只能是当前字节给复位了....可能按下去的时候经过了好几个循环....但我觉得按下去用个循环全部复位不好吗/??或许你有其它想法说出来看看,,,

Alarm1A0.pdf

你这个还不够完整,,,只能是从0开始,,,,不够灵活...没能完全发挥PEEK指令.....至于你说的浪费循环我倒不觉得....不在乎....

讲点编程细节的问题：

这个数组是奇数字节的，0~128 ，128字节应该是0~127或1~128，可能会导致HMI的访问出错，如果以字为单位就不存在上述问题。

还有，输入变量LENGTH的初始值为0，不合理，有违人的通常认知，应该是一个大于1的数，至于与循环次数的关系其实是很容易处理的。

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

首先，关于变量的间址访问，楼主采用的是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。

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

我觉得你有些跑偏了。

改的都是些无关紧要的东西，程序的易用性更差了。