4. NMT主站与从站：谁说了算？

NMT（Network Management）状态机，说白了就是CANopen网络里设备的“生老病死”管理机制。主站负责发号施令，从站负责听话执行。但实际项目中，主从关系远没这么简单——我见过不少工程师把主站当上帝，结果网络一乱就抓瞎。

咱们先理清一个概念：NMT主站 ≠ 应用主站。NMT主站只管状态切换和网络管理，不负责处理PDO/SDO数据。很多设备既当NMT主站又当应用主站，但职责必须分开。

4.1 主站职责：状态控制与网络管理

NMT主站的核心职责就两件事：控制从站状态和管理网络节点。我习惯把主站比作“交通警察”——它不决定车往哪开，但决定车能不能上路、要不要靠边停。

4.1.1 状态控制

主站通过发送NMT命令（CAN-ID为0x000）来切换从站状态。命令格式很简单：

COB-ID: 0x000
数据字节1: CS（命令选择符）
数据字节2: Node-ID（目标节点，0x00表示所有节点）

常用的CS命令码：

4.1.2 网络管理

主站还要负责：

• 节点监控：通过心跳（Heartbeat）或节点守护（Node Guarding）检测从站是否存活
• 启动同步：发送SYNC报文触发所有从站同步采样
• 错误处理：收到Emergency报文后决定是否复位节点

我个人建议优先用心跳机制。节点守护需要主站轮询，网络负载大；心跳是从站主动发，主站只需监听。你想想看，一个网络里几十个从站，主站一个个轮询得多累？

4.2 从站响应机制：不是所有命令都照单全收

从站收到NMT命令后，必须按状态机规则响应。但很多从站设计有“小脾气”——比如某些从站不允许从Operational直接跳到Stopped，必须先经过Pre-operational。

标准状态转换规则：

Initialisation → Pre-operational (自动)
Pre-operational → Operational (收到0x01)
Operational → Pre-operational (收到0x80)
Operational → Stopped (收到0x02)
Pre-operational → Stopped (收到0x02)
Stopped → Pre-operational (收到0x01)
任何状态 → Initialisation (收到0x81或0x82)

从站收到命令后的典型响应：

• 状态切换成功：更新内部状态机，发送心跳（如果使能）
• 命令无效：忽略或发送错误报文（取决于实现）
• 复位命令：执行硬件复位，重新初始化OD

4.3 多主站场景处理：谁才是老大？

CANopen标准里，一个网络可以有多个NMT主站。但实际项目中，我强烈建议只保留一个活跃主站。为什么？因为多个主站同时发NMT命令，从站会懵——到底听谁的？

多主站场景常见于：

• 冗余系统：主站挂了，备用主站接管
• 调试工具：工程师用CAN分析仪临时当主站
• 网关桥接：两个CAN网络通过网关互联，每个网络有自己的主站

4.3.1 主站选举机制

如果非要搞多主站，得有个选举规则。我见过两种方案：

我个人倾向静态分配。动态选举看着高大上，但我在一个军工项目里吃过亏——两个主站同时发选举报文，CAN总线冲突导致网络瘫痪。从那以后，我对动态选举就敬而远之了。

4.3.2 从站的多主站处理

从站收到多个主站的NMT命令时，标准做法是：谁的命令先到就听谁的。但这里有个陷阱——如果主站A发“启动”，主站B发“停止”，从站会反复切换，导致网络震荡。

4.4 知识结构图：NMT主从关系全景

下面这张图帮你理清主站、从站、状态机之间的关系：

4.5 实战要点总结

最后，我把本章核心要点列出来，方便你对照检查：

1. 主站职责清晰：只管状态和网络，别掺和PDO/SDO
2. 从站响应要规范：非法命令直接忽略，别自作主张
3. 多主站慎用：能单主就别双主，非要双主就静态分配
4. 心跳优于守护：减少总线负载，调试也方便
5. 复位命令选0x81：比0x82更彻底，避免OD残留