报警块所实现的功能与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。

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

我觉得你有些跑偏了。

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

第一,这种方法可能容易把一些存储区给清零...其实我也想过可能会一下清楚不用的地方,但回过头来想了想for已经限制住它了也没必要再去判断这个.....第二我这个下标应该是从1就好了....第三.并不觉得我这个易用性差呀,,,M  DB都可以去处理. 楼主那个只能是针对DB如果M区呢,就得改程序吧,?..       

  博图我在使用的时候如果对.%X0 的方式来访问的时候交叉引用用起来特别不方便...要点整个字然后再点分的.%X 找起来特别不方便(不能像点普通变量的时候,是你点这个的时候交叉信息就出来)....  之前看的你的思路是数组的方式...也是这么来的,,,,,又不想大改程序,,只能是把字传给数组...然后调用块就好了......但今天看楼主这个方式来了灵感.....当然还有不可取的地方比如复位的地方.....如果说针对每个报警有一个位来控制...那么就可以在wincc消息控件上做对报警的确认,及其它操作...但后来想想也没必要这么麻烦,,,,,,用这种思路,,,纯粹是为了让现场的报警灯响,,,,,不可能说每个报警来个上升沿,那得累死.....

还没有仔细看楼主的程序，第一感觉是怎么传一个报警信号就需要三个输入信息呢？

而且是关于地址的信息，我个人不觉得这样更好。

我们设计中关注的是这个信号需不需要作为报警，如何传递，而不是浪费在这个信号传递时地址到底是什么？

-----------------

打开这个帖子就临时有事，现在发帖没有注意的版主已经回帖。

是呀，我用300就特烦DB编号了，楼主你还来搞编号，你太厉害了，佩服。

不错学习了

仔细读了楼主的程序，谢谢分享。

把外部（DB)存放的一块连续区域的报警信号交由该FB处理，只为了得到是否该点灯和拉响警铃吗？

那么你连续存放的报警信号又是如何产生的呢？

不如直接放到该FB中去不好吗？

所以我觉得使用绝对地址的peek其实大可不必。

1. 突然想起来，做这个功能块的基本意义了，由于我公司使用的HMI较多不全是SIEMENS(MCGS,威纶)，所以导致我在使用报警块的时候只能是绝对地址，这是无奈之举。不知道是否有别的更好的方式来处理此问题；

   由于入行时我们的报警DB块一直时这样做的，我无法知道是否还有更好的方式去实现这些功能，so...；

   
   

   所以说一个人的学识，决定他所站的高度，然而我站在金字塔底端还不自知；

   
   

2. 基于我的报警制作习惯而言，我所有报警都是采用置位指令，所以无法去判断当前这个位是否是真正的在报警；

   不用置位的话做历史报警又显得有点鸡肋，至少西门子 HMI 的历史报警是要掏钱买卡的,当然也可以在报警组态中将报警组改为Error，这样报警必须要确认才会消除；

3. 我在WinCC PRO 中测试使用Word数组，博图会提示错误，不知是否是我打开的方式不对；

4. PEEK指令是不好判断，关于访问越界的问题，不知版主大大是否能够给一点建议；

5. 额，基于各位大佬提出的建议我将修改此程序；

6. 站在巨人肩膀上学习还是比较轻松的，谢谢各位大佬的指正；

谢谢分享，学习了。

谢谢分享！

果然高手在民间，非常感谢分享~~

既然报警消除后报警声和报警灯自动消灭，为什么还要加这个报警复位的输入信号啊，还有报警复位控制信号？这个作用是什么啊？没理解，希望楼主帮忙解释一下@iZhouSai 。

第一对于连锁故障,需要人为的确认故障发生过,,所以要加上手动去复位掉它,这是最重要的..最主要的原因.

第二,可能一些设备坏掉了,连锁可以解除,但不能让报警灯一直响吧?这样太吵了..(故障恢复比较长)