CAN&CANopen通信协议全面解析:从基础到高级应用
前言
在现代工业自动化和汽车电子领域,CAN总线技术因其高可靠性和实时性得到了广泛应用。而CANopen作为基于CAN总线的高层协议,进一步提升了设备间的互操作性和系统集成效率。本文将深入浅出地介绍CANopen协议的核心概念和技术细节。
一、CAN总线基础回顾
1.1 CAN协议概述
CAN(Controller Area Network)是一种串行总线系统,最初于80年代初为汽车应用而开发,现已成为ISO11898-1国际标准。它具有多主控能力、广播通信、先进的错误检测机制等特性,广泛应用于汽车电子、工业自动化、医用设备等领域。
1.2 CAN协议架构
根据OSI七层模型,CAN通信协议主要包含物理层和数据链路层。值得注意的是,CAN标准本身没有规定应用层协议,这就需要像CANopen这样的高层协议来定义报文标识符和数据字节的使用规范。

图1.1 OSI七层模型
CAN物理层主要标准包括:
-
ISO 11898-2(高速):数据传输速率高达1Mbit/s,终端电阻120Ω
-
ISO 11898-3(低速容错):数据传输速率125kbit/s,具备故障容错能力
-
SAE J2411(单线):适用于要求较低的场合
二、CANopen协议核心概念
2.1 CANopen简介
CANopen是基于CAN的分布式自动化系统高层协议,它实现了不同制造商设备之间的标准化通信。该协议由设备配置文件定义应用层,并提供了完整的通信机制和网络管理功能。
CANopen设备在逻辑上分为三个部分:通信接口、对象字典和应用层,这种分层结构确保了协议的灵活性和可扩展性。

图2.1 CANopen设备模型
|
应用层 |
|
设备配置文件,如:CiA401(通用I/O模块), CiA402(运动控制器和驱动) |
|
CiA301,CANopen应用层和通讯概况,CiA302,可编程CANopen设备框架 |
|
数据链路层 |
|
物理层 |
2.2 网络拓扑与节点寻址
CANopen系统采用主从式网络结构,有且只有一个主站,最多可连接127个从站。每个设备都有独立的Node-ID(范围1~127),节点号必须唯一。主站负责启动/停止和监测CAN总线,确保网络正常运行。
三、对象字典:CANopen的核心组件
3.1 对象字典概述
对象字典(OD)是所有CANopen设备最重要的部分,它是应用程序和CAN总线之间的接口。OD以索引和子索引的方式有序管理参数,索引范围分为几个重要区域:
|
索引范围 |
用途 |
描述 |
|---|---|---|
|
1000h~1FFFh |
通信对象子协议区 |
定义设备通信行为 |
|
2000h~5FFFh |
制造商特定子协议区 |
制造商自定义应用参数 |
|
6000h~9FFFh |
标准化设备子协议区 |
遵循行业标准规范 |
表3. 1 对象字典概述
3.2 通信对象子协议区
该区域定义了所有和通信有关的对象参数,如下表3.2所示,1000h~1029h为通用通讯对象,所有CANopen节点都必须具备这些索引,否则将无法加入CANopen网络。其他索引根据实际情况进行分配与定义。
|
索引范围Index range |
描述Description |
|
1000h~1029h |
通用通讯对象 |
|
1200h~12FFh |
SDO参数对象 |
|
1300h~13FFh |
安全对象 |
|
1400h~1BFFh |
PDO参数对象 |
|
1F00h~1F11h |
SDO管理对象 |
|
1F20h~1F27h |
配置管理对象 |
|
1F50h~1F54h |
程序控制对象 |
|
1F80h~1F89h |
网络管理主机对象 |
表3. 2 通讯对象子协议区
3.3 关键通信对象
通用通信对象子协议区(1000h~1029h)包含了所有CANopen节点必须实现的索引,这些是设备加入CANopen网络的基础。其中一些重要索引包括:
-
1000h:设备类型
-
1001h:错误寄存器
-
1008h:制造商设备名称
-
1018h:身份标识对象(包含厂商ID、产品代码等)
|
Index索引 |
Object对象 |
Name名字 |
|
1000h |
VAR变量 |
Device type设备类型 |
|
1001h |
VAR变量 |
Error register错误寄存器 |
|
1002h |
VAR变量 |
Manufacturer status register制造商状态寄存器 |
|
1003h |
ARRAY数组 |
Pre-defined error field预定义错误场 |
|
1005h |
VAR变量 |
COB-ID Sync message同步报文COB标识符 |
|
1006h |
VAR变量 |
Communication cycle period同步通信循环周期(单位us) |
|
1007h |
VAR变量 |
Synchronous windows length同步窗口长度(单位us) |
|
1008h |
VAR变量 |
Manufacturer device name制造商设备名称 |
|
1009h |
VAR变量 |
Manufacturer hardware version制造商硬件版本 |
|
100Ah |
VAR变量 |
Manufacturer software version制造商软件版本 |
|
100Ch |
VAR变量 |
Guard time守护时间(单位ms) |
|
100Dh |
VAR变量 |
Life time factor寿命因子(单位ms) |
|
1010h |
VAR变量 |
Store parameters保存参数 |
|
1011h |
VAR变量 |
Restore default parameters恢复默认参数 |
|
1012h |
VAR变量 |
COB-ID time stamp时间报文COB标识符(发送网络时间) |
|
1013h |
VAR变量 |
High resolution time stamp高分辨率时间标识 |
|
1014h |
VAR变量 |
COB-ID emergency紧急报文COB标识符 |
|
1015h |
VAR变量 |
Inhibit time emergency紧急报文禁止时间(单位100us) |
|
1016h |
ARRAY数组 |
Consumer heartbeat time消费者心跳时间间隔(单位ms) |
|
1017h |
VAR变量 |
Producer heartbeat time生产者心跳时间间隔(单位ms) |
|
1018h |
RECORD记录 |
Identity object厂商ID标识对象 |
|
1019h |
VAR变量 |
Sync.counter overflow value同步计数溢出值 |
|
1020h |
ARRAY数组 |
Verify configuration验证配置 |
|
1021h |
VAR变量 |
Store EDS存储EDS |
|
1022h |
VAR变量 |
Storage format存储格式 |
|
1023h |
RECORD记录 |
OS command操作系统命令 |
|
1024h |
VAR变量 |
OS command mode操作系统命令模式 |
|
1025h |
RECORD记录 |
OS debugger interface操作系统调试接口 |
|
1026h |
ARRAY数组 |
OS prompt操作系统提示 |
|
1027h |
ARRAY数组 |
Module list模块列表 |
|
1028h |
ARRAY数组 |
Emergency consumer紧急报文消费者 |
|
1029h |
ARRAY数组 |
Error behavior错误行为 |
表3. 3 通用通信对象
3.4 制造商特定子协议
对象字典索引2000h to 5FFFh为制造商特定子协议,通常是存放所应用子协议的应用数据。而上文所描述的通讯对象子协议区(Communication profile area)是存放这些应用数据的通信参数。比如EPEC的部分子协议定义如下:

图3. 1 EPEC部分制造商特定子协议示意图
3.5 对象字典和EDS文件实例
对于对象字典和 EDS 文件的实现,需要使用专用的 EDS 生成工具,并且能通过 CiA 的EDS 测试工具进行一致性测试,EPEC中创建和导入EDS文件可以使用Multitool在对象字典页面中实现:

图3. 2 EPEC_EDS导入和导出示意图
四、过程数据对象(PDO)详解
4.1 PDO基本特性
PDO用于传输高优先级的控制信息和状态信息,每个CAN帧包含8字节数据。PDO采用生产消费模式,支持单点向多点通信,无需接收节点回应确认,具有较高的实时性。
PDO的触发模式包括:
-
异步传输:由特定事件触发(定时传输、数据变化等)
-
同步传输:通过同步报文实现精确时间控制
-
远程帧触发:较少使用

4.2 PDO的COB-ID规则
在CiA301规范下,PDO的CAN-ID有明确的预定义规则:
|
PDO类型 |
CAN-ID范围 |
计算公式 |
|---|---|---|
|
TPDO1 |
181h~1FFh |
180h + Node-ID |
|
RPDO1 |
201h~27Fh |
200h + Node-ID |
|
TPDO2 |
281h~2FFh |
280h + Node-ID |
|
... |
... |
... |
每个节点最多可定义4个TPDO和4个RPDO,超出时需要采用虚拟节点加偏移量的方式扩展。
PDO分为TPDO(发送PDO)和RPDO(接收PDO),发送和接收是以自身作为参考,可以看到TPDO和RPDO分别有4个数据对象,每种数据对象就是1条CAN报文封装,如果需要配置超过4条,比如说第5条TPDO5,和EPEC控制器中对PDO的COB-ID的定义类似,需要打破预定义的规则。比方说将Node-ID为2的节点号定义成1A2h,这里PDO中COB-ID中的低7位不再是表示Node-ID,但事实上PDO的COB-ID和Node-ID无必然规则上的联系。
五、服务数据对象(SDO)深入解析
5.1 SDO通信机制
SDO是CANopen网络中用于配置和管理节点参数的一种对象类型。它通过请求-响应机制实现数据的读取和写入。SDO适用于配置节点参数、读取设备状态和进行故障诊断等场景。SDO的数据传输是基于请求和响应的,需要节点之间进行交互。
发送方(客户端)发送CAN-ID为600h+Node-ID的报文,其中Node-ID为为接收方(服务器)的节点地址,数据长度为8字节;
接收方(服务器)成功接收后,回应CAN-ID为580h+Node-ID的报文,这里的Node-ID依然是接收方(服务器)的节点地址,数据长度均为8字节。
CANopen的主节点通常作为Client客户端发送方,从节点作为Server服务器端,SDO客户端可以通过索引和子索引访问SDO服务器上的对象字典,这称为CS架构(Client-Server架构)
|
字节位置 |
占用长度 |
内容描述 |
|
字节 0 |
1字节 |
命令字:用于标识操作类型(读/写)和传输模式(快速)。 |
|
字节 1-2 |
2字节 |
对象字典索引:指定要访问的参数地址。 |
|
字节 3 |
1字节 |
对象字典子索引:指定参数的子项。 |
|
字节 4-7 |
4字节 |
数据区:用于存放要读取或写入的实际用户数据。 |
表5. 1 SDO结构示意
|
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
|
CS命令 |
索引 |
子索引 |
数据Data(高位在后) | ||||
表5. 2 SDO结构示意
5.2 SDO协议类型
快速SDO协议适用于不超过32位的数据传输,单次通信即可完成数据交换。其命令字包括:
-
2Fh/2Bh/27h/23h:分别表示写入1/2/3/4字节
-
40h:读取请求
-
60h:写入成功应答
-
80h:异常响应

图5. 1 快速SDO示意图
普通SDO协议用于大数据量的分段传输,支持任意长度的数据交换。协议采用分段传输机制,通过交替的命令字控制传输过程。

图5. 2 普通SDO下载协议示意图
六、网络管理(NMT)与设备监控
6.1 NMT状态机
CANopen定义了完整的网络管理服务,NMT主节点能够控制其他节点的状态。NMT消息具有最高优先级(CAN-ID 0),包含命令符和目标节点ID。
设备状态包括:
-
初始化:设备上电初始化阶段
-
预操作:允许SDO通信,禁止PDO通信
-
操作:全面通信状态
-
停止:仅允许NMT通信
NMT的信息包含了2个字节
1.命令符字节(启动/停止/预操作)
2.被改变通讯状态的Node-ID
EPEC的NMT指令如下表6.2所示:
|
COB-ID |
Command(byte0) |
Node-ID(byte1) |
|
000 |
1h 启动 |
00h(全部节点) |
|
000 |
2h 停止 |
01h |
|
000 |
80h 预操作 |
... |
|
000 |
81h 重置node |
7Fh |
|
000 |
82h 重置communications |
表6. 1 EPEC_NMT指令表
6.2 设备监控机制
CANopen提供两种设备监控方式:
-
心跳报文:设备周期发送状态信息(COB-ID = 700h + Node-ID)
-
节点保护:主节点定期检查从节点状态(现已较少使用)
七、EPEC预定义通信表和OD基本条目



八、CANopen开发实践与挑战
8.1 实际开发考量
在CANopen系统开发中,工程师需要重点关注:
-
对象字典配置:合理规划索引地址和数据类型
-
PDO映射优化:确保关键数据的实时性
-
网络管理策略:设计合理的状态转换逻辑
-
错误处理机制:实现完善的故障诊断和恢复
8.2 传统调试方式的局限性
传统的CANopen开发调试通常依赖有线连接,存在诸多不便:
-
布线复杂:特别是分布式系统和大型设备
-
现场调试困难:工程师需要携带设备亲临现场
-
实时监控受限:有线连接限制数据采集灵活性
-
维护成本高:故障诊断和系统升级效率低下
九、无线CAN调试解决方案:PKCAN-WIFI
9.1 产品概述
PKCAN-WIFI是专为CAN总线应用开发的无线调试工具,集成了多种实用功能,极大提升了CANopen系统的开发调试效率。
主要技术参数:
-
供电电压:9-36VDC宽电压输入
-
通信接口:支持WIFI6,兼容Station/SoftAP模式
-
CAN接口:内置无线PEAK和KVASER接口
-
工作环境:-20~80℃工业级温度范围
-
防护等级:IP65,适应恶劣工业环境
9.2 核心功能优势
-
全面兼容性:支持PCAN-View、CANmoon、Kvaser CanKing等主流软件
-
无缝集成:内置Codesys2.3和3.5无线网关,实现源程序无线下载和调试
-
灵活部署:支持局域网和远程访问模式,满足不同应用场景
-
多功能集成:集成了在线监控、数据采集、远程诊断等实用功能
9.3 应用价值
PKCAN-WIFI的革命性意义在于:
-
提升开发效率:工程师可以远程完成配置和调试工作
-
降低维护成本:减少现场服务次数和系统停机时间
-
增强系统灵活性:支持移动端访问和远程协作
-
未来可扩展性:为工业物联网应用奠定基础
结语
CANopen协议作为成熟可靠的工业通信标准,在智能制造和自动化领域发挥着重要作用。随着无线通信技术的发展,基于PKCAN-WIFI这样的创新工具,工程师能够突破传统有线连接的限制,以更高效、灵活的方式应对各种应用挑战。
在工业4.0和物联网时代,无线CAN调试技术将成为行业发展的重要推动力。我们相信,通过不断的技术创新和工具优化,CANopen协议将在更多领域展现其价值,为智能制造注入新的活力。
本文涉及的技术文档参考了EPEC文档CAN_CANopen以及其它单位的相关资料,仅供技术交流使用。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐



所有评论(0)