急停已经释放，ESTOP1.Q 为什么仍然是 0？确认按钮明明按过，程序为什么没有恢复允许？这类问题不能只看按钮当前的电平，还要看输入何时恢复、确认沿何时被识别，以及这个调用是否正在等待确认。ESTOP1 的作用就在于组织停止与重新使能之间的逻辑，而不是提供一个万能复位入口。 [1]

本篇属于「SIMATIC Safety 工程笔记」的功能应用部分，面向已经理解 F-CPU、F-I/O 和基本安全组态、需要读懂急停调用的读者。先以一个实际官方调用说明信号去向，再分析正常停止、确认、延时重触发和输入故障。本文为官方例程与指令解读，没有进行仿真或实机复现。

资料范围：行为说明以《STEP 7 Safety V21 Instructions》（11/2025）为基线，涉及重触发时明确使用指令版本 1.6。三张截图来自上一组态篇采用的同一套 V14 SP1 历史例程，CPU 为 1511F-1 PN、固件 V2.1，F-DI 为 6ES7136-6BA00-0CA0。旧图用于读懂实际连接，不用于证明它运行了 1.6，也不是 V21 实测工程。 [1] [2]

操作边界：下面的地址、时间和状态是资料示例。在线修改、下载、恢复输出或测试之前，应完成相应风险评估、备份和维护授权，并使危险运动处于受控状态。本文不提供可直接投产的急停回路，不把功能块确认当作机器启动命令。 [5] [9]

一、从实际调用看输入、实例和输出

在官方例程的主安全块中，作者从 Safety functions（安全功能）插入 ESTOP1，实例为 ESTOP1_DB。看图先沿左侧输入进入块，再沿右侧输出离开，不要只找黄色框里的名字。图中 Tag_1 等只是例程符号，正式项目应按实际对象命名。 [2]

1. 把例程连接翻译成工程含义

下面只整理图中实际接线，地址不具有通用性。接口的数据类型另以 V21 参数表核对；表内的 TRUE 和 T#0ms 是这个例程的选择，不是对所有项目的推荐值。 [1] [2]

接口	图中的连接	需要读懂的含义
E_STOP，BOOL 输入	%I0.0 / Tag_1	停止条件输入。0 请求停止；1 只是该输入条件恢复。
ACK_NEC / ACK，BOOL 输入	TRUE / %I0.1	本例要求人工确认；ACK 承接确认按钮的信号。
TIME_DEL，TIME 输入	T#0ms	本例未建立需要延时输出的停止路径。
Q / Q_DELAY，BOOL 输出	%Q6.0 / 未接出	图中只使用立即撤销的 Q；它的最终作用仍要追查输出回路。
ACK_REQ / DIAG	%M0.0 / 未接出	分别为 BOOL 确认请求与 BYTE 非故障安全服务信息；本图未显示 DIAG。

把表读完，应能区分三种对象：输入条件、功能块内部状态和现场执行结果。例如，图中的 %Q6.0 是输出地址，但只凭这个地址，不知道接触器、驱动或其他执行机构是否按要求动作。原图没有展示完整执行回路，不能替它补写一套已经验证的接线。

2. 实例保存状态，调用必须处于正确的执行路径

每次 ESTOP1 调用需要分配实例数据，可以是单实例 DB，也可以是调用块静态区中的多重实例。项目中有多个独立急停逻辑时，应分别确认其调用与实例对应，不能只复制一张网络图就忽略保存状态的对象。 [1]

ESTOP1 的 EN/ENO 不允许接线。不能照普通块的习惯，在 EN 前串一个“只有急停时才执行”的条件；同样，“指令总是执行”不能解释成主安全块没有被调用时，它仍会在后台运行。应先确认所属 F 运行组和主安全块的调用路径，再检查接口信号。 [1] [3]

这项检查适合在离线阅读时完成：找到实例、查输入与输出交叉引用，确认没有另一处逻辑覆盖同一目标，再进入时序分析。本文没有提供另写的 SCL 替代程序，也不把伪代码包装成可以编译的安全逻辑。

二、送入 E_STOP 的，应是正确处理后的输入条件

对 V21 ESTOP1 说明中的双常闭触点急停配置，双通道等价评估及差异监控应先由 F-I/O 完成，再把评估结果送到 E_STOP。这个块只有一个停止条件输入，不会替你比较两根原始触点线，也不会自动补齐短路诊断。 [1]

同一急停装置的两路原始触点，与两个已经评估完成的安全条件，是不同对象。把两个原始位做一次 AND，只描述了布尔关系，不能据此声称已经实现对应 F-I/O 评估的诊断能力。先明确自己手里的是哪一层数据，再决定怎样组织上层逻辑。

指令说明还要求，在其所述配置中，为避免差异时间影响停止响应，将差异期间的行为设置为 Supply value 0（提供值 0）。这里不能仅记下一个差异时间毫秒数：差异出现时先向程序提供什么值，同样决定了停止条件何时到达。更完整的参数关系见 F-DI 差异时间与输入延时。 [1]

输入无效时，程序可能得到安全替代值 0。手册 S009 要求数字安全输入始终处理系统提供的输入过程映像值，不能因为模块质量无效，就用故障前保存的 1 顶替当前输入来保持运行许可。诊断用来解释停止原因，不用来取消应有的安全反应。 [6]

三、Q 与 Q_DELAY 分别决定什么时刻撤销允许

E_STOP 变为 0 后，Q 在指令处理时撤销；Q_DELAY 按 TIME_DEL 延时撤销。Q_DELAY 是关断延时的允许信号，不是等一段时间才发出的“启动脉冲”。“立即”也只是相对于该指令的逻辑处理，不表示从按钮动作到机械停止的总时间为零。 [1] [4]

Siemens 将这两个输出分别用于支持停止类别 0 和 1 的实现，同时明确完整符合相应标准还需要其他措施。实际停止方案要决定立即撤销的信号作用于哪里、延时期间需要保留什么，以及到期后怎样完成安全切断；不能只接出 Q_DELAY，就宣布实现了完整受控停止。 [1]

举一个用于理解的条件情境：若既定停止方案需要驱动在减速阶段继续提供转矩，那么一开始就切掉该阶段必需的能量，会使设计所要求的减速过程失去前提。反过来，继续保留能量也必须受安全功能约束。这个推理说明的是信号与执行方案要匹配，不是为某款驱动指定接线。

图 1 使用 TIME_DEL = T#0ms，而且没有接出 Q_DELAY，因此不能从这张图推导任何延时停止性能。本篇不把例程里的零延时擅自改成“常用 500 ms”，也不从一张在线截图猜测机器的最不利停止时间。 [2]

检查一个已有项目时，可以把时间分为三层：块设定的延时、程序及通信的处理时间、执行机构完成动作的时间。V21 对时间指令还要求考虑循环处理、时间基准更新和 CPU 内部计时容差；重复调用并不等于时间基准在同一运行组周期内重复更新。本文只说明这些误差来源，不把不同 CPU 的数值混成一条通用公式。 [4]

因此，TIME_DEL、F-monitoring time 和整条安全功能的最大响应时间不能互换。改变一个时间参数后，需要按所用设备的计算条件重新核对结果；目标不只是让报警消失，而是同时满足可用性与过程允许的安全时间。 [11]

四、沿一次“停止—释放—确认”看输出为什么不恢复

先只看立即输出 Q，固定采用 ACK_NEC = TRUE，并假定输入评估有效、指令持续按要求调用。下面是依据指令规则整理的逻辑状态表，不是设备测试记录，也不表达精确扫描周期。延时尚未结束时的另一种过程在第五节单独讨论。 [1]

阶段	输入与操作	Q 和 ACK_REQ 的预期
已确认并允许	E_STOP = 1；先前确认已完成	Q = 1；ACK_REQ = 0。ACK 无需持续保持为 1。
停止条件到达	E_STOP = 0	Q 撤销；此时不是可以靠确认重新使能的阶段。
条件恢复，尚未确认	E_STOP = 1；没有新的有效 ACK 上升沿	Q = 0；ACK_REQ = 1。
满足条件后确认	E_STOP 保持为 1，ACK 出现有效上升沿	Q 恢复允许，ACK_REQ 清除。
确认按钮释放	ACK = 0，停止条件未再次出现	已完成的确认不因按钮释放而被撤销；机器能否启动仍看后续逻辑。

这张表解释了一个常见误判：E_STOP 为 1，只说明停止输入条件不再有效，不说明确认已经完成。检查时应把 E_STOP、ACK、ACK_REQ 和 Q 放在同一个实例中观察，并保留变化先后。监控表刷新到的某一刻，可能已经看不到此前短暂出现的确认沿。

下面是同一官方例程的在线画面：E_STOP 和 Q 为 TRUE，ACK 与 ACK_REQ 为 FALSE。它能支持“截图时块处于已使能状态”，却不能支持“只要 E_STOP 为 1，Q 就会自动变成 1”。图里 ACK 为 FALSE，也不能证明此前从来没有确认过。 [2]

确认过早、持续为高与上电，分别怎么看

确认是一个有条件的事件，不是预先存入的永久许可。E_STOP 仍为 0 时反复按按钮，不会消除停止输入；待输入恢复，应在项目允许的条件下产生被指令识别的确认沿。不要把“人已经按过”直接等同于“这个实例在正确阶段看到了上升沿”。 [1]

ACK 一直为 1 不会产生新的 0→1 变化。排查应看按钮、线路和逻辑是否把确认保持住，而不是再并上一条自动脉冲。尤其不能把 ACK_REQ 反馈给 ACK 来取代原设计要求的人工判断。ACK_REQ 表示块在请求确认，不是危险区域已经安全的证明。 [1] [5]

F 系统启动后，ACK_NEC = 1 的 ESTOP1 也需要 ACK 上升沿。把机器停机重启，不能代替本来缺失的确认。系统手册还指出，安全程序启动时通常会初始化 F-DB，F-I/O 可以自动重新集成，因此整机的启动保护必须另行落实，不能只依赖旧故障状态是否保留下来。 [1] [5]

改变确认策略之前：只有通过其他措施排除了相关过程的自动重启，才允许按 S033 使用 ACK_NEC = 0。这是一项安全设计条件，不是“临时调试方便”的选项。即使保持人工确认，也应另外验证确认动作不会直接变成不允许的设备启动。 [1] [5]

五、指令 1.6：延时期间再次停止，会重新计时

这里讨论另一种调用：Q_DELAY 被实际使用，TIME_DEL 为经过设计确定的正延时。不要把它与图 1 的零延时、Q_DELAY 未接出的例程混为一谈。V21 的版本说明指出，S7-1200/1500 上的指令 1.6 在延时尚未结束时，若停止输入经历“0→1（包括确认）→0”，延时会重新开始。 [1]

可以用三个事件读懂这句话：第一次停止启动延时；在延时结束前输入恢复并完成所需确认；随后再次发生停止。关键是中间包含了恢复及确认，不能把它简写成“输入抖一下，计时就一定重置”。原页面在版本备注中把该输入写作 ESTOP，本文按其参数表统一称 E_STOP。 [1]

下面是对该规则的符号化举例：设延时为 D，第一次停止发生在 A，第二次符合上述条件的停止发生在 B。重新计时后，应从 B 对照这次 D，而不能仍把 A＋D 当作最终截止点。A、B、D 不代表实测时间；实际观察还受第四项资料所述时间误差影响。 [1] [4]

这意味着验证不能只覆盖“一直按住急停直到停止完成”。还要根据项目允许的操作，评价延时中恢复、确认和再次停止的过程，检查是否影响执行机构预期的停止方式。已有工程更换指令版本时，应先记录原版本与新版本，做变更影响分析，而不是看到块名没变就沿用全部旧结论。 [10]

本文没有从 1.6 的差异说明反推出所有旧版本的完整行为，也没有给出某个未经复现的精确波形。已有项目使用其他指令版本时，以该版本帮助及受控测试结果为准；不能用“工程软件是 V21”代替实际指令版本记录。

六、F-I/O 恢复与 ESTOP1 确认不是同一个入口

如果急停装置已释放，而 E_STOP 仍为 0，应先查这个 0 的来源。它可能是输入条件仍未满足，也可能是 F-I/O 处于钝化（passivation）时提供的安全替代值。此时仅操作 ESTOP1 的 ACK，不能修复输入通道的故障。 [6]

同一 S7-1500F 例程给出了双通道急停其中一路断线后的诊断：通道 0 出现差异错误，并显示 F-I/O channel passivated。这张图把问题定位到输入及模块诊断层，不是 ESTOP1 内部发现了断线，也不表示所有差异故障都由断线造成。 [2]

这里有两组容易同名混淆的接口：ESTOP1.ACK_REQ / ACK 服务于这个停止逻辑的重新使能；F-I/O DB.ACK_REQ / ACK_REI 服务于相应模块恢复过程数据。两个 ACK_REQ 来自不同对象，不能仅因名称相同就把它们接成一条“总复位”。 [1] [7]

对手册所述通信故障，相关 F-I/O 的重新集成需要先消除全部通信错误，由系统给出确认请求，再收到规定的用户确认上升沿。模块或通道故障则要按其对应恢复规则处理，不套用一条通用公式。重新集成意味着过程值恢复，不等于 ESTOP1 已确认，更不等于设备已满足启动条件。 [6] [7]

确认恢复输出之前，先确认其后果安全。记录应能分清：故障何时消除、过程值何时恢复、ESTOP1 何时接受确认，以及后续启动条件何时成立。这不要求每台设备必须有多个物理按钮，但要求程序与验证不能把不同层次的条件省略。完整恢复分支见 F-I/O 钝化、重新集成与启动保护。 [5] [7]

七、用 DIAG 缩小范围，不把它当安全许可

V21 将 DIAG 定义为 BYTE 类型的非故障安全服务信息，可用于显示和标准程序诊断。它不是替代 Q 的控制许可，也不能只看整个字节是否非零就宣布有故障：其中同时包含确认请求和 Q 状态。 [1]

下面提取与本文排查直接相关的位。表中掩码是按位号换算的表示方式，用于判断某一位是否置位，不是整个 DIAG 字节必须等于该数值；其他位可能同时存在。 [1]

位 / 十六进制掩码	意义	优先检查
Bit 0 / 16#01	延时设置异常；官方列出的原因是负延时	核对本实例的 TIME_DEL 实际值、类型和指令版本，不随手试改时间。
Bit 4 / 16#10	停止仍有效，无法确认	看 E_STOP 来源、按钮状态、接线及 F-I/O 诊断。
Bit 5 / 16#20	缺少使能时，ACK 长期为 1	确认线路或逻辑是否保持高电平，是否存在新的有效确认沿。
Bit 6 / 16#40	需要确认，对应 ACK_REQ	先判断允许确认的条件，不把请求本身直接反馈成确认。
Bit 7 / 16#80	Q 的状态	非零可能只是 Q 已使能，不能按“DIAG 非零＝故障”处理。

Bit 4、Bit 5 会保存到 ACK 确认为止。因此，故障记录还要区分当前条件与已保存的信息。建议在清除显示或重新下载前，保存实例名、E_STOP、ACK、ACK_REQ、Q、TIME_DEL、DIAG 以及相关模块诊断；只有一个十六进制数，往往不能重建事件顺序。 [1]

例如，E_STOP 仍为 0，就先查输入来源；E_STOP 为 1、ACK_REQ 为 1 而 Q 为 0，就核对确认阶段；Q 已为 1 而现场执行器没有按要求动作，则转向输出、后续逻辑与反馈回路。FDBACK 专门检查命令和反馈之间的时间关系，ESTOP1 不能代替这一层。 [1] [8]

八、把验证写成有预期的记录，而不只看输出变绿

测试前提：以下是用于编制验证计划的建议，不是在线测试授权。应先确认危险能量控制、测试人员权限、停止与恢复条件，以及每个刺激动作的影响。需要模拟断线、停通信或改变确认信号时，必须使用经批准的测试环境与方案；本文不要求在生产设备上直接强制地址或拔线。

先完成离线核对：实际 CPU 和 F-I/O、指令版本、实例归属、双通道评估依据、输入/输出交叉引用、TIME_DEL 与确认策略。没有这些记录，就很难解释同一组动作为什么在另一台设备上表现不同。接着为每个测试场景预先写下观察对象，不能发生什么就把什么当成期望结果。

需要覆盖的情境	程序层的观察重点	还要独立确认什么
正常停止，再释放	停止时 Q 撤销；手动确认方案中，释放后仍等待新的确认	执行机构的实际停止结果、停止时间和风险控制。
正确阶段确认后释放按钮	ACK 沿被当前实例识别，ACK_REQ 清除；不要求 ACK 常高	确认不会引发未经允许的自动启动。
确认过早或长期按住	未满足的停止条件不能被确认覆盖；保存实际时序与 DIAG	按钮、线路、脉冲宽度与采集条件。
F 系统启动或重新启动	核对 ESTOP1 启动确认及系统启动保护	旧命令或自动重新集成不会意外恢复危险动作。
延时期间再次停止	只对适用调用核对 1.6 的恢复、确认、再次停止和重新计时	该分支是否仍满足最不利停止时间与执行方案。
输入故障及恢复	区分安全替代值、模块重新集成和 ESTOP1 确认	故障消除方式、输出恢复后果和整机启动条件。

这些检查可以分三层留证据：输入层保存现场信号、评估及诊断；逻辑层保存同一实例的变化顺序；执行层记录真实动作与时间。仿真观察不能自动覆盖接线和机械过程，一张绿色程序截图也不能代替完整安全功能测试。 [9]

记录格式可以保持简洁，例如“版本与实例 → 测试前状态 → 动作及顺序 → 预期 → 实际观察 → 差异与未覆盖条件”。本文没有实际测试结果，不能替读者把最后两项填成通过。发现偏差时先保存证据，回到相应层级定位，不靠降低确认要求或增加时间让测试看起来成功。

修改指令版本、确认策略、输入评估或时间参数后，按变更影响分析确定需要重新验证的内容，并保留参照工程、比较结果和验收记录。受影响的部分可能并没有直接改过代码，不能只测试鼠标刚刚编辑的那一个网络。 [10]

读懂 ESTOP1 的终点不是背出几个管脚，而是能解释一次停止为什么发生、为什么暂时不能确认、何时恢复允许，以及这份允许随后作用于哪里。需要继续理解执行器反馈，可读 FDBACK 反馈回路与超时诊断；交付前再核对 程序验收、签名与归档。

资料来源

以下按实际使用的章节列出。第 2 项为历史例程，其余为 V21（11/2025）文档；图示环境、指令版本与测试状态分别看待。文中的状态表、符号化时间举例和检查顺序为基于资料的整理，不是从设备导出的测试记录。

1. Siemens：ESTOP1: Emergency STOP/emergency OFF up to stop category 1。STEP 7 Safety V21 Instructions，11/2025；Description、S033、Parameters、Instruction versions（1.6）、Startup behavior、Structure of DIAG。

2. Siemens：TIA Portal 中 S7-1500F CPU 与 ET200SP 安全模块的配置例程。V14 SP1 历史例程；第 1 节环境、第 3 节软件编程、第 4 节模块钝化；原图 3-2、3-4、4-1。

3. Siemens：Connection of the Enable input EN and Enable output ENO。STEP 7 Safety V21 Instructions，11/2025；EN/ENO 接线限制。

4. Siemens：Temporal blurring for instructions with time processing。STEP 7 Safety V21 Instructions，11/2025；时间处理误差、S034；不同 CPU 的条件分别适用。

5. Siemens：Programming startup protection。SIMATIC Safety V21，11/2025；Introduction、S008。

6. Siemens：Process Data or Fail-Safe Values。SIMATIC Safety V21，11/2025；钝化、数字输入警告 S009、Reintegration。

7. Siemens：After communication errors。SIMATIC Safety V21，11/2025；通信故障后的钝化和重新集成条件。

8. Siemens：FDBACK: Feedback monitoring。STEP 7 Safety V21 Instructions，11/2025；Description，仅用于说明执行器反馈的职责。

9. Siemens：Overview of System Acceptance。SIMATIC Safety V21，11/2025；验收范围、在线与离线一致性、归档。

10. Siemens：Acceptance of Changes。SIMATIC Safety V21，11/2025；Introduction、变更定位和影响分析、S072。

11. Siemens：Configuring the monitoring times。SIMATIC Safety V21，11/2025；Rules、General procedure；监控时间与最大响应时间核对。

图片说明：三张截图均来自资料 [2] 的公开官方例程，未生成或改绘软件界面。图中地址、实例、状态和诊断属于原例程，不是本站现场记录；图片权利归 Siemens，不纳入本站原创文字的 CC BY-NC-SA 许可。

修订说明：改用与组态篇配套的 S7-1500F 官方调用，补充确认事件、延时重触发、诊断位与分层验证；原文的 S7-1200 调用图和通用接线图移出正文，原媒体保留。正文不设目录，本文仍为资料解读，未进行仿真或实机验证。