干了十几年嵌入式，从单片机裸机一路干到多轴运动控制，CAN总线始终是绕不开的老伙计。尤其是这几年伺服驱动、机器人、汽车电子大量上CANopen协议栈，很多人问我：“CAN和CANopen到底啥关系？”“PDO和SDO怎么选？”“报文中那个ID号到底什么意思？”这些问题如果只看数据手册，很容易被一堆晦涩的术语劝退。
这篇文章我打算系统地把CAN和CANopen拆开讲清楚，从物理层的电平、终端电阻，到数据链路层的帧格式、仲裁机制，再到CANopen的NMT、PDO、SDO、对象字典，最后落到伺服驱动控制、Python上位机开发和现场调试的真实案例。不管你是在校学生、刚入行的工程师，还是被现场总线问题折磨的调试老手，照着这篇文章的思路走，基本能把CAN和CANopen这套东西串起来用。
1. 物理层与总线基础：CAN为什么能在工业现场站稳脚跟
很多初学者上来就直接啃CANopen协议，结果对象字典还没搞明白，就被现场的总线信号问题整懵了。其实CAN能成为工业通信的主流，最核心的功劳在物理层。这一节先把电流、电压、线缆这些“硬骨头”啃明白，后面所有协议层的分析才有根基。
1.1 差分信号传输：CAN抗干扰的底层逻辑
CAN总线用的是差分信号，两根线分别叫CAN_H和CAN_L。发送端让这两根线上的电压互为相反数，接收端只关心它们的差值。当总线处于隐性状态时，CAN_H和CAN_L都被偏置到2.5V左右，差分电压接近0V，逻辑上对应“1”；当总线被某个节点拉成显性状态时，CAN_H升到3.5V，CAN_L降到1.5V，差分电压约2V，逻辑上对应“0”。
这里关键点在于，外部电磁干扰通常以共模形式同时叠加在两根线上，差分解码时这种共模干扰会互相抵消。这就是为啥CAN能在电机旁边、变频器柜里、车身上这些电磁环境极其恶劣的地方稳定工作，而普通的RS232、TTL串口在这种条件下早就丢帧丢得没法看了。同样道理，布线时CAN_H和CAN_L必须绞合在一起，双绞线的目的就是让两根线耦合到的干扰尽量一致，提高共模抑制比。有的新手图省事把CAN线当普通电线一样走，两根线分开很远，结果干扰一大就误码，这就是物理基础没打牢。
1.2 终端电阻两端120Ω：阻值怎么算、中间节点该不该接
CAN总线的线缆特性阻抗典型值是120Ω。当信号在线缆中传播时，如果遇到阻抗不连续的点，就会发生反射，反射波会和原信号叠加，造成波形畸变、电平误判。所以标准做法是在物理总线的最远两端各并联一个120Ω终端电阻，这样信号到达末端时能量被吸收掉，不会反射回来。
实测时用万用表量CAN_H和CAN_L之间的电阻，应该在60Ω左右（两个120Ω并联）。如果量出来是120Ω，说明有一端漏接了；如果接近0Ω，说明某个终端电阻短路或者线缆有问题；如果是一个小于60Ω的阻值，大概率是中间某个节点也接了终端电阻，并联后等效阻抗被拉低了。很多人想当然把所有节点都接上120Ω，结果总线负载加重，信号幅值下降，反而容易出现通信不稳定。
注意：终端电阻一定要接在物理线缆的最末端，而不是控制柜里随便找个节点接。多分支的现场总线如果末端不明确，宁可把总线改成菊花链结构，也要确保终端电阻位置正确。
1.3 波特率与采样点：现场总线不稳定的隐藏变量
CAN总线的波特率常见的有125kbps、250kbps、500kbps、1Mbps。波特率越高，单位时间传输的位越多，但每一位占用的时间越短，对线缆长度、节点时钟精度、信号质量的要求就越苛刻。比如1Mbps下，一位只有1微秒，线缆超过几十米就可能因为传播延迟导致采样错误；而125kbps下，轻松可以跑到几百米。
除了波特率，采样点的设置同样关键。CAN控制器在一位的周期内会选择一个时间点采样总线电平，这个时间点相对于位开始的百分比就是采样点。常规建议是75%到87.5%，比如500kbps时把采样点设为80%，意味着在一个位周期的80%处采样。采样点太靠前，可能还没等信号稳定就采了；太靠后，留给同步和建立时间的安全余量不足。不同厂家的设备对采样点要求不一样，两边的采样点差异过大时，即使波特率相同也可能偶发丢帧，这一点在混合使用不同品牌设备的现场尤其常见。
2. 数据链路层核心机制：帧、仲裁与错误恢复
物理层搞定了，接下来看CAN协议栈的第二个层次：数据链路层。这一层负责把数据封装成帧、处理总线冲突、检测并恢复错误。很多工程师只关注应用层数据，对帧结构不熟悉，出了问题就只会“换一台设备试试”，了解了这一层，定位问题的效率会明显提升。
2.1 CAN报文帧结构与ID到底代表什么
CAN总线上的数据以报文为单位传输，标准帧长度不固定，但核心结构包括帧起始、仲裁段、控制段、数据段、CRC段、ACK段和帧结束。仲裁段里的报文ID是很多人最早接触也最困惑的地方。
报文ID是什么？它决定了两件事：优先级和身份标识。ID越小，优先级越高。比如两个节点同时抢占总线，ID小的节点会赢得仲裁继续发送，ID大的节点自动退出发送，等总线空闲后再重试。因为CAN仲裁机制中显性位（0）可以覆盖隐性位（1），所以ID编码中低数值的报文天然优势更大。我们在设计项目时，会把实时性要求高的报文（比如伺服使能、急停命令）分配比较小的ID，把参数类、诊断类的报文分配大ID，这个是CAN应用层设计的基本原则。
另外需要特别记住：CAN报文中的ID不完全是“发给谁”的地址，它更像一个“内容标签”。比如0x181这个ID表示“节点1的发送PDO1”，0x201表示“节点2的发送PDO1”，这种把报文按内容语义来组织的设计，正是CANopen能实现分布式控制的基础。
2.2 仲裁机制：为什么小ID先发，CSMA/CA如何避免冲突
CAN总线的仲裁机制属于CSMA/CA，也就是“载波监听多路访问/冲突避免”。每个节点在发送前先监听总线，发现总线空闲才开始发送；发送的同时又一直在监测总线上的实际电平，如果自己发出的电平是隐性位（1），但总线上却读到显性位（0），说明有其他更高优先级（更小ID）的节点正在发送，自己立刻退出，下一次再尝试。
整个过程逐位比较，直到分出胜负为止。这种机制的好处是：高优先级的报文几乎不会因为低优先级报文占用总线而等待，实时性有保障。此外，仲裁过程不会破坏高优先级报文的完整性，它是在传输过程中自动完成的，不需要额外的“令牌”或“主机轮询”。
这和以太网的CSMA/CD完全不一样。以太网是“先听再发，冲突后截断退避随机时间再重发”，CAN是“一边发一边听，冲突的时候低优先级主动让路”。所以CAN总线上同时有个节点发10ms周期的实时控制报文，又有个节点发100ms周期的诊断报文，实时报文基本不会被诊断报文阻塞，这就是现场控制系统中CAN比普通串口或者以太网更受青睐的原因。
2.3 错误计数器、错误状态与bus-off自动恢复
CAN协议里的容错机制是一大亮点。每个节点都有两个错误计数器：发送错误计数（TEC）和接收错误计数（REC）。当节点检测到错误时，计数器会增加；当节点成功收发报文时，计数器会减少。根据计数值，节点会处于三种状态之一：错误主动、错误被动、总线关闭（bus-off）。
- 错误主动：TEC和REC都小于128，可以正常发送和接收，出错时发送“主动错误帧”（6个显性位）。
- 错误被动：TEC超过127或REC超过127，出错时只能发“被动错误帧”（6个隐性位），发送前需要等待总线空闲。
- 总线关闭：TEC超过255，节点会切断与总线的联系，既不能发送也不能接收，避免一个故障节点持续破坏总线通信。
bus-off自动恢复有硬件和软件两种方式。有些控制器支持自动恢复，在检测到128次总线空闲信号后重新上线；有些则需要应用层软件主动复位。在实际项目里，如果某个节点突然“失踪”，一去查错误寄存器往往是bus-off，这种情况光靠自动恢复不一定靠谱，关键是要找到导致TEC飙升的根因，比如终端电阻异常、波特率不匹配、线缆过长导致信号质量差等。
2.4 CAN FD与CAN 2.0：什么时候升级、怎么混用
CAN FD是CAN 2.0的升级版，全称CAN with Flexible Data-rate。它在保留原有仲裁机制和物理连接方式的基础上，做了两处关键改进：一是数据场长度从最多8字节扩展到64字节；二是在数据段采用更高速率传输（BRS位控制速率切换），仲裁段的速率保持不变，数据段可以提升到5Mbps甚至8Mbps，总吞吐量大幅提升。
但要注意，CAN FD帧和CAN 2.0标准帧是不兼容的，老设备无法识别CAN FD报文。在实际项目中，如果总线上同时存在CAN FD节点和CAN 2.0节点，需要仔细考虑兼容策略。现在很多新出的控制器和驱动都支持CAN FD，但现场的老设备未必支持。我的建议是，如果整个总线设备都确认支持CAN FD，且数据吞吐量确实是瓶颈，可以升级到CAN FD；如果总线上还有老节点，那就老老实实用CAN 2.0，避免一锅粥。
提示：CAN FD与CAN 2.0共享物理层特性（120Ω终端电阻、差分信号），所以线缆布线部分不用重做，但要关注线缆质量，高速率下对线缆的带宽要求更高。
3. CANopen协议栈拆解：对象字典、NMT、PDO和SDO
有了CAN物理层和帧格式的理解，接下来把协议栈抬高到应用层。CANopen是基于CAN总线的应用层协议，它没有改变CAN的帧结构，而是在CAN报文的基础上定义了一套标准化的设备描述、网络管理、数据传输机制。为什么要用CANopen？因为裸CAN报文只关心数据是否送达，却不解决“这个数据是干什么用的”“怎么控制节点上下线”“怎么区分实时数据和参数数据”这类问题，而CANopen把这一整套规则都定义好了。
3.1 CANopen分层结构与对象字典：0x1000-0x9FFF都是什么
CANopen的核心数据结构叫对象字典（Object Dictionary，OD），它相当于设备的“寄存器地图”。每个对象字典条目都有一个16位索引和8位子索引，设备的所有参数、状态、指令都映射到对象字典中的某个地址。
对象字典的索引区间有约定俗成的分工：0x1000到0x1FFF存放设备通用信息（设备类型、错误寄存器、心跳周期、NMT设置等）；0x2000到0x5FFF是厂家特定区域；0x6000到0x9FFF是标准化设备行规区域，比如伺服驱动器按CiA 402行规定义的控制字、状态字、目标位置、实际位置等对象都分布在这个区间。
举个例子，0x1017是心跳生产周期（Heartbeat Producer Time），0x1800是TPDO1通信参数，0x1A00是TPDO1映射参数。写CANopen代码时，配置节点本质就是在操作这些对象字典条目。这就是为什么很多工程师拿到一个支持CANopen的伺服驱动器，第一件事就是翻它的对象字典手册——搞懂了OD，就搞懂了这个设备的一切。
3.2 NMT网络管理：从预操作到操作状态怎么切换
NMT（Network Management）是CANopen的“总开关”。一个CANopen网络中通常会有一个NMT主机，负责管理其他节点的状态。CANopen节点有四种主要状态：初始化（Initialization）、预操作（Pre-operational）、操作（Operational）、停止（Stopped）。
节点上电后自动进入初始化状态，完成硬件配置后进入预操作状态。在预操作状态下，节点只允许SDO通信和心跳报文，不允许PDO实时数据传输。NMT主机发送启动命令后，节点才进入操作状态，此时PDO才生效，可以开始实时交换控制数据。
NMT报文用COB-ID 0发送，数据场第一个字节是要执行的服务（如0x01启动节点、0x02进入预操作、0x80停止节点、0x81复位节点），第二个字节是目标节点ID，0表示广播给所有节点。这就是调试现场时经常看到“发了启动命令之后，设备才动起来”的原因——很多第一次接触CANopen的工程师漏了NMT这个步骤，以为设备上电就能跑PDO了。
3.3 PDO实时通信：高速传输怎么配置映射
PDO（Process Data Object）用于传输实时性要求高的过程数据，如伺服的目标位置、状态字、速度等。PDO传输的特点是速度快、开销小，数据场最多8字节，而且不需要接收方应答——属于单向广播式通信。
PDO分为TPDO（发送PDO）和RPDO（接收PDO）。每个PDO都由通信参数和映射参数两部分描述。通信参数（索引0x1800-0x19FF为RPDO，0x1400-0x15FF为TPDO）定义了COB-ID、传输类型、同步周期等；映射参数（索引0x1A00-0x1BFF）则定义了这个PDO数据场里依次装的都是对象字典里的哪些字段。
配置PDO映射时要注意，映射的对象长度累加起来不能超过8字节。比如把控制字（2字节）、目标位置（4字节）、模式字（1字节）映射到一个RPDO里，一共7字节，正好放得下；如果你非要再塞一个8字节的扩展数据，就超出限制需要换方案了。很多设备支持PDO映射的动态配置，但需要在预操作状态下通过SDO改好映射参数，然后再切到操作状态让PDO真正跑起来。
PDO的触发方式也很关键。传输类型0表示同步非周期，1-240表示同步周期传输，255表示事件触发。现场最常用的组合是：同步周期模式下，所有节点收到SYNC报文后同时更新输出，实现多轴同步运动；事件触发模式下，设备快发出数据，适合传感器等非周期性信号源。
3.4 SDO参数读写：快速下载和分段传输怎么选
SDO（Service Data Object）用于访问对象字典条目，特点是可靠性高、需要确认，但开销大、速度慢。SDO采用客户端/服务器模型，服务器通常是设备节点，客户端通常是上位机或NMT主机。客户端用0x600+节点ID作为COB-ID发送请求，服务器用0x580+节点ID回复。
SDO的帧结构里，第一个字节是命令字，后面跟着索引、子索引和数据。如果传输的对象数据不超过4字节，可以使用快速传输，一条SDO报文就能完成读写；如果超过4字节，比如要下载一个很长的软件版本字符串或固件块，就要用分段传输，把一个大数据对象分成多段SDO报文依次传递，每段都要确认。
在实际调试中，伺服参数配置基本都走SDO。比如把伺服驱动器从“速度模式”切换到“位置模式”，通过SDO改写对象字典0x6060（模式选择）就行。PDO适合周期性刷新的数据，SDO适合偶发性、单次读写的参数，这个原则选型时一定要记牢。
3.5 心跳机制：节点“离线”是怎么被发现的
CANopen网络不像以太网那样每帧都带源地址，如果某个节点突然断电或者死机，其他节点怎么知道它掉线了？答案就是心跳机制。每个节点按0x1017配置的周期，定时向总线上发送一条心跳报文，COB-ID是0x700+节点ID，数据场是该节点的NMT状态值。
NMT主机或监控节点会比较心跳间隔，如果在设定的超时时间内收不到某节点的下一跳心跳，就判定该节点“心跳超时”，然后可以采取报警、急停等安全措施。这里心跳周期的设置就很讲究：周期太短，总线负载高；太长，故障感知延迟大。一般伺服控制系统的从站心跳设为100ms到200ms，主站在计算超时时间时通常要考虑通讯抖动，设为心跳周期的3倍左右比较稳妥。
注意：心跳超时和SDO超时是两码事。心跳超时是节点连续不发心跳，SDO超时是SDO请求发出后无响应。现场排查故障时先把这两个概念分开，别看到“超时”报警就以为都是总线断了。
4. CANopen高级应用：伺服控制、上位机开发与现场调试
基础概念讲完，进入真正的实战环节。这一节我把这几年在伺服控制系统里最常用的CANopen套路、Python上位机的快速实现方法，以及现场调试时踩过的坑整理一下，希望能帮大家少走弯路。
4.1 伺服驱动器CANopen控制：CSP/CSV模式与PDO映射实操
伺服驱动器的CANopen控制通常遵循CiA 402行规，这个标准把驱动器状态定义成一套状态机，包括“未就绪”“待机”“使能”“运行”等状态，并定义了一系列标准化对象，比如0x6040控制字、0x6041状态字、0x607A目标位置、0x6064实际位置、0x6060模式选择等。
以位置控制为例，最常用的是CSP（Cyclic Synchronous Position，循环同步位置）模式。上位机以固定周期（比如1ms、2ms）把目标位置通过RPDO发给驱动器，驱动器内部完成位置环、速度环、电流环的闭环控制。为了让电机转起来，整个流程是：
- 通过SDO把0x6060设为CSP模式对应的数值（如8）；
- 配置RPDO映射：控制字（0x6040）、目标位置（0x607A）、模式字（0x6060）；
- 配置TPDO映射：状态字（0x6041）、实际位置（0x6064）、实际速度（0x606C）；
- 切换到操作状态（NMT启动）；
- 按CiA 402状态机依次写入控制字0x06、0x07、0x0F，使驱动器进入“操作使能”状态；
- 周期性写入目标位置，电机开始跟随。
这里面最难懂的就是第5步的控制字顺序。CiA 402状态机要求必须先写0x06（进入待机），再写0x07（进入使能就绪），最后写0x0F（使能运行），如果顺序写错了，驱动器不会执行运动。很多人一开始直接把0x0F写进去，电机不动，回头看状态字才发现根本没进使能态。伺服控制的CANopen调试，很大一部分时间都花在这个状态机切换上。
4.2 用Python开发CANopen上位机：从选库到跑通
在项目原型验证阶段，我不太建议一上来就写大而全的C#或C++上位机，用Python先跑通通信流程，效率会高很多。Python社区有两个库用得最多：python-can负责底层收发CAN帧，canopen负责处理CANopen/NMT/SDO/PDO这套协议栈。
以周立功USBCAN或CANable这类设备为例，用canopen库写一个简单的连接脚本很简单。下面是一个最小示例，连接节点1，启动NMT，通过PDO设置目标位置：
import canopen # 连接CAN总线，假设用的是CANable或类似设备 network = canopen.Network() network.connect(channel='can0', bustype='socketcan') # 加载节点1的EDS描述文件 node = network.add_node(1, 'servo.eds') # 启动NMT，让节点进入操作状态 node.nmt.send_command(0x01) # 0x01 = Start Node # 切换到位置模式（CSP） node.sdo['Modes of operation'].raw = 8 # 通过RPDO1发送目标位置，模拟一个周期 1000 * 1000 步的目标 node.rpdo[1]['Target position'].raw = 1000000 node.rpdo[1].send() # 读取实际位置 pos = node.tpdo[1]['Actual position'].raw print(f'Actual position: {pos}')这段代码的核心是先通过NMT启动节点，再用SDO设置模式，最后通过PDO发送控制和读取反馈。用Python验证通之后，再决定要不要迁移到性能更高的上位机语言。
开发中要注意，canopen库的配置依赖EDS文件。EDS文件是设备厂商提供的一台“字典”，里面描述了设备支持的对象索引、类型、默认值等信息。如果厂商没有提供EDS文件，也可以手动创建，但最好还是找厂商要，因为手写EDS容易漏掉关键字段，导致SDO读写失败。
4.3 汇川、步科现场案例：节点配置和状态切换常见坑
国内伺服和HMI厂商里，汇川和步科对CANopen支持得都挺全面，我拿它们做个对比分析。汇川的IS620N系列伺服支持CiA 402行规，通过CANopen与H5U、AM600等控制器互联。现场配置时，通常要用伺服上位机软件（如汇川InoDriverShop）先设置站号（节点ID）和波特率，这两个参数如果和控制器不一致，总线是无论如何也通信不上的。
步科的状态机设计和标准CiA 402一样，但它们的触摸屏内置了CANopen主站功能，可以直接占用屏上的智能连接来配置。这个功能对小型设备特别友好，不用额外买独立主站控制器。但用触摸屏做主站时有个典型问题：屏上配置的PDO映射周期必须和伺服驱动的默认心跳周期匹配，否则屏会频繁报节点离线。
在这类现场调试中，我常见的坑有三个：
- 节点ID重复。总线上有两个设备用了相同节点ID，后上电的设备把先上电的设备踢下线，现象就是通信一会儿通一会儿断。
- 只配置了SDO，忘记发NMT启动命令。设备在预操作状态下，PDO数据不生效，看起来就是“上位机发了目标位置，电机没反应”。
- 波特率参数不一致。伺服上设置的是500kbps，控制器通道却配成了250kbps，总线上的设备根本听不见对方。
排查这些问题，我一般先用CAN分析工具把总线上的报文全部抓一遍，看看NMT报文、心跳报文、SDO报文是否按预期出现，然后在报文层面定位，比瞎猜省事得多。
4.4 CAN地偏移测试：3个步骤判断接地问题
CAN总线是差分传输，但不代表它不需要地线。每个节点的CAN收发器都有一个参考地（GND），如果两个节点之间的GND电位相差过大，就会导致共模电压超过收发器的容忍范围，出现发送正常但接收乱码的现象。这就是常说的“地偏移”问题。
做CAN地偏移测试时，我通常用三个最简单的步骤：
- 用万用表分别量CAN_H和CAN_L对本地GND的电压。正常隐性状态时，CAN_H和CAN_L大约都是2.5V左右；显性状态时，CAN_H约3.5V、CAN_L约1.5V。如果测出来CAN_L对地只有0.3V，那明显不正常。
- 把两个节点的GND用表笔短接，量GND之间的电压差。这个电压差如果超过2V，就需要认真处理了。对于非隔离的CAN收发器，建议压差控制在1V以内才比较稳妥。
- 接好公共地后再复测一次CAN_H和CAN_L对地电压。注意要用示波器看动态波形，特别是总线繁忙时的波形，看显隐性电平是否分离清晰、有没有回沟或台阶。
处理地偏移的正确姿势有三种：一是把各个节点的GND用足够粗的导线可靠地连接在一起，确保参考地一致；二是在干扰特别大的场合，使用带隔离的CAN收发器（比如CTM1051这类隔离模块），彻底阻断地环路；三是避免把CAN线和大电流动力线走同一个线槽，减少共模干扰引入。
提示：不要小看这些接地细节。我在现场见过一个案例，整条CAN总线换了三批设备都不稳定，最后发现是伺服电机的地线接到控制柜的接地点后，和CAN总线的GND形成了地环路，共模电压波动接近5V，把收发器直接打懵了。
5. 工程实战问题实录：错误帧、丢帧与调试工具
最后一个大节，我把调试CAN和CANopen系统时最常遇到的问题，按现象、原因、解决思路整理一下。这些都是我实际工作中踩过坑的地方，说不定哪天你就碰上了。
5.1 总线无响应排查：终端电阻、波特率、节点ID三板斧
先看终端电阻：断电后量CAN_H和CAN_L之间的直流电阻，应该在60Ω左右。如果量出来120Ω，检查总线两端是否各接了一个120Ω电阻；如果量出来几乎0Ω，检查是不是有接线短路；如果量出来小于60Ω，检查是不是某个中间节点多接了电阻。
再看波特率：把所有设备的波特率核对一遍，确保相同。有些设备会自动检测波特率，有些则不会。理解CAN的仲裁位元结构，我推荐用示波器或者逻辑分析仪抓总线空闲时的波形，量一下一比特的时间，换算一下波特率就知道谁不匹配了。
最后看节点ID：扫一遍总线上的报文，看是否有重复的节点ID在争抢总线。重复ID的节点看起来都“能发”，但互相踩来踩去，一个发成功一个就被动等重试，时间久了错误计数器会飙升，最终触发bus-off。
5.2 错误帧风暴与bus-off：如何定位故障节点
错误帧风暴是现场最让人头疼的问题之一。一帧错误帧只是偶然干扰，但如果总线上持续出现大量错误帧，说明有一个节点在疯狂破坏总线。定位故障节点的思路是看错误标志的来源。
用支持错误帧统计的CAN分析工具，抓一段时间内每类错误帧的数量和错误码。CAN控制器捕获的错误码能提示错误类型，比如位错误（Bit Error）、填充错误（Stuff Error）、CRC错误、ACK错误等。位错误通常说明发送节点自身的发送电平异常，可能是收发器硬件问题；CRC错误和填充错误往往是总线电平畸变、干扰太大；ACK错误则可能是接收端配置不正确或总线上的监听节点太少。
最土的定位办法是把可能故障的节点一个一个断电，观察错误帧是否消失。虽然土但很有效，尤其是总线上节点不多的时候。找到故障节点后，再结合示波器看它的发送波形，判断是驱动器芯片坏了、线缆接触不良，还是接地问题导致输出电平不在正常范围内。
5.3 调试工具选型：CAN卡、示波器、软件怎么搭配
一个好的CAN调试工具可以让你少熬几夜。硬件方面，我常备三类东西：一个USB接口的CAN卡（比如周立功USBCAN系列或者开源CANable），用来收发报文；一台示波器，用来查看物理层波形；一个小型逻辑分析仪或者总线分析仪，用来深挖错误帧和总线负载。
软件方面，Wireshark配合CAN dissector可以插件化解析CANopen报文，BUSMASTER是免费开源的CAN调试工具，支持报文收发、信号解析、报文记录回放，在Windows下很实用。如果用的是Python，canopen库加python-can库的组合基本能满足从报文抓取到协议解析的完整需求。
工具选型上我的经验是：不要一开始就上最贵的商业软件。项目验证阶段，用开源工具加示波器完全可以搞定；到了产线批量调试、要长时间记录报文并做自动化分析的时候，再考虑商业CAN卡自带的分析软件。工具够用就好，重点是能看懂数据，而不是堆工具。
最后再分享一个小技巧：调试CANopen系统时，特别留意初始化的时序。多数总线故障的根源都在“上电顺序”上——NMT主机还没启动，从站已经在预操作状态把SDO参数改了一堆；或者主站还在配置PDO映射，从站已经按旧的映射开始发数据了。上电时给总线留出几百毫秒到几秒的稳定时间，很多奇怪的问题都会自动消失。这个习惯我保持了多年，实测下来非常有用。
