Codesys 3.5报警功能实战：REF与ACK机制详解及避坑指南

1. 为什么报警功能值得单独拿出来讲在Codesys 3.5里做报警很多人的第一反应是“不就是拉个报警块、绑个变量吗”。真到项目上你会发现事情远没有这么简单报警触发条件写错了设备停了报警却不来报警确认按钮按下去报警消失了但故障还在REF和ACK两个引脚到底谁先谁后手册上写得云里雾里现场调试时只能靠试。我自己第一次在Codesys里做报警是在一条包装线上当时用的是基础的报警功能块变量定义没做规范结果报警文本显示的是“Alarm_1”“Alarm_2”操作工根本不知道发生了什么。后来重新梳理了变量命名和报警配置才把这个问题解决掉。从那以后我养成了一个习惯报警相关的变量定义、触发逻辑、确认方式必须在项目初期就规划好不能等到现场再补。这篇内容适合两类人看一类是刚接触Codesys 3.5、需要快速把报警功能跑起来的工程师另一类是用过报警功能但总觉得“哪里不对劲”、想搞清楚REF和ACK底层逻辑的老手。我会从变量定义开始一步步讲到报警组态、REF和ACK的区别、确认方式的实现最后附上我实际项目中踩过的坑和排查方法。所有操作基于Codesys 3.5 SP以上版本不同版本菜单可能略有差异但核心逻辑一致。2. 报警功能整体设计与变量定义思路2.1 报警系统的三层结构在Codesys里做报警本质上是在做三件事检测异常、记录异常、响应异常。这三件事对应到工程实现上就是三层结构。最底层是变量层也就是你的报警触发变量。这个变量可能是一个布尔量比如电机过载信号也可能是一个模拟量比较结果比如温度超过80度。变量层的核心任务是“准确反映设备状态”不能有误报也不能漏报。中间层是报警配置层在Codesys的报警组态里定义报警的文本、类别、优先级、触发条件。这一层决定了报警怎么显示、怎么分类、怎么记录。最上层是报警交互层也就是操作员看到的报警列表、确认按钮、复位按钮。这一层决定了操作员怎么响应报警。三层结构听起来简单但实际项目里最容易出问题的就是变量层。我见过太多项目报警变量直接用一个M点或者Q点没有做防抖处理结果设备震动一下报警就闪一下操作员根本来不及看。2.2 变量定义的核心原则在Codesys里定义报警变量我总结了几条原则都是实际项目里验证过的。第一条报警变量必须独立命名不能复用控制变量。比如你有一个电机启动信号Motor_Start不要直接用这个信号的反状态作为报警触发。应该单独定义一个Motor_Fault变量在逻辑里把过载、短路、超时等条件综合进去。这样做的好处是报警逻辑和控制逻辑解耦后期改报警条件不会影响控制。第二条报警变量要加防抖。物理信号都有抖动特别是接近开关、限位开关这类传感器。我通常会在报警变量后面加一个TON延时比如200ms确认信号稳定后再触发报警。Codesys里可以用TON功能块实现也可以用报警组态里的“延迟时间”参数。第三条报警变量要区分“瞬时报警”和“持续报警”。瞬时报警是故障出现一下马上消失比如急停按钮被误碰持续报警是故障一直存在比如电机过载。这两种报警的处理方式不同瞬时报警通常只需要记录持续报警需要操作员确认并处理。第四条报警变量要分组。一条产线上可能有几十个报警如果不分组操作员看到的就是一长串列表。我通常按设备单元分组比如“上料单元”“加工单元”“下料单元”每个单元下的报警再按优先级排序。2.3 变量定义的具体操作在Codesys里定义报警变量有两种方式一种是在PLC变量表里直接定义另一种是在报警组态里关联变量。我推荐的做法是先在PLC变量表里定义好所有报警变量命名规则统一为Alarm_设备_故障类型比如Alarm_Feeder_Overload、Alarm_Cutter_Jam。变量类型用BOOL初始值FALSE。然后在报警组态里通过“变量”列关联这些变量。这里有一个细节Codesys的报警组态支持“表达式”触发也就是说你可以不定义单独的报警变量直接在报警组态里写表达式比如Motor_Current 10.0。这种方式看起来省事但我不推荐。原因是表达式写在报警组态里后期维护时很难找到而且没法在PLC代码里复用。还是老老实实定义变量在代码里赋值报警组态只负责显示。变量定义完成后建议在变量表里加一列注释写清楚这个报警的触发条件和处理建议。这个注释不会显示在HMI上但对你后期维护非常有帮助。我现在的项目里每个报警变量都有注释比如“电机电流超过额定值110%持续3秒触发检查负载或变频器参数”。3. 报警组态配置与REF/ACK核心机制3.1 报警组态的创建步骤在Codesys 3.5里创建报警组态操作路径是右键点击Application - 添加对象 - 报警配置。创建完成后你会看到一个表格每一行代表一个报警。表格里几个关键列需要填写变量关联你之前定义的报警变量比如Alarm_Feeder_Overload。报警文本显示给操作员看的文字比如“上料单元电机过载”。报警类别Codesys默认有“错误”“警告”“信息”三类你也可以自定义。类别决定了报警的颜色和优先级。报警优先级数值越大优先级越高高优先级报警会排在列表前面。触发类型可以选择“上升沿”“下降沿”“电平”。大部分报警用“上升沿”也就是变量从FALSE变TRUE时触发。这里有一个容易忽略的参数确认方式。Codesys支持三种确认方式无确认、确认后消失、确认后保留。这个参数直接决定了REF和ACK的行为后面会详细讲。3.2 REF和ACK到底是什么REF和ACK是Codesys报警功能块上的两个输入引脚很多人搞不清楚它们的区别。我用一个生活化的类比来解释。想象你家里有一个烟雾报警器。烟雾报警器响了这是报警触发。你走到报警器前面按了一下“静音”按钮报警器不响了但烟雾还在这是ACK确认。你把窗户打开烟雾散了报警器彻底恢复正常这是REF复位。对应到Codesys里ACK操作员确认报警。确认后报警从“未确认”状态变为“已确认”状态。如果报警条件还在报警仍然存在但不再闪烁或发出声音。REF报警条件消失后复位报警状态。复位后报警从报警列表中移除。关键区别ACK是操作员主动做的REF是系统自动做的当触发条件消失时。ACK解决的是“操作员知道了”REF解决的是“故障没了”。在实际项目中这两个信号通常来自HMI上的两个按钮“确认”按钮触发ACK“复位”按钮触发REF。但要注意不是所有报警都需要REF。有些报警只需要确认不需要复位比如“参数已修改”这类信息报警。3.3 报警功能块的引脚详解Codesys里常用的报警功能块是Alarm和Alarm_2。以Alarm为例主要引脚如下引脚类型说明INBOOL报警触发条件TRUE时触发报警ACKBOOL确认信号上升沿有效REFBOOL复位信号上升沿有效ACTBOOL输出报警当前是否激活ACKEDBOOL输出报警是否已确认ERRBOOL输出报警是否处于错误状态这里有一个细节ACK和REF都是上升沿有效也就是说你按住按钮不放只会确认一次。这个设计是为了防止误操作但也意味着如果你用HMI上的按钮需要确保按钮是“点动”模式而不是“保持”模式。还有一个容易踩的坑REF信号必须在报警条件消失后才能生效。如果报警条件还在你给REF信号报警不会复位。这个逻辑是合理的但现场调试时经常有人搞错以为按了复位按钮报警就应该消失。3.4 报警类别的配置技巧Codesys的报警类别不只是颜色区分还影响报警的确认方式。在报警配置里你可以为每个类别设置默认的确认方式。我通常这样配置错误类确认后保留。操作员确认后报警仍然显示在列表里直到故障排除并复位。这类报警通常是设备故障需要跟踪处理。警告类确认后消失。操作员确认后报警从列表里移除。这类报警通常是参数超限操作员知道就行。信息类无确认。报警自动显示和消失不需要操作员干预。这类报警通常是状态提示。这个配置需要在报警组态的“类别”设置里提前定义好然后在每个报警行里选择对应的类别。如果项目后期要改确认方式改类别设置就行不用一个个改报警行。4. 实操过程与核心环节实现4.1 从零搭建一个报警功能的完整流程我以一个实际项目为例演示从变量定义到报警确认的完整流程。项目背景一条传送带需要监测电机过载和跑偏两个故障。第一步定义报警变量。在PLC变量表里添加两个变量VAR_GLOBAL Alarm_Conveyor_Overload : BOOL : FALSE; (* 传送带电机过载 *) Alarm_Conveyor_Misalign : BOOL : FALSE; (* 传送带跑偏 *) END_VAR第二步编写报警触发逻辑。在PLC_PRG里写逻辑用TON做防抖VAR OverloadRaw : BOOL; (* 过载原始信号 *) MisalignRaw : BOOL; (* 跑偏原始信号 *) TON_Overload : TON; (* 过载防抖定时器 *) TON_Misalign : TON; (* 跑偏防抖定时器 *) END_VAR (* 过载检测电流大于10A持续2秒 *) OverloadRaw : Motor_Current 10.0; TON_Overload(IN : OverloadRaw, PT : T#2S); Alarm_Conveyor_Overload : TON_Overload.Q; (* 跑偏检测跑偏开关触发持续1秒 *) MisalignRaw : Misalign_Switch; TON_Misalign(IN : MisalignRaw, PT : T#1S); Alarm_Conveyor_Misalign : TON_Misalign.Q;第三步创建报警组态。在Application下添加报警配置添加两行报警变量报警文本类别优先级触发类型确认方式Alarm_Conveyor_Overload传送带电机过载错误10上升沿确认后保留Alarm_Conveyor_Misalign传送带跑偏错误8上升沿确认后保留第四步在HMI上绑定报警显示和确认按钮。在HMI里添加报警显示控件关联报警组态。添加两个按钮“确认”和“复位”分别绑定到报警功能块的ACK和REF引脚。第五步编写报警功能块调用。在PLC_PRG里调用报警功能块VAR Alarm_Overload : Alarm; Alarm_Misalign : Alarm; HMI_Ack : BOOL; (* HMI确认按钮 *) HMI_Ref : BOOL; (* HMI复位按钮 *) END_VAR Alarm_Overload(IN : Alarm_Conveyor_Overload, ACK : HMI_Ack, REF : HMI_Ref); Alarm_Misalign(IN : Alarm_Conveyor_Misalign, ACK : HMI_Ack, REF : HMI_Ref);这里注意HMI_Ack和HMI_Ref是两个全局变量HMI上的按钮直接写这两个变量。按钮配置为“点动”模式按下时变量为TRUE松开为FALSE。4.2 参数计算与选择过程防抖时间怎么定这个没有标准答案要根据实际工况来。我的经验是机械开关类信号防抖时间100-200ms。机械开关抖动时间通常在10-50ms100ms足够。模拟量比较类信号防抖时间1-3秒。模拟量本身有波动太短会误报太长会漏报。通信类信号防抖时间3-5秒。通信中断可能是瞬时的需要确认是真的断了。以传送带过载为例电机电流在启动瞬间会有一个冲击可能达到额定值的2-3倍但持续时间很短。如果你不防抖每次启动都会报过载。我设置2秒防抖启动冲击通常在1秒内结束不会触发报警。报警优先级怎么定我通常按“安全 设备 工艺 信息”的顺序排。安全相关的报警优先级最高比如急停、安全门设备故障次之比如电机过载工艺参数超限再次之比如温度偏高信息类最低比如“自动模式运行中”。4.3 报警确认方式的实现细节Codesys的报警确认方式有三种我在项目里都用过说一下各自的适用场景。无确认报警触发后自动显示条件消失后自动消失。适合信息类报警比如“设备运行中”“等待物料”。这类报警不需要操作员干预显示出来只是让操作员知道当前状态。确认后消失报警触发后显示操作员确认后消失不管条件是否还在。适合警告类报警比如“温度偏高”“压力偏低”。操作员确认表示“我知道了”报警消失后如果条件还在不会再次触发除非条件先消失再出现。确认后保留报警触发后显示操作员确认后仍然显示直到条件消失并复位。适合错误类报警比如“电机过载”“通信中断”。这类报警需要操作员确认并处理处理完成后复位。这里有一个细节确认后保留的报警REF信号必须在条件消失后才能生效。如果你在条件还在的时候给REF信号报警不会复位。这个逻辑在Codesys手册里没有明确写是我实际调试时发现的。还有一个细节多个报警共用一个ACK信号时确认操作会同时确认所有未确认的报警。这个行为在大多数场景下是合理的但如果你希望操作员逐个确认就需要为每个报警单独做确认按钮。我通常的做法是同一设备的报警共用一个确认按钮不同设备的报警分开。5. 常见问题与排查技巧实录5.1 报警不触发或误触发这是最常见的问题排查思路如下现象可能原因排查方法解决方法报警完全不触发变量未关联检查报警组态里的变量列是否填写重新关联变量报警完全不触发触发类型错误检查触发类型是上升沿还是电平改为上升沿报警频繁误触发未做防抖用Trace功能监控变量波形加TON防抖报警频繁误触发变量被多次赋值检查PLC代码里是否有多个地方写同一个变量统一赋值点报警触发后不消失确认方式设置错误检查报警的确认方式改为确认后消失报警触发后不消失REF信号未生效检查REF信号是否在条件消失后给出调整REF逻辑我遇到过一个典型案例报警变量在PLC代码里被写了两次一次在自动模式一次在手动模式两个地方的逻辑不一致导致报警状态混乱。后来改成只在报警检测功能块里写一次问题解决。5.2 REF和ACK的时序问题REF和ACK的时序是调试时最容易搞混的地方。我用一个时序图来说明文字描述假设报警条件在t1时刻出现操作员在t2时刻按下确认按钮报警条件在t3时刻消失操作员在t4时刻按下复位按钮。t1报警触发ACT输出TRUEACKED输出FALSE。t2ACK信号上升沿ACKED输出TRUEACT仍然TRUE。t3报警条件消失ACT输出FALSE但报警仍然在列表中因为确认后保留。t4REF信号上升沿报警从列表中移除。如果操作员在t3之前按下复位按钮t2.5时刻REF信号不会生效因为报警条件还在。这个逻辑是合理的但现场调试时经常有人在这里卡住。我的建议是在HMI上把“确认”和“复位”按钮分开确认按钮随时可以按复位按钮只在报警条件消失后才允许按。可以在HMI上做一个使能逻辑当所有报警的ACT输出都为FALSE时复位按钮才使能。5.3 报警文本显示乱码或不显示这个问题通常和编码有关。Codesys的报警文本支持中文但需要在报警组态里设置正确的字体和编码。我遇到过报警文本在HMI上显示为“???”的情况原因是HMI的字体不支持中文。解决方法是在HMI项目里把报警显示控件的字体改为支持中文的字体比如“宋体”或“微软雅黑”。还有一个可能的原因是报警文本太长超出了显示控件的宽度。Codesys的报警文本可以设置“短文本”和“长文本”短文本用于列表显示长文本用于详情显示。我通常把短文本控制在20个字符以内长文本可以写详细一点。5.4 报警记录不保存Codesys的报警默认只在运行时显示断电后不保存。如果你需要保存报警记录需要在报警组态里启用“报警记录”功能并配置存储路径。存储路径可以是本地文件也可以是数据库。我通常用CSV文件存储报警记录配置简单后期用Excel就能分析。配置方法在报警组态的“记录”设置里选择“文件记录”设置文件路径和文件名格式。文件名格式可以用时间戳比如Alarm_%Y%m%d_%H%M%S.csv。这里有一个坑文件路径必须是Codesys运行时有权限写入的路径。如果你在Windows上运行路径可以是C:\AlarmLog\如果在Linux上运行路径需要是/var/log/alarm/之类的。路径不存在时Codesys不会自动创建需要你提前建好文件夹。5.5 独家避坑技巧技巧一报警变量加前缀。我所有的报警变量都以Alarm_开头这样在变量表里搜索Alarm_就能看到所有报警变量不会和控制变量混淆。技巧二报警文本用“设备现象建议”格式。比如“上料单元电机过载请检查负载或变频器参数”。操作员看到报警后知道发生了什么也知道该做什么。技巧三报警优先级用数字分段。0-3是信息类4-6是警告类7-9是错误类10以上是安全类。这样在报警列表里排序时高优先级报警自然排在前面。技巧四定期清理报警记录。报警记录文件会越来越大我通常设置一个定时任务每月清理一次超过3个月的记录。Codesys里可以用SysFile库实现文件操作。技巧五在HMI上做报警统计。除了报警列表我还会在HMI上做一个报警统计页面显示每个报警的触发次数和总持续时间。这个数据对设备维护非常有帮助能看出哪些故障最频繁。6. 报警功能的扩展与优化6.1 报警分组与过滤当报警数量超过20个时操作员在列表里找报警会很费劲。Codesys支持报警分组你可以按设备单元、报警类别、优先级等维度分组。在报警组态里每个报警行都有一个“组”列填写组名即可。我通常按设备单元分组比如“上料组”“加工组”“下料组”。在HMI上报警显示控件可以设置“按组显示”操作员点击组名就能过滤出该组的报警。6.2 报警抑制与屏蔽设备维护时某些报警会频繁触发比如你正在检修电机过载报警一直响。这时候需要报警抑制功能。Codesys支持在报警组态里设置“抑制变量”当抑制变量为TRUE时报警不触发。我通常为每个设备单元做一个抑制变量比如Suppress_Feeder。维护时在HMI上打开抑制开关该单元的报警全部屏蔽。维护完成后关闭抑制开关报警恢复正常。注意抑制变量只影响报警触发不影响报警记录。也就是说抑制期间的报警仍然会被记录只是不显示。这个设计是为了保留完整的报警历史。6.3 报警与PLCopen报警标准的对比Codesys的报警功能和PLCopen报警标准有一些差异。PLCopen标准里报警分为“报警”和“事件”两类报警需要确认事件不需要。Codesys的报警类别可以模拟这个行为但底层实现不同。如果你需要符合PLCopen标准的报警功能可以用Codesys的PLCopenAlarm库。这个库提供了更标准的报警功能块但配置比原生报警组态复杂。我的建议是如果项目没有强制要求PLCopen标准用原生报警组态就够了简单直接。6.4 报警功能的性能优化当报警数量很多时报警功能块的调用会占用PLC扫描时间。我做过测试100个报警功能块大约占用1-2ms扫描时间取决于PLC性能。如果报警数量超过200个建议做以下优化把报警功能块的调用放在单独的任务里设置较低的任务优先级。用Alarm_2功能块代替AlarmAlarm_2支持多个报警输入减少功能块调用次数。对于不需要确认的信息类报警直接用变量触发报警组态不调用报警功能块。我在一个项目里用了300多个报警通过任务分离和功能块优化扫描时间控制在3ms以内对整体性能没有明显影响。6.5 报警功能的测试方法报警功能上线前必须测试我通常分三步第一步单元测试。在PLC代码里强制报警变量为TRUE检查报警是否触发、文本是否正确、优先级是否生效。这一步在Codesys的仿真模式下就能做。第二步集成测试。连接实际HMI测试确认和复位按钮的功能。重点测试REF和ACK的时序确保确认后报警状态正确复位后报警消失。第三步压力测试。同时触发多个报警检查报警列表的排序和显示是否正常。测试报警记录功能确保记录文件正确生成。我遇到过一次压力测试时报警列表刷新卡顿的问题原因是HMI的报警显示控件设置了“自动滚动”报警太多时滚动频繁导致卡顿。后来改成“手动滚动”问题解决。7. 个人经验总结报警功能看起来简单但要做好需要关注很多细节。变量定义要规范防抖时间要合理确认方式要匹配报警类型REF和ACK的时序要搞清楚。这些细节在手册里不会写只有实际调试时才会遇到。我现在做项目报警功能一定在项目初期就规划好变量命名、分组、优先级、确认方式都提前定下来。后期改报警比前期规划麻烦十倍因为报警涉及PLC代码、报警组态、HMI显示三个地方改一处就要同步改另外两处。最后分享一个小技巧在报警组态里加一个“测试模式”变量当测试模式为TRUE时所有报警的防抖时间减半。这样调试时能快速验证报警逻辑不用等防抖时间。测试完成后关闭测试模式恢复正常防抖时间。这个技巧帮我省了不少调试时间。