CANopen 节点调试：从 EDS 到设备联调与验收
BMCLI 的 CANopen 能力可以将设备定义、对象读写与网络观察结合起来，帮助工程师完成节点接入和联调。本篇以机器人执行器为例，介绍怎样让 AI 将这些检查组织成专用工具和验收报告。
设想一台机器人的机械与电气部分已经装好，控制团队收到驱动器的 EDS 和对象字典说明，需要先确认它与机器人控制器的接口定义是否一致。准备设备供电、CAN 接线、BUSMUST 分析仪、EDS 和预期节点号，AI 就可以借助 BMCLI 完成被动观察与指定对象读取。
本次检查不使能运动，也不修改驱动参数。完成身份、状态与 PDO 对照后，再根据设备手册安排参数调整或控制实验。随文使用教学节点的数据展示方法，机器人型号、实际对象含义和运动条件由项目资料提供。
图 10-1 设备定义、主动读取与被动观察，三种信息各有来源。工程关系示意。
给 AI 的输入：描述节点检查任务
Section titled “给 AI 的输入：描述节点检查任务”输入为设备 EDS、Bench 中的 canopen-can 网络，以及期望节点号和对象清单。下面明确授权被动观察与指定对象读取，参数写入不在此次任务内。
请使用 BMCLI，根据 tutorial-node.eds，为 canopen-can 上的 Node-ID 1 生成一份节点调试报告。连接信息取自项目 Bench。先被动观察 5 秒，汇总 Boot-up、Heartbeat、PDO 和 EMCY；随后读取 Node 1 的身份对象、0x1017 和 0x2000，并比较在线 TPDO1/RPDO1 与 EDS。此次仅执行这些观察与读取，不写参数，也不切换 NMT 状态。请将 EDS 定义值、设备读取值和被动观察结果分别标明并排展示，附上差异说明与相关记录。
AI 先检查 EDS，再组织观察、读取和比较。随文 EDS 与验收计划提供了教学定义，实际运行还需要匹配的 CANopen 节点。
成品与效果：把三类信息放到一起
Section titled “成品与效果：把三类信息放到一起”AI 应输出一份定义值、在线值和观察结果并列的调试报告。下面用教学节点展示报告结构与关键数据，便于理解不同来源的信息。
本例使用 Node-ID 1 和公开教学 EDS。节点身份、Heartbeat、厂商对象与 PDO 可以整理为以下对照：
| 项目 | EDS 中的示例定义 | 在线需要确认的内容 |
|---|---|---|
| 身份 0x1018 | Vendor=1、Product=2 等 | 当前节点的实际身份 |
| Heartbeat 0x1017 | 默认 1000 ms | 在线参数与实测周期 |
| 厂商对象 0x2000 | U8，范围 0..255 | 当前值及访问结果 |
| TPDO1 | COB-ID 0x181，映射一个字节 | 在线通信与映射对象 |
| RPDO1 | COB-ID 0x201，映射一个字节 | 接收映射是否符合项目要求 |
| EMCY | 错误事件解析 | 观察窗口内发生的事件 |
这里很容易遇到一种情况：EDS 写着默认 1000 ms，节点却已配置成 500 ms。将默认值、在线值和实际周期并排列出，工程师就能判断这是正常配置差异，还是需要处理的问题。
实现解析：BMCLI 在成品中承担的工作
Section titled “实现解析：BMCLI 在成品中承担的工作”下面结合关键调用说明应用的实现方式。AI 生成的程序将这些调用组织成完整流程，并处理返回结果与任务收尾。
从被动观察到主动读取
Section titled “从被动观察到主动读取”# 加载数据库并登记资源名，供后续解析或协议操作复用。bmcli database load --file=tutorial-node.eds ` --name=tutorial-node --type=canopen# 列出 EDS 对象字典，查看设备定义而非实时读回值。bmcli canopen object list --database=tutorial-node --format=json# 查看 EDS 中的 PDO 定义，为在线对照准备基准。bmcli canopen pdo list --database=tutorial-node --format=json
# 启用 CANopen 解析与事件记录，并设置预期心跳周期。bmcli canopen enable --channel=canopen-can --database=tutorial-node ` --heartbeat-producer=1:1000 --history-events=4096# 被动观察五秒，汇总出现的节点与网络事件。bmcli canopen node discover --channel=canopen-can --duration=5 --format=json# 查看指定节点的心跳状态与超时信息。bmcli canopen heartbeat status --channel=canopen-can --node-id=1 --format=json
# 通过对象读取取得节点身份，与项目期望比较。bmcli canopen node identify --channel=canopen-can --node-id=1 ` --database=tutorial-node --format=json# 主动读取教学对象 0x2000:0，取得设备当前值。bmcli canopen sdo read --channel=canopen-can --node-id=1 ` --index=0x2000 --sub-index=0 --database=tutorial-node --format=json# 将在线 PDO 映射与 EDS 比较，检查定义和设备配置是否一致。bmcli canopen pdo verify --channel=canopen-can --node-id=1 ` --database=tutorial-node --direction=tpdo --pdo-number=1 --format=jsonenable 建立被动解析视图，discover 从自然流量中发现节点。身份读取、SDO 读取和 PDO verify 则会向指定节点发送请求。把两类动作分开，报告也能清楚说明信息从哪里来。
EDS 提供对象类型、访问权限和映射定义，BMCLI 处理 CANopen 通信与结果解释。AI 生成的工具可以围绕对象名和工程含义组织界面，而不是让用户反复查 COB-ID 与数据字节。
pdo verify --apply 将验证结果记入 BMCLI 本地观察会话，供后续观察使用。调整 ECU 的节点映射时，按设备要求组织 SDO 写入和状态切换。
调试时怎样判断更准确
Section titled “调试时怎样判断更准确”Heartbeat 的 1000 ms 在这里是示例基准，实际项目可先读取 0x1017，再结合设备要求设置期限。观察窗口内没有 Boot-up，也可能只是节点早已启动；将“未观察到事件”与“节点故障”分别记录即可。
有了身份匹配和只读结果，再安排写入测试会更清晰。SDO 写入后若响应中断，可以先读回对象确认完成情况；NMT 切换则明确目标节点，便于控制影响范围。
进一步探索：从调试记录到设备验收
Section titled “进一步探索：从调试记录到设备验收”这个案例还可以继续完善，也可以延伸到更多工作中。您可以从感兴趣的一项出发，与 AI 讨论下一步的实现。
按产品型号生成验收配置
Section titled “按产品型号生成验收配置”如果实验台会更换不同型号的节点，可以请 AI 将期望身份、关键对象值、Heartbeat 要求和 PDO 定义整理成型号配置。执行时通过 BMCLI 读取实际值，再与配置比较，报告分别呈现“EDS 如何定义”和“设备实际返回什么”。对需要写入或改变 NMT 状态的检查，按设备手册设置独立步骤与操作条件。这样一份调试记录就能成长为可复用的来料检查或台架验收工具。
给 EMCY 事件补上现场上下文
Section titled “给 EMCY 事件补上现场上下文”收到一条 EMCY 后，错误码本身往往只说明了结果。可以请 AI 在观察期间保留 PDO 与 Heartbeat 记录，将事件时间附近的帧和已知状态附到报告中，再按厂商错误定义解释。确有必要的对象读取由诊断流程安排，并注明它是在事件后取得的状态。最终得到的不是孤立的告警列表，而是一组便于继续定位的事件记录。
以下文档介绍本篇涉及的接口；具体参数可通过本机 JSON Help 查询。