📚 课程目录第4章心跳与节点守护

4. 心跳与节点守护：心跳报文丢失或周期异常导致主站误判从站状态

心跳机制，说白了就是从站定期跟主站喊一声“我还活着”。

主站如果没听到，就会认为这个从站挂了，然后触发相应的错误处理。但问题来了——如果心跳报文本身出了问题呢？

我在现场调试时遇到过好几次：从站明明跑得好好的，主站却报“节点丢失”。查了半天，发现是心跳周期配置错了，或者报文被总线上的干扰吞掉了。

在CANopen协议里，每个节点可以同时扮演两个角色：

角色	对象字典索引	说明
心跳生产者	0x1017	主动发送心跳报文，告诉别人自己还活着
心跳消费者	0x1016	监听指定节点的心跳，超时则判定节点丢失

一个节点可以既是生产者又是消费者。比如，从站向主站发心跳（生产者），同时监听另一个传感器的状态（消费者）。

关键点：心跳生产者只负责发，不负责收。心跳消费者只负责收，不负责发。两者通过COB-ID匹配。

心跳报文是CAN标准帧，数据域只有1个字节——即节点的NMT状态。

COB-ID = 0x700 + Node-ID
Data  = 0x00 (Boot-up) / 0x04 (Stopped) / 0x05 (Operational) / 0x7F (Pre-operational)

举个例子：节点ID为3的从站，在Operational状态下发送的心跳报文：

CAN ID: 0x703
Data:   0x05

嗯，这里要注意：心跳报文不包含时间戳，也不包含序列号。主站判断节点是否存活，纯粹靠“有没有在规定时间内收到下一帧”。

对象字典0x1017定义心跳生产周期，单位是毫秒。

0x1017值	心跳周期	说明
0	禁止	节点不发送心跳
1–65535	对应毫秒数	节点按此周期发送心跳

我个人习惯把心跳周期设在100ms到1000ms之间。太短了总线负载高，太长了主站反应慢。

经验之谈：如果从站有实时性要求，建议设200ms。既不会占用太多总线带宽，主站也能在200ms内感知节点丢失。

0x1016是一个数组，每个条目包含三个信息：

每个条目32位：
Bit 31–24: 保留
Bit 23–16: 消费者节点ID（0表示所有节点）
Bit 15–0:  超时时间（毫秒）

举个例子，主站要监听节点3的心跳，超时时间设为500ms：

0x1016[0] = 0x000301F4
// 0x01F4 = 500ms

超时时间的计算规则：实际超时 = 生产者周期 × 消费者超时系数。大多数实现里，超时系数是3。也就是说，生产者周期200ms，消费者超时就是600ms。

避坑指南：我曾经遇到一个案例，生产者周期设了100ms，消费者超时设了150ms。结果总线偶尔有延迟，主站频繁误报节点丢失。后来我把消费者超时改成300ms（3倍周期），问题就解决了。

为什么会丢失心跳？我总结了几个常见原因：

诊断方法，我一般按这个顺序来：

我的习惯：先用CAN工具连续抓30秒心跳，统计最大间隔和最小间隔。如果最大间隔超过配置周期的1.5倍，说明生产者定时器有问题。

节点守护（Node Guarding）是CANopen早期的机制，心跳是后来引入的替代方案。两者不能同时使用。

现在的主流实现都推荐用心跳。节点守护已经很少用了，除非你要兼容非常老的设备。

下面这张图展示了心跳生产者与消费者之间的交互逻辑：

根据我多年的调试经验，给出几条实用建议：

小技巧：如果你用PCAN-View抓心跳，可以设置一个“周期性报文”过滤器，只显示0x700+NodeID的报文。这样一眼就能看出心跳是否正常。

心跳机制看似简单，但配置不当引发的故障非常隐蔽。你想想看，从站明明在正常工作，主站却认为它挂了，然后触发紧急停机——这种问题在产线上可是要背锅的。