4、心跳报文机制：生产者心跳定时器、消费者心跳监控、心跳COB-ID配置(0x700+NodeID)
心跳机制，说白了就是CANopen网络里的“保活”信号。每个从站设备定期往外发一个报文，告诉主站：“我还活着，没死机。” 主站如果一段时间没收到某个从站的心跳，就知道它出问题了，可以采取相应措施。
我刚开始接触CANopen时，觉得心跳就是个简单的定时器。后来在产线上调试，发现心跳超时导致主站误判从站离线，折腾了两天才找到根因。嗯，这里面的细节其实不少。
4.1 心跳报文的结构与COB-ID
心跳报文使用事件触发方式，由从站主动发送。它的COB-ID固定为：
COB-ID = 0x700 + NodeID举个例子：
- 节点ID为1的从站，心跳COB-ID = 0x701
- 节点ID为5的从站，心跳COB-ID = 0x705
- 节点ID为127的从站，心跳COB-ID = 0x77F
心跳报文的数据部分只有1个字节，表示当前节点的状态。常见状态值如下：
| 状态值 | 含义 | 说明 |
|---|---|---|
| 0x00 | 启动中 (BOOTUP) | 节点刚上电或复位后发送 |
| 0x04 | 停止 (STOPPED) | 节点处于停止状态，不参与通信 |
| 0x05 | 运行中 (OPERATIONAL) | 正常工作状态 |
| 0x7F | 预操作 (PRE-OPERATIONAL) | 允许SDO，禁止PDO |
小技巧： 我习惯在调试时先抓一个心跳报文，确认节点ID和状态值是否正确。如果心跳报文都收不到，后面的SDO、PDO调试基本没戏。
4.2 生产者心跳定时器
每个从站内部都有一个生产者心跳定时器，周期性地发送心跳报文。这个周期由对象字典中的索引0x1017配置：
索引: 0x1017
名称: Producer Heartbeat Time
数据类型: UNSIGNED16
单位: 毫秒 (ms)
默认值: 0 (禁用心跳)配置规则很简单：
- 0：禁止发送心跳
- 1~65535：心跳周期，单位毫秒
实际项目中，常用的心跳周期有：
- 100ms：对实时性要求高的场合，比如伺服驱动器
- 500ms：大多数工业现场的标准配置
- 1000ms：传感器、IO模块等非实时设备
注意： 我曾经遇到一个坑——把心跳周期设为10ms，结果总线负载飙升，导致其他报文丢帧。心跳周期不要设得太短，一般不低于50ms。
4.3 消费者心跳监控
主站（或其他监控节点）需要配置消费者心跳监控，才能检测从站是否离线。这个功能由对象字典索引0x1016控制：
索引: 0x1016
名称: Consumer Heartbeat Time
数据结构: 每个子索引包含一个节点ID和超时时间
格式: [节点ID(高字节)][超时时间(低2字节)]
单位: 毫秒每个子索引的格式如下：
| 位域 | 长度 | 说明 |
|---|---|---|
| 高字节 | 8位 | 被监控的节点ID (1~127) |
| 低2字节 | 16位 | 超时时间，单位ms |
举个例子：
子索引1: 0x01 0x000003E8
含义: 监控节点ID=1，超时时间=1000ms超时时间的计算有个经验公式：
超时时间 ≥ 生产者心跳周期 × 3为什么是3倍？因为要容忍偶尔的丢包或延迟。我一般设成4倍，留点余量。
核心逻辑： 消费者心跳监控的工作原理是：主站收到从站的心跳后，重置定时器。如果定时器溢出（超过设定的超时时间），就触发心跳事件，通知应用层该节点离线。
4.4 心跳COB-ID的配置细节
虽然心跳COB-ID默认是0x700+NodeID，但CANopen允许通过对象字典0x1014修改：
索引: 0x1014
名称: COB-ID Heartbeat
数据类型: UNSIGNED32
默认值: 0x700 + NodeID这个值的高位有特殊含义：
| 位 | 含义 |
|---|---|
| 31 | 1=禁止心跳，0=启用心跳 |
| 30 | 保留，必须为0 |
| 29 | 1=使用29位CAN ID，0=使用11位CAN ID |
| 28~0 | COB-ID值 |
说实话，我很少改这个值。除非遇到特殊需求，比如多个从站共用同一个心跳COB-ID（不推荐），或者需要兼容某些老设备。
避坑指南： 我曾经为了省COB-ID资源，把两个从站的心跳COB-ID改成一样的。结果主站收到心跳后不知道是谁发的，直接报错。每个节点的心跳COB-ID必须唯一。
4.5 心跳机制流程图
下面这张图展示了从站心跳的生产与消费全过程：
4.6 心跳机制的调试方法
调试心跳问题时，我一般按以下步骤排查：
- 确认心跳周期：读取从站0x1017的值，看是否非零
- 抓取心跳报文：用CAN分析工具过滤0x700+NodeID，看是否周期性出现
- 检查状态值：确认心跳报文的数据字节是否为0x05（运行中）
- 验证超时配置：读取主站0x1016，确认超时时间是否合理
- 模拟丢包：手动拔掉从站CAN线，看主站是否在超时后触发心跳事件
实战经验： 我调试时常用一个技巧——在从站代码里加一个调试串口，打印心跳发送的时刻。如果心跳定时器正常，但CAN总线上收不到，那问题大概率在CAN收发器或物理层。
4.7 常见故障与定位
| 故障现象 | 可能原因 | 排查方法 |
|---|---|---|
| 收不到心跳 | 0x1017=0，或节点未进入OPERATIONAL | 检查对象字典，确认NMT状态 |
| 心跳周期不对 | 定时器精度问题，或代码配置错误 | 用示波器或CAN分析仪测量实际间隔 |
| 主站误报离线 | 超时时间设得太短 | 将超时时间改为心跳周期的3~4倍 |
| 心跳COB-ID冲突 | 两个节点使用了相同的COB-ID | 检查0x1014配置，确保唯一性 |
心跳机制虽然简单，但它是整个CANopen网络健康监测的基石。心跳配置不对，后面的SDO、PDO调试都会受影响。我个人建议，在项目初期就把心跳调通，后面能省不少事。