F-I/O 为什么会钝化：ACK_REI、ACK_GL、QBAD 与重新集成完整逻辑

前面的 F-I/O DB、ESTOP1、SFDOOR、FDBACK 都会遇到同一个底层问题：为什么现场故障已经消失，Safety 程序却仍然使用 0，或者模块还在等待确认？

答案在 F-I/O 的 passivation（钝化）与 reintegration（重新集成）机制里。这也是排查时最容易搞错方向的地方——把“还没恢复”当成“还有故障”，回头去查现场。

F-I/O 钝化时，Safety 程序使用规定的故障安全值 0。此时看到的过程值可能已经不是现场真实状态。

诊断时把两件事分开：故障是否还存在，以及是否已经重新集成。顺序是固定的：

完整链路：钝化 → 故障消失 → ACK_REQ=1 → 确认正沿 → 重新使用过程值。

一、什么时候会钝化

Siemens V21 规定，在 F-System 启动、PROFIsafe 通信错误、F-I/O 故障、通道故障、程序设置 PASS_ON=1 或 F-I/O 被停用时，系统可能使用故障安全值代替过程值。

最后一行值得留意：如果是程序自己把 PASS_ON 置 1，现场怎么查都查不出毛病。

如果 F-CPU 与 F-I/O 之间检测到安全通信错误，整个 F-I/O 的所有通道都会被钝化。对于 S7-1200/1500 的相关 F-I/O，QBAD 和 PASS_OUT 会反映整块模块进入故障安全状态，通道值使用 0。

通信恢复并不等于立即恢复过程值。所有通信错误必须先消除，F-System 将 ACK_REQ 置 1，然后通过当前 F-I/O 的 ACK_REI 或全局 ACK_GL 完成人工重新集成。

对于模块故障或通道故障，重新集成方式取决于 ACK_NEC 或模块参数“Channel failure acknowledge”。如果设置为 automatic，F-System 检测到故障已经排除后可以自动重新集成。

如果设置为 manual，则必须等故障消除且 ACK_REQ=1 后，再给 ACK_REI 或 ACK_GL 一个上升沿。对于某些 F-I/O 输出，故障排除后还可能需要等待模块内部必要的测试信号完成，人工确认不一定能立即执行。

这两个很容易混。ACK_REQ 是“可以确认了”的状态信号，由 F-System 在确认相关故障已经排除后置 1，不是用户自己写入的命令。

ACK_REI 才是针对单个 F-I/O 的重新集成命令，并且依赖上升沿。确认完成以后，ACK_REQ 会复位。

一个读、一个写，方向相反。把 ACK_REQ 当成命令去写是无效的。

ACK_GL 用一个全局确认信号同时重新集成当前 F-runtime group 内所有满足条件的 F-I/O 或通道。它的输入 ACK_GLOB 需要上升沿。

Siemens V21 规定，ACK_GL 每个 F-runtime group 只能调用一次。使用全局确认时，对应 F-I/O DB 的 ACK_REI 必须保持 0；反过来，使用单个 ACK_REI 时，ACK_GLOB 必须为 0。两种方式不能混用。

全局确认不是“忽略所有故障”，只有已经满足重新集成条件的 F-I/O 才会响应。它省的是逐个确认的力气，不是排障的力气。

Siemens 对 F-I/O 供电中断给出了一个容易被忽略的特殊情况：如果供电中断持续时间短于该 F-I/O 的 F-monitoring time，可能发生自动重新集成，并且不受 ACK_NEC 或 Channel failure acknowledge 设置限制。

这一条的分量很重：你可能把确认策略全部设成了人工，但一次短暂的电源波动仍然可能让模块自己恢复。如果相关过程不允许这种自动恢复，需要通过 QBAD、Value Status、PASS_OUT 等状态自己编写 startup protection，避免设备在短暂供电恢复后直接重新进入运行条件。

常见说法	实际情况
故障消失就会立即恢复真实过程值	是否自动恢复取决于故障类型、确认策略和 F-I/O 特性
`ACK_GL` 可以把所有故障强制清掉	它只对已经满足重新集成条件的 F-I/O 进行确认
`ACK_REI` 长期为 1 更可靠	重新集成依赖正沿，应使用明确的确认脉冲
短暂掉电一定会等待人工确认	短于 `F-monitoring time` 的供电故障可能自动重新集成