SINUMERIK 840D/828D UAFEHL 报警怎么处理？PLC 进入 Stop Mode 的原因与 DB2 报警定位-CNCShare

一、UAFEHL 到底是什么（先纠正常见误解）

很多人第一次看到 UAFEHL，会下意识把它当成一个“故障代码”去翻手册——其实它不是一个具体的故障，而是 SINUMERIK 报警机制里的一个触发标识：

U = User（用户）
A = Alarm（报警）
FEHL = Fehler（德语“故障 / 错误”）

合起来就是 User Alarm Fault——用户报警故障。它是机床厂（OEM）通过 PLC 用户报警机制自定义的一类报警。当某条被配置为“停机级”的用户报警触发时，PLC 被强制带入 STOP（停止）模式，操作界面上就会看到 UAFEHL 字样和对应的报警号（典型如 UAFEHL 700000、UAFEHL 700001…）。

⚠️ 常见误解必须纠正：网上有资料把 UAFEHL 解释成德语“Benutzerfehler（用户错误 / 操作员失误）”的缩写，这是不准确的。UAFEHL 的语义是“用户（自定义）报警故障”，指的是机床厂编进 PLC 的那条报警被触发了，而不是在说“操作员按错了”。把它理解成“操作员错误”会直接把排查方向带偏——你该查的是 PLC 里哪条用户报警被置位，而不是去问谁操作失误。

关键结论：UAFEHL = “有一条停机级用户报警被触发了”这个状态本身，真正的原因藏在触发它的那条 700xxx 报警和对应的 DB2 位里。与之同时，当 PLC 进入 STOP、与 NC 的通信中断时，NC 侧往往还会伴随出现 120202“等待与 NC/PLC 的连接” 报警——这是 PLC 停机后的“结果性”报警，不是根因。

相关阅读：如果你想知道这些 700xxx 报警是怎么编出来的，见《西门子 840D PLC 用户报警怎么编：700xxx 与 DB2 地址换算》。

UAFEHL 概念图：它是用户报警触发的 PLC 停机标识而非具体故障，纠正 Benutzerfehler 误解

二、★ PLC 停机的六类根因

UAFEHL 只是“报警被触发”的统称，背后的根因可以归成六类。排错时先按这张表把范围收窄，比盲目翻程序快得多：

根因类别	典型触发条件	现场第一反应
① 用户报警	机床厂自定义报警（700xxx）满足置位条件	记报警号 → 查 DB2 对应位（见第四节）
② I/O 硬件	I/O 模块故障、接线松动、传感器断线	看模块 LED、硬件诊断扫描
③ 安全回路	安全门、急停、光幕未闭合	核安全继电器 / 安全 PLC 状态，恢复回路
④ 过程互锁	液压压力低、润滑失效、冷却不足	查压力 / 液位开关，满足互锁条件
⑤ 通信丢失	PROFIBUS / PROFINET 断线、终端电阻错	查总线电缆、接头、终端电阻
⑥ 存储损坏	PLC 程序或数据块损坏、备份不匹配	用备份重新下载 PLC 程序

经验：六类里“用户报警”和“过程互锁”占了现场大多数。安全回路和通信丢失次之，I/O 硬件和存储损坏相对少见但危害大。

SINUMERIK PLC 停机六类根因：用户报警 / I-O 硬件 / 安全回路 / 过程互锁 / 通信丢失 / 存储损坏

三、标准处置流程五步

遇到 UAFEHL + PLC STOP，按下面五步走，基本能在现场把报警号锁定到具体位：

记报警号：先把界面上显示的完整报警号抄下来（例如 UAFEHL 700806），这是后面所有定位的钥匙。
打开工程：用 STEP 7（SIMATIC Manager）或 TIA Portal 打开该机床的 840D PLC 项目（828D 用 SINUMERIK 的 PLC 编程工具）。
查 DB2 报警位：按报警号算出 DB2 中的字节 / 位，在线监控该位是否为 1，确认是哪一条用户报警在报警。
看 CPU LED：观察 NCU（840D）或 PPU（828D）上的 SF / STOP / RUN 指示灯，确认 PLC 当前确实在 STOP，以及有没有硬件故障（SF）。
硬件诊断扫描：在 STEP 7 / TIA 里用“硬件诊断”功能扫描机架，找出缺失或报错的模块（I/O、通信、电源）。

小提醒：PLC 在 STOP 状态下无法靠“复位”消除硬件 / 通信类故障，必须先把物理问题解决了，再重新将 PLC 置为 RUN。

UAFEHL 处置五步流程与 PLC CPU 的 SF / STOP / RUN 三灯含义

四、CPU 三个 LED 的含义（最基础也最常被误读）

以 840D（NCU 内集成 S7-300 PLC）为例，PLC 状态主要看三个灯：

SF（红色，System Fault）：系统故障。亮 = 有硬件故障、总线故障或程序错误（如 OB 缺失导致的同步错误）。它是“有问题”的总信号。
STOP（黄色）：PLC 处于停止模式。亮 = 程序没有运行，这就是 UAFEHL 触发后的典型状态。
RUN（绿色）：PLC 运行。亮 = 程序正常循环执行。

⚠️ 常见误读：有人看到 SF 红就以为是“PLC 坏了要换”，其实 SF 大多数时候是“某个 OB 没下载”或“某个模块报错”，并不等于 CPU 报废。也有人把 STOP 黄灯当成“电源没给”，其实黄灯恰好说明 PLC 上电了只是没运行。

828D 的 PLC 跑在 PPU 里（软 PLC，S7-200 架构），没有与 840D 完全一样的独立 PLC LED 排；它的状态主要靠 PPU 上的状态 LED 和操作界面的诊断画面判断，思路一致：先确认 PLC 是否处于停止，再看诊断信息。

五、关键 OB 的作用

S7-300 的 PLC 靠“组织块（OB）”来响应不同事件。UAFEHL / PLC STOP 相关，最该认识这三个：

OB100（冷启动 / Startup）：PLC 上电或模式切换时执行一次，负责初始化。FB1（报警块）如果在 OB100 里没被正确调用初始化，报警系统可能根本没建起来，一触发就异常停机。
OB121（同步错误）：程序执行中出错（如访问了不存在的地址、数据类型错）时触发。如果没有下载 OB121，CPU 会直接停——很多“莫名其妙 PLC 停机”其实就是缺了 OB121。
OB40（硬件中断）：由模块硬件中断请求驱动的报警 OB，常用于把外部事件快速上报成报警。与之配合的还有 OB82（诊断中断）、OB86（机架 / 模块故障）等，处理通信 / 模块类根因时都要看。

排错铁律：PLC 频繁停车又找不到原因，先确认 OB100 / OB121 有没有下载进 CPU。缺 OB121 是最容易被忽略、也最好修的一类“停机”。

六、常见 700xxx 段报警与 DB2 定位速查

700xxx 是 SINUMERIK 里用户报警区的地址段，对应 DB2 中的报警位。换算关系（与“怎么编报警”那篇一致）：

报警号 700xxyy → DB2 字节 = 180 + xx×8 + ⌊yy/8⌋，位 = yy mod 8
起始 700000 对应 DB2.DBX 180.0
每组（xx 固定）内，前 4 字节（yy 00–31）是 EM（红色、锁存、需 Quit / RESET 才能消），后 4 字节（yy 32–63）是 OM（黑色、自动消失）

举例：

报警号	DB2 位	说明
700000	DB2.DBX 180.0	用户报警区基址（EM 组第 0 位）
700806	DB2.DBX 244.6	字节 = 180 + 8×8 + ⌊6/8⌋ = 244，位 = 6
701661	DB2.DBX 315.5	字节 = 180 + 16×8 + ⌊61/8⌋ = 315，位 = 5
700458	DB2.DBX 219.2	字节 = 180 + 4×8 + ⌊58/8⌋ = 219，位 = 2

⚠️ 重要：上面“报警号 → 含义”只给了地址定位，没给“每条报警代表什么故障”。因为 700xxx 的具体含义是机床厂（OEM）自己定义的，每台机床不一样。真正的含义在机床厂的报警对照文档（通常是 HMI 语言目录下的 oem_alarms_plc_*.ts 文本，或随机床提供的报警清单）里。网上的“700001 = 主轴未准备好”之类说法只是某一台的个例，不能直接套到你的机床上。定位到 DB2 位后，下一步是去反查“谁在写这个位”（常用 SFC20 从背景 DB 整块搬入，沿写位网络往上找触发条件）。

相关阅读：地址换算和 EM / OM 分组更完整的讲法，见《西门子 840D PLC 用户报警怎么编》。

七、为什么有些报警复位不掉

经常有现场问：“报警消了又来，或者根本复位不掉。”常见三类原因：

安全回路没真正恢复：安全门、急停、光幕只是“看起来合上了”，实际继电器触点或安全 PLC 信号还没到。根因在，报警当然复不掉。
DB2 报警位没复位：EM 类（红色、锁存）报警必须由 Quit / RESET 清掉对应位；如果只是按了 NC 复位而没走 Quit 流程，位还挂着。
PLC 处于 STOP 需重新下载 / 运行：PLC 停机后，单纯“复位”无效。要先用 STEP 7 / TIA 把导致停机的根因排除，再把 PLC 切回 RUN（必要时重新下载 PLC 程序 / 备份）。

顺序：先确认物理条件满足 → 走 Quit / RESET 清锁存位 → 最后才把 PLC 置 RUN。跳步往往“复位秒回报警”。

八、预防性维护

定期备份三件套：PLC 程序 + 机床数据（MD）+ NC 数据。UAFEHL 多因程序 / 数据异常，有备份就能快速回退。
建报警交叉对照文档：把本机床每条 700xxx 报警号、含义、触发条件、排查步骤记成一张表（或维护在 oem_alarms_plc_*.ts 里），下次报警直接查，不靠记忆。
变更留痕：改 PLC 程序前先存版本、记改了哪一段；停机类问题多数来自“上次改了点东西”。
OB 完整性检查：确保 OB100 / OB121（及 OB82 / OB86）都已下载，避免“缺 OB 即停机”。

常见问题

840D 出现 UAFEHL 报警是什么意思？为什么它会让 PLC 停机？

UAFEHL 是 SINUMERIK 里“用户报警故障（User Alarm Fault）”的标识，不是一个具体故障代码。它是机床厂通过 PLC 用户报警机制自定义的报警；当某条被设为“停机级”的用户报警被触发时，PLC 被强制带入 STOP 模式，界面就显示 UAFEHL 加报警号。它让 PLC 停机，是因为触发它的那条用户报警在 PLC 程序里被配置成“报警即停止”，目的是在不安全或条件不满足的状态下锁住机床动作。

怎么查出是哪个报警号触发了 PLC 停止？

第一步把界面上完整报警号抄下来（如 UAFEHL 700806）；第二步用 STEP 7 / TIA 打开该机床 PLC 项目；第三步按 700xxyy → DB2 字节 = 180 + xx×8 + ⌊yy/8⌋、位 = yy mod 8 算出对应位，在线监控该位是否为 1，即可确认是哪条用户报警。报警的具体含义看机床厂提供的报警对照文档（oem_alarms_plc_*.ts），每台机床不同。

PLC CPU 上的 SF、STOP、RUN 三个指示灯分别代表什么？

以 840D（NCU 集成 S7-300 PLC）为例：SF 红灯 = 系统故障（硬件、总线或程序错误，如缺 OB121）；STOP 黄灯 = PLC 处于停止模式，程序没运行，正是 UAFEHL 后的典型状态；RUN 绿灯 = PLC 正常运行。828D 的 PLC 跑在 PPU 里（软 PLC），看 PPU 状态 LED 和诊断画面，判断思路相同。

UAFEHL 报警复位不掉，怎么处理？

先确认安全回路（安全门、急停、光幕）是否真正恢复；EM 类锁存报警要走 Quit / RESET 清对应 DB2 位，单纯 NC 复位清不掉；PLC 若在 STOP，须先排除根因再把 PLC 置 RUN，必要时重新下载备份。顺序是：物理条件满足 → Quit / RESET 清锁存位 → PLC 置 RUN，跳步会“复位秒回报警”。