3. 对象字典(OD)深度解析：OD数据结构，EDS/DCF文件格式，OD编辑器使用，自定义对象添加

对象字典，说白了就是CANopen设备的“灵魂”。你想想看，一个从站设备，它有哪些参数、怎么配置、数据存在哪、怎么访问——所有这些信息，都写在对象字典里。我刚开始接触CANopen时，总觉得这东西就是个配置文件，后来踩了坑才明白：OD设计得好不好，直接决定了你的设备好不好用。

3.1 OD数据结构：从索引到子索引

对象字典本质上是一个线性表，每个条目由索引（Index）和子索引（Subindex）唯一标识。索引是16位，范围0x0000~0xFFFF；子索引是8位，范围0x00~0xFF。

CANopen标准把索引空间划分成了几个功能区，我整理了一张表，方便你对照：

索引范围 用途 说明
0x0000 保留 不使用
0x0001~0x001F 静态数据类型 如布尔、整数、浮点数定义
0x0020~0x003F 复杂数据类型 如PDO映射结构、时间结构
0x0040~0x005F 设备配置文件专用 如DS401 I/O设备、DS402驱动
0x1000~0x1FFF 通信对象 COB-ID、同步、心跳、PDO/SDO参数
0x2000~0x5FFF 制造商专用 自定义参数、校准数据、诊断信息
0x6000~0x9FFF 标准化设备子协议 如DS401数字量输入输出
0xA000~0xFFFF 保留/网络专用 一般不使用

关键点：0x2000~0x5FFF是留给你的“自留地”。我习惯把所有自定义参数都放在0x2000~0x3FFF区间，这样既不会和标准对象冲突，也方便后期维护。

每个OD条目包含以下核心字段：

  • Index：16位索引号
  • Subindex：8位子索引号，0x00通常表示“子索引数量”
  • Name：对象名称，如“Error Register”
  • Object Type：对象类型（VAR、ARRAY、RECORD）
  • Data Type：数据类型（UNSIGNED8、UNSIGNED16、INTEGER32等）
  • Access Type：访问权限（ro、wo、rw、const）
  • Default Value：默认值
  • PDO Mapping：是否可映射到PDO

3.2 EDS/DCF文件格式：设备描述的“身份证”

EDS（Electronic Data Sheet）是设备的数据手册，DCF（Device Configuration File）是带具体配置的EDS。说白了，EDS是模板，DCF是实例。

我见过不少工程师，拿到一个从站设备，第一件事就是找EDS文件。为什么？因为EDS里写明了这个设备支持哪些对象、每个对象的默认值、PDO映射能力——这些信息是配置主站和调试的基础。

EDS文件是纯文本格式，用方括号表示节（Section），键值对表示属性。下面是一个典型的EDS片段：

[FileInfo]
FileName=MyDevice.eds
FileVersion=1
FileRevision=1
Description=My CANopen Slave Device
CreationTime=10:00:00
CreationDate=01-01-2025
CreatedBy=YourName

[DeviceInfo]
VendorName=MyCompany
ProductName=MySlave
ProductNumber=12345
RevisionNumber=1
BaudRate_10=1
BaudRate_20=1
BaudRate_50=1
BaudRate_125=1
BaudRate_250=1
BaudRate_500=1
BaudRate_800=1
BaudRate_1000=1
SimpleBootUpMaster=0
SimpleBootUpSlave=0
Granularity=8
DynamicChannelsSupported=0
GroupMessaging=0
NrOfRXPDO=4
NrOfTXPDO=4
LSS_Supported=0

[1000]
ParameterName=Device Type
ObjectType=0x07
DataType=0x0007
AccessType=ro
DefaultValue=0x00000000
PDOMapping=0

[1001]
ParameterName=Error Register
ObjectType=0x07
DataType=0x0005
AccessType=ro
DefaultValue=0x00
PDOMapping=1

[1600]
ParameterName=Receive PDO 1 Parameter
ObjectType=0x07
DataType=0x0007
AccessType=rw
DefaultValue=0x00000200
PDOMapping=0
SubNumber=2

[1600sub0]
ParameterName=Number of Entries
ObjectType=0x07
DataType=0x0005
AccessType=rw
DefaultValue=2
PDOMapping=0

[1600sub1]
ParameterName=PDO Mapping Entry 1
ObjectType=0x07
DataType=0x0007
AccessType=rw
DefaultValue=0x60000108
PDOMapping=0

我的习惯：写EDS文件时，我会在[FileInfo]节里加上RevisionHistory字段，记录每次修改的内容。这样后期排查问题，一眼就能看出EDS版本和固件版本是否匹配。

3.3 OD编辑器使用：图形化配置工具

手写EDS文件太容易出错了。我早期做项目时，有一次把索引号写错了一位，结果主站怎么都配不上从站，查了整整两天。后来我学乖了，用OD编辑器来管理对象字典。

市面上常用的OD编辑器有：

  • CANopenEDitor（Vector）：功能最全，支持语法检查、PDO映射可视化、DCF生成
  • CANopen Object Dictionary Editor（EmSA）：开源免费，轻量级，适合小项目
  • LAWICEL EDS Editor：简单易用，适合快速修改
  • CANopenNode自带的OD工具：如果你用CANopenNode，它有一套基于Python的OD生成脚本

使用OD编辑器的一般流程：

  1. 新建项目：选择设备类型（从站/主站），设置厂商ID、产品名称
  2. 添加通信对象：配置COB-ID、同步参数、心跳时间等
  3. 配置PDO参数：设置PDO的传输类型、禁止时间、事件定时器
  4. 添加自定义对象：在制造商专用区（0x2000~0x5FFF）添加你的参数
  5. 设置PDO映射：把需要实时传输的对象映射到对应的PDO
  6. 导出文件：生成EDS/DCF文件，或者直接导出C语言头文件

避坑指南：我曾经在配置PDO映射时，把两个不同长度的对象映射到了同一个PDO里，结果数据错位，从站输出的值完全不对。记住：PDO映射时，所有映射对象的总长度不能超过PDO的数据长度（默认8字节）。

3.4 自定义对象添加：从需求到实现

添加自定义对象，是每个CANopen开发者都会遇到的需求。比如你的设备有一个温度传感器，需要把温度值通过PDO实时上传，那你就得在OD里定义一个温度对象。

我一般按以下步骤操作：

  1. 确定索引和子索引：选在0x2000~0x3FFF区间，比如0x2100。子索引0x00表示“子索引数量”，子索引0x01开始放实际数据。
  2. 选择数据类型：温度值用INTEGER16（有符号16位，单位0.1°C）或UNSIGNED16（无符号16位）。我个人偏好INTEGER16，因为温度可能是负的。
  3. 设置访问权限：如果温度值是传感器采集的，设为ro（只读）；如果是可配置的阈值，设为rw（读写）。
  4. 启用PDO映射：把PDOMapping设为1，这样主站才能通过PDO实时读取温度值。
  5. 设置默认值：比如温度默认值设为0x0000（0°C）。

下面是一个自定义对象的EDS示例：

[2100]
ParameterName=Temperature Sensor
ObjectType=0x07
DataType=0x0003
AccessType=ro
DefaultValue=0x0000
PDOMapping=1
SubNumber=2

[2100sub0]
ParameterName=Number of Entries
ObjectType=0x07
DataType=0x0005
AccessType=ro
DefaultValue=2
PDOMapping=0

[2100sub1]
ParameterName=Temperature Value
ObjectType=0x07
DataType=0x0003
AccessType=ro
DefaultValue=0x0000
PDOMapping=1

[2100sub2]
ParameterName=Temperature Unit
ObjectType=0x07
DataType=0x0005
AccessType=ro
DefaultValue=0x00
PDOMapping=0

注意：子索引0x00的DefaultValue必须等于实际子索引数量。比如你有2个子索引（sub1和sub2），那sub0的DefaultValue就是2。这个值写错了，主站读OD时就会报错。

3.5 OD与CANopenNode的集成

在CANopenNode中，对象字典是以C语言结构体数组的形式存在的。你写完EDS文件后，需要用工具把它转换成C代码。CANopenNode官方提供了一个Python脚本eds2c.py，可以自动生成OD的C语言实现。

生成的代码结构大致如下：

/* 对象字典条目结构体 */
typedef struct {
    uint16_t index;           /* 索引 */
    uint8_t  subIndex;        /* 子索引 */
    uint8_t  objectType;      /* 对象类型 */
    uint8_t  dataType;        /* 数据类型 */
    uint8_t  accessType;      /* 访问权限 */
    void*    pData;           /* 数据指针 */
    uint32_t dataLength;      /* 数据长度 */
    uint8_t  pdoMapping;      /* PDO映射标志 */
} OD_entry_t;

/* 对象字典表 */
const OD_entry_t OD[] = {
    {0x1000, 0x00, 0x07, 0x0007, 0x01, &deviceType, 4, 0},
    {0x1001, 0x00, 0x07, 0x0005, 0x01, &errorRegister, 1, 1},
    {0x2100, 0x00, 0x07, 0x0005, 0x01, &tempSubNumber, 1, 0},
    {0x2100, 0x01, 0x07, 0x0003, 0x01, &temperatureValue, 2, 1},
    {0x2100, 0x02, 0x07, 0x0005, 0x01, &temperatureUnit, 1, 0},
    /* ... 更多条目 */
};

我的建议：不要手动修改生成的C代码。每次修改OD，都改EDS文件，然后重新生成。手动改C代码容易导致OD和实际数据不一致，这种bug极难排查。

3.6 本章知识结构图

下面这张图展示了对象字典的核心组成和配置流程，你可以对照着梳理思路：

对象字典核心结构图 对象字典(OD)核心结构 对象字典 (Object Dictionary) 通信对象 (0x1000~0x1FFF) 制造商专用 (0x2000~0x5FFF) 设备子协议 (0x6000~0x9FFF) PDO参数 SDO参数 同步/心跳 自定义参数 校准数据 诊断信息 数字量输入 数字量输出 模拟量通道 输出：EDS / DCF 文件 EDS = 模板 DCF = 实例（含配置） 索引 + 子索引 唯一标识每个对象

3.7 避坑总结

做OD配置这么多年，我踩过的坑不少。挑几个典型的跟你说说：

  • 索引冲突：自定义对象不要占用标准区（0x1000~0x1FFF、0x6000~0x9FFF），否则主站解析时会混乱。
  • 子索引0x00的默认值：必须等于实际子索引数量，多一个少一个都不行。
  • PDO映射长度超限：一个PDO最多8字节数据，映射的所有对象总长度不能超过8字节。
  • EDS版本管理：每次修改OD，记得更新EDS的版本号。我曾经因为版本号没改，现场工程师用了旧版EDS配置新固件，结果设备起不来。
  • 数据类型匹配：OD里定义的数据类型，必须和C代码里实际变量的类型一致。比如OD里写UNSIGNED16，C代码里就得用uint16_t。

最后提醒一句：对象字典是CANopen设备的“宪法”。宪法写错了，后面所有的工作都是白费。花时间把OD设计好、测试好，比后期在代码里打补丁要划算得多。

← 上一章 📖 返回目录 下一章 →