2. 主站与从站的关系：主站如何通过心跳感知从站状态？从站失联后的典型处理流程

好，我们接着聊。上一章讲了心跳是什么，这一章咱们深入看看主站和从站之间到底怎么“对话”的。说白了，主站就像一个车间主任，从站就是底下干活儿的工人。主任不可能每秒钟都盯着每个工人，但他得知道谁在好好干活，谁掉线了。

心跳机制，就是主任用来“点名”的方式。

2.1 主站如何“感知”从站状态？

主站感知从站状态，靠的不是玄学，是实实在在的协议和定时器。我习惯把这种感知分为三个层次：

1. 链路层心跳：这是最底层的。比如 EtherCAT 或者 PROFINET，协议本身就有物理层的连接检测。线断了、端口掉了，主站立马知道。但这太粗糙，只能知道“线还在不在”。
2. 应用层心跳：这就是我们课程的核心。主站和从站约定好，每隔固定时间（比如 10ms）交换一个“我还活着”的信号。这个信号可以是一个专用的心跳报文，也可以藏在普通的数据帧里。
3. 看门狗（Watchdog）：这是从站自己的“自救”机制。从站内部有个定时器，如果超过设定时间没收到主站的任何指令，它就认为主站挂了或者自己失联了，然后自动进入安全状态。

我在一个项目中遇到过这样的情况：现场总线偶尔会有干扰，导致一两个报文丢了。如果主站一丢包就判定从站挂了，那整个产线就得频繁停机。所以，实际工程里很少用“丢一次就算挂”的策略。

2.2 心跳超时的判定策略

主站怎么判断“超时”？不是简单地看一次没回应。我常用的策略有三种：

策略名称	实现方式	适用场景
固定超时	设定一个固定时间 T，超过 T 没收到心跳就报警	网络稳定、对实时性要求极高的场合
连续丢失计数	连续丢失 N 个心跳包才判定失联（比如 N=3）	现场干扰较多、允许短暂抖动的场合
动态超时	根据历史通信延迟动态调整超时时间	网络负载变化大的复杂系统

我个人最常用的是连续丢失计数。为什么？你想想看，工业现场电磁干扰太常见了，偶尔丢一两个包很正常。如果因为一次丢包就触发急停，那操作工得疯掉。我曾经调试一条包装线，就因为超时次数设得太严，一天能误报警十几次。后来改成连续丢 3 次才算失联，世界清净了。

2.3 从站失联后的典型处理流程

好，现在主站判定从站失联了。接下来怎么办？不是直接停机那么简单。我总结了一个标准流程，分五步走：

1. 检测与确认：主站连续 N 次没收到心跳，确认从站失联。注意，这里要排除主站自己网卡故障的情况。
2. 报警与记录：主站立即触发报警，把失联从站的 ID、时间、错误码写入日志。这一步很重要，事后排查问题全靠它。
3. 安全输出：主站向失联从站对应的输出点发送安全值。比如把控制阀门的输出置为 0，或者让电机停止。这一步是为了防止从站“死机”后输出保持错误状态。
4. 系统降级或停机：根据工艺要求，决定是让系统降级运行（比如只停掉失联的那一段），还是全线急停。
5. 恢复与重连：从站恢复后，主站需要重新建立通信，同步数据，然后恢复正常运行。

嗯，这里要注意第三步。很多新手工程师只关注报警，忘了把输出置为安全值。结果从站虽然失联了，但它的输出还保持着最后的状态，比如一个加热器还在全功率加热，那就危险了。

2.4 主从站状态机转换

为了让大家更直观地理解，我画了一张状态机图。主站和从站之间的状态转换，其实就是一个有限状态机。

2.5 实际工程中的处理细节

上面讲的是通用流程。实际工程里，还有一些细节要注意：

• 心跳周期怎么设？ 我一般建议设在 10ms~100ms 之间。周期太短，CPU 负载高；周期太长，故障响应慢。对于普通 I/O 从站，50ms 是个不错的起点。
• 安全输出值怎么定？ 这个要跟工艺工程师一起确认。数字量输出一般置 0，模拟量输出置 0 或保持最后值？我倾向于置 0，因为“没有信号”比“错误信号”更安全。
• 日志记录什么？ 至少记录：失联时间、从站 ID、当前心跳计数值、失联前的最后几个数据包。这些信息对排查是线缆问题还是从站死机，非常有帮助。