一、看门狗概述：什么是看门狗、看门狗在运动控制中的作用、硬件看门狗与软件看门狗的区别

1.1 什么是看门狗？一个简单的比喻

看门狗，英文叫 Watchdog Timer（WDT）。

说白了，它就是一个定时器。你必须在规定时间内去“喂狗”——也就是复位这个定时器。如果你没及时喂，狗就“叫”了，系统会被强制复位。

我刚开始接触运动控制时，觉得这东西很简单。不就是个定时器嘛。直到有一次，一台三轴雕刻机在加工中途突然“飞车”，刀具直接扎进工件里……嗯，从那以后，我再也不敢小看看门狗了。

看门狗的核心逻辑就三条：

• 启动定时器：设定一个超时时间，比如 100ms
• 定期喂狗：在超时前，程序主动复位定时器
• 超时触发：如果没喂狗，系统执行预设的恢复动作（通常是复位）

1.2 看门狗在运动控制中的作用

运动控制对实时性要求极高。你想想看，一个伺服电机每 1ms 就要更新一次位置指令。如果 CPU 卡住了 10ms，电机可能已经跑偏了几个毫米。

我个人习惯把看门狗在运动控制中的作用归纳为三点：

1. 检测 CPU 死锁或跑飞：这是最基础的功能。程序跑飞了，喂狗线程自然就停了，狗叫，复位。
2. 检测实时任务超时：运动控制中，位置环、速度环、电流环都有严格的执行周期。如果某个周期超时，看门狗可以及时介入。
3. 检测通信中断：比如上位机与驱动器之间的 EtherCAT 通信断了，看门狗可以触发安全停机。

我曾经在一个六轴机器人项目中，把看门狗超时设成了 500ms。结果发现，机器人偶尔会莫名其妙复位。排查了很久才发现，是某个非实时任务偶尔占用了 CPU 超过 500ms。后来我把超时改成 200ms，同时优化了任务调度，问题就解决了。

1.3 硬件看门狗 vs 软件看门狗

很多初学者会问：看门狗不就是个定时器吗？为什么还要分硬件和软件？

嗯，这里要注意。虽然原理相似，但它们的可靠性天差地别。

对比项	硬件看门狗	软件看门狗
实现方式	独立硬件芯片或 MCU 内部外设	操作系统或应用程序中的定时器
可靠性	高，不受 CPU 跑飞影响	低，CPU 跑飞时软件看门狗也可能失效
响应速度	微秒级	毫秒级（取决于任务调度）
独立性	完全独立于主 CPU	依赖主 CPU 运行
成本	需要额外硬件，成本较高	零硬件成本
典型应用	安全关键系统（如机器人、CNC）	非安全关键系统（如数据采集）

硬件看门狗，说白了就是一个独立的“监工”。即使主 CPU 完全死机，它依然能正常工作。我见过最极端的案例：某国产 MCU 内部硬件看门狗在 CPU 内核电压跌落时也跟着失效了。从那以后，我在安全等级高的项目中，一律使用外部独立看门狗芯片。

软件看门狗呢？它更像是一个“自我检查”。比如在 FreeRTOS 中，你可以创建一个高优先级任务专门负责喂狗。但问题是——如果操作系统本身崩溃了，这个任务还能运行吗？

1.4 看门狗的工作流程

下面这张图展示了一个典型的看门狗工作流程。我特意用 SVG 画出来，方便你理解整个逻辑链条。

从这张图你可以看到：正常流程是一个闭环——主循环运行，定期喂狗。一旦喂狗失败，系统就会走异常分支，触发复位。

1.5 实际项目中的看门狗设计思路

我在设计运动控制系统的看门狗时，通常会考虑以下几个层次：

• 第一层：硬件看门狗——使用外部独立芯片（如 MAX706），超时时间 1.6s。这个时间足够长，避免误触发；又足够短，能在系统死机后快速恢复。
• 第二层：操作系统看门狗——在 RTOS 中创建一个喂狗任务，优先级设为中等。这个任务会检查其他关键任务是否按时“签到”。
• 第三层：应用层看门狗——在运动控制算法中，检查位置环、速度环是否在预期时间内完成。如果某个周期超时，先尝试软件恢复，不行再触发硬件复位。

1.6 小结

看门狗不是什么高深的技术，但它往往是运动控制系统稳定性的最后一道防线。硬件看门狗保底，软件看门狗精细监控，两者配合使用才能做到万无一失。

记住一句话：在运动控制中，不是“会不会出问题”，而是“什么时候出问题”。看门狗就是那个帮你兜底的人。

---