PLC 报警复位逻辑

设备报警以后按复位，plc 到底应该清掉什么？这个是一直困扰我的问题，后来我总结出来总共仅三类东西。
・第一类是启动保持。比如操作员按了一下启动按钮，plc 把自动运行状态保持住了，设备报警以后启动保持应该清掉，否则故障一恢复，设备可能不需要重新按启动就自己接着动作。
・第二类是故障之前留下的操作请求。比如点动请求、单次运行请求、气缸伸出请求、是否移动请求以及还没有执行完的触发信号。这些命令都是故障之前发出的，设备已经停下来了，它们就不能继续留在程序里等故障恢复以后突然执行。
但是注意调气缸伸出请求不等于直接把所有电磁阀输出全部关闭，因为有些电磁阀一断电，气缸反而会立即收回。到底保持收回还是停止要由恢复程序根据现场情况来决定。
・第三类是已经消失在报警锁存。比如气缸伸出超时，如果气缸后来已经到位，故障条件也消失了，按下复位可以把报警锁层和本次超时状态清掉。但如果气缸还是没有到位报警，原因还在，按多少次复位都不应该把报警强行清掉。
所以复位通常清的是启动保持、点动请求、再次触发未完成的动作请求以及故障消失以后的报警所存。
为什么不能随便清？气缸的到位信号、是否轴的实际位置、面积的真实状态，这些是现场反馈，不能在程序里假装它们回到了初始产品配方、生产技术和追溯数据，也不能跟着普通复位一起清掉，后续同样不能一律回到第零步。
更合理的做法是让程序先进入恢复步骤，重新检查设备现在在哪里，再决定回原点退掉，继续运行还是人工处理。所以复位不是让设备假装什么都没有发生，真正清掉的是故障之前留下，现在已经不能继续执行的命令。

---

0. 心智模型：PLC 复位的本质

复位（Reset）不是“一键还原”回出厂设置，而是“清理不合时宜的愿望，保留客观存在的真相”。

      +-------------------------------------------------------+
      |                  PLC 运行逻辑状态模型                    |
      +-------------------------------------------------------+
      | [ 物理反馈层 ] (真相) -> 传感器、轴位置、配方数据 (不可复位) |
      +-----------^-------------------------------------------+
                  |
      +-----------+-----------+      +------------------------+
      | [ 逻辑控制层 ] (中间态) | <--- | [ 用户指令层 ] (愿望)    |
      |   状态机、定时器、计数器   |      |  启动保持、点动请求、触发 |
      +-----------+-----------+      +-----------+------------+
                  |                              |
      +-----------v------------------------------v------------+
      | [ 复位操作 (Reset) ] -> 剪断残留愿望，检查物理真相，决定下一步 |
      +-------------------------------------------------------+

---

1. 核心概念分组：三类“必清”与“必留”

为了方便理解，我们将复位动作在三个不同场景中串起来：

场景 A：第一类：启动保持

• 概念：启动保持位（Running Latch）。
• 故事：你点了一桌菜（启动），厨师正在做。突然厨房着火了（报警）。复位时，必须把“继续做这桌菜”的指令撤销。
• 理由：如果不撤销，火一灭厨师直接开火，可能此时食材已经焦了或者服务员还没准备好接盘。

场景 B：第二类：操作请求

• 概念：中间触发位、单次请求（Request Flag）。
• 故事：报警前你按了“气缸伸出”，但气缸还没动就报错了。复位时，这个“伸出请求”必须清掉。
• 比喻：就像你发了表白短信，如果对方拒绝（报警）了，复位后你不应该默认对方还在考虑那条短信。

场景 C：第三类：报警锁存

• 概念：故障锁存（Alarm Latch）。
• 故事：手被烫了会疼（报警）。复位是把“疼的感觉”消掉，但前提是手已经离开了火源（故障消失）。
• 理由：如果手还在火上，你按多少次“不疼”的按钮（复位），疼痛感都会立刻回来。

---

2. 知识点与“深坑”总结

知识点

1. 复位的对象是“逻辑”而非“物理”：清掉的是 PLC 内部的 M 或 DB 位，而不是直接去改 I/O 输出（除非安全回路强制）。
2. 边缘触发复位：复位信号应该是上升沿触发，防止复位按钮卡死导致逻辑一直处于清零状态。
3. 状态机回转：复位后，程序应进入 Manual 或 Step Recovery 模式，而不是直接回 Step 0。

陷阱（坑）

• 【天坑】全盘复位：有些工程师喜欢一按复位就把所有中间寄存器 Fill_N 清零。
  • 后果：设备丢失了当前位置信息，原本只需走 10cm 的轴，现在认为自己在原点，直接撞墙。
• 【地坑】不分性质的电磁阀复位：
  • 现象：双电控电磁阀在复位时被强制“复位到初始位”。
  • 后果：夹具在报警时还夹着产品，复位瞬间松开，产品掉落砸坏设备。

---

3. 数据来源与算法逻辑

数据来源

• 标准协议：参考 ISA-S88 状态模型或 OMAC PackML 标准。
• 工程经验：源于汽车制造（如大众标准、通用标准）对设备安全复位的强制要求。

涉及的逻辑算法

复位逻辑通常采用“条件组合逻辑”：

1. 报警清除算法：IF (Fault_Condition == FALSE) AND (Reset_Button_Rising_Edge == TRUE) THEN Alarm_Latch = FALSE;
2. 指令切断算法：IF (Global_Alarm == TRUE) THEN Clear_All_Requests();

---

4. 指标意义与生产指导

指标	意义	对生产的指导
MTTR (平均修复时间)	衡量报警到恢复的速度	良好的复位逻辑能让操作工一键恢复，缩短停机时间。
二次事故率	复位后发生的非预期动作次数	若复位导致二次撞机，说明复位逻辑没有清掉“残留请求”。
数据追溯完整率	报警复位后数据是否丢失	严禁复位时清掉生产批次、扫码信息等核心数据。

---

5. 经典问答 (Q&A)

Q：复位时到底要不要让气缸回到原点？
A： 绝对不要在普通复位里自动动气缸！复位只是“清除故障状态”。如果需要回原位，应该由操作员手动按“回原点”按钮，或者在复位后切换到“恢复模式”受控地执行。

Q：为什么按了复位，报警灯还亮着？
A： 说明“物理真相”还在。比如急停没拔出来，或者光幕还被遮挡。程序检测到故障触发条件依然为 True，所以拒绝清除锁存。

---

6. 最佳工程实践：正确做法 vs 反例

反例 (Bad Practice)

// 错误写法：不分青红皂白一把抓
IF Reset_Button THEN
    FILL(0, M0.0, 1000); // 毁天灭地的清除，导致所有状态丢失
END_IF;

正确做法 (Best Practice)

// 1. 复位报警锁存（仅在条件消失时）
IF Reset_Btn_RisingEdge AND NOT Sensor_Overload THEN
    Alarm_Latch_Overload := FALSE;
END_IF;

// 2. 切断启动保持和危险请求
IF Global_Alarm THEN
    Running_State := FALSE;       // 停止自动运行逻辑
    Request_Cylinder_Ext := FALSE; // 清掉“愿望”
    Request_Servo_Move := FALSE;  // 防止复位后轴突然飞出去
END_IF;

// 3. 保留关键数据
// Product_ID, Current_Position, Step_Number 严禁在 Reset 中修改

---

7. 关联功能

• 安全回路 (Safety Integrated)：复位往往需要先复位硬件安全继电器。
• HMI 报警诊断：复位逻辑应与人机界面的报警显示一一对应。
• MES 系统：报警和复位的时间点需要上传，用于 OEE（设备综合效率）计算。

---

总结

复位不是掩耳盗铃，而是“断舍离”。 它断掉的是不可控的未来（残留指令），舍弃的是已发生的痛苦（故障锁存），而离开的是混乱的状态。优秀的 PLC 工程师，复位逻辑里写的是对物理世界的敬畏。