《canopen轻松入门.pdf//某品牌伺服电机驱动器EDS文件》链接:https://pan.baidu.com/s/1GjdXTk0tfyEmIvRdWSlpBw?pwd=4qad
提取码:4qad
CANopen在OSI层级中的位置
从OSI的7层网络模型的角度来看同,CAN(Controller Area Network)现场总线仅仅 定义了第1层(物理层,见ISO11898-2标准)、第 2层(数据链路层,见ISO11898-1标准); 而在实际设计中,这两层完全由硬件实现,设计人员无需再为此开发相关软件(Software) 或固件(Firmware),只要了解如何调用相关的接口和寄存器,即可完成对CAN的控制
但CAN没有规定应用层。也就是没有规定与实际应用相关的逻辑,比如开关量输入输 出,模拟量输入输出。所以本身对于应用来说,是不完整的。这就像铁矿石(物理层)冶炼 成铁锭(数据链路层),然后针对具体应用,再加工做成汽车、轮船、钢筋、坦克、钢结构 建筑等等。如图示。
因此,基本每个行业的 CAN 应用,都需要一个高层协议来定义 CAN 报文中的 11/29 位标识符、8字节数据的使用。在CAN总线的工业自动化应用中,需要一个开放的、标准化的高层协议:能够实现在CAN网络中提供标准的、统一的系统通讯模式,提供 设备功能描述方式,执行网络管理功能。其中包括:
应用层(Application layer):为网络中每一个有效设备都能够提供一组有用的服务与协议。
通讯描述(Communication profile):提供配置设备、通讯数据的含义,定义数据通讯方式。
设备描述(Device proflile):为设备(类)增加符合规范的行为。
CANopen的预定义报文ID分类
CANopen 的创始人在设计CANopen时,对其定 义为小网络、控制信号的实时通讯:
报文传输采用CAN标准帧格式。即11bit的ID域,以尽量减小传输时间;
网络控制报文均采用数据最小字节数。比如心跳报文,只有1个字节数据;
实时更新的过程数据无需接收方报文应答。即采用生产消费模型,降低总线负载;
需要接收方确认的配置参数一般都是采用快速单字传输。即 1 个报文最多传送 1 个32字节的参数变量,避免了分帧引起的实时性降低。
以上这些定义都是为了节约时间开销,最大限度保证实时性。同时为了减小简单网络的 组态工作量,CANopen定义了强制性的缺省标识符(CAN帧ID)分配表,以减少使用者与 维护者的学习时间,快速上手。
网络管理(NMT)与特殊协议(Special protocols)报文ID分类
虽然CANopen 的通讯发挥了CAN的特色,所有节点通信地位平等,运行时允许自行 发送报文,但CANopen网络为了稳定可靠可控,都需要设置一个网络管理主机NMT-Master (Network Management-Master),就像一个交响乐团的指挥家,所有节点的启动、停止都是 有他进行指挥。
NMT主机一般是CANopen网络中具备监控的PLC或者PC(当然也可以是一般的功能 节点),所以也成为CANopen主站。相对应的其他CANopen节点就是NMT从机(NMT-slaves)。 NMT主机和NMT从机之间通讯的报文就称为NMT网络管理报文。管理报文负责层管 理、网络管理和ID分配服务。例如,初始化、配置和网络管理(其中包括节点保护)。网络 管理中,同一个网络中只允许有一个主节点、一个或多个从节点,并遵循主从模式。 另外,为了协调各个节点的同步、心跳、时间、错误提示等通讯控制,CANopen 还定 义了一系列特殊协议(Special protocols)报文。如表 4.1 所示,为 CANopen 预定义报文 (Pre-defined CAN-IDs)的 NMT 报文和特殊协议报文。
CAN-ID 就是这类报文的COB-ID,其中读者必须需要记住的是绿色底纹的这些常用的 CAN-ID 含义,在研发和应用CANopen中,这三类是最为常用的NMT与特殊协议报文。
过程数据对象(PDO)和服务数据对象(SDO)的报文ID分类
用户应用 CANopen 时,需要传递的配置信息和应用信息都是放在过程数据对象 PDO (Process data object)和服务数据对象 SDO (Service data object)里面。这些对象就和市场 上卖水果的箩筐,大小是一样的,只是装的东西(应用数据)不一样,这就 是CiA301 协议所规定的基础协议——“箩筐”,而 CiA4xx的子协议或者用户自定义的对象 就是“箩筐”里面的东西。
PDO 和 SDO 的通讯区别在于,PDO属于过程数据,即单向传输,无需接收节点回应 CAN报文来确认,从通讯术语上来说是属于“生产消费”模型。
而SDO属于服务数据,有指定被接收节点的地址(Node-ID),并且需要指定的接收节 点回应CAN 报文来确认已经接收,如果超时没有确认,则发送节点将会重新发送原报文。 这种通讯方式属于常见的“服务器客户端”的通信模型,即我们通常所说的轮询式。如图 4.5 所示。
PDO的CAN-ID定义
对于PDO和SDO的报文ID分配,为了减少网络的组态工作量,CANopen预定义了强 制性的缺省标识符(CAN-ID)分配表,该分配表是基于 11 位CAN-ID 的标准帧格式。将 其划分为 4 位的功能码(Function-ID)和7 位的节点号(Node-ID)。如图 4.6所示.
PDO通信比较灵活,广义上只要符合PDO范围内的所有CANID都可以作为节点自身 的TPDO或者RPDO使用,也称为COB-ID,不受功能码和Node-ID限制 .而在PDO预定义中,人为规定了TPDO和RPDO,规定了Node-ID在PDO中的位置, 规定了PDO的编号.PDO分为TPDO(发送PDO)和(接收RPDO),发送和接收是以CANopen节点自身 为参考(如果CAN主站或者其他从站就相反)。TPDO和RPDO分别有4个数据对象,每 种数据对象就是1条CAN报文封装,这些都是数据收发的容器,就像水果箩 筐为使用者准备好,就看使用者在里面放什么水果了。 当然,如果某个节点需要传递的资源特别多,则有出现例如 TPDO5 之类的数据对象, 而它们的CAN-ID 定义就需要打破预定义的规则,比如我们可以定义Node-ID为1的节点 中TPDO5是182h,这里的PDO的COB-ID 中的低7位不再是表示Node-ID。其实所有的 PDO的COB-ID与Node-ID无必然规则上的联系。
在CANopen 里也通常把 CAN-ID 称为 COB-ID(通信对象编号)。所以我们可以分清 楚两个易于混淆的名称:
COB-ID:Communication Object Identifier,即 CANopen 中对某种通讯对象的报文帧 ID,即CAN报文的11位ID。代表了一种通讯含义。
Node-ID:节点ID号,即CANopen网络中的节点地址,CANopen规定了逻辑上最 大128个节点,所以Node-ID最大为128(7位)。
COB-ID 和 Node-ID 无必然联系,但在过程数据对象(PDO)和服务数据对象(SDO) 中,COB-ID 中包含了Node-ID 。
由于需要区分每个CANopen节点的输入和输出,所以PDO分为TPDO(发送PDO) 和(接收RPDO),发送和接收是以CANopen从站节点为参考(如果CAN主站就相反)。TPDO 和RPDO分别有4个数据对象,每种数据对象就是1条CAN报文封装,如表 4.2所示, 这些都是数据收发的容器,就像各种水果箩筐为使用者准备好,就看使用者在里面 放什么水果了。 而SDO就相对比较简单固定,发起通讯的“问”SDO的CAN帧ID就是600h +node-ID, 这里的Node-ID 是被问的节点地址,而被问的节点应“答”SDO的CAN帧ID就是580h +node-ID。一般在CANopen网络中,只有NMT主机能发起SDO通讯,进行节点参数配置 或者关键性参数的传递。当然从节点也可以对其他从节点发起SDO通讯。 如表 4.2所示。为CANopen预定义报文的PDO报文和SDO报文中的ID分类。使用 者务必牢记!
对象字典OD(Object dictionary)
CANopen 对象字典(OD: Object Dictionary)是 CANopen协议最为核心的概念。所谓的 对象字典就是一个有序的对象组,描述了对应CANopen节点的所有参数,包括通讯数据的 存放位置也列入其索引,这个表变成可以传递形式就叫做EDS文件(电子数据文档 Electronic Data Sheet)。对象字典,就像体检表,具备这个人每个功能的参数,便于用人 单位(主站)进行合理分配工作。
每个对象采用一个16位的索引值来寻址,这个索引值通常被称为索引,其范围在0x0000
到0xFFFF之间。为了避免数据大量时无索引可分配,所以在某些索引下也定义了一个8 位
的索引值,这个索引值通常被称为子索引,其范围是0x00到0xFF之间。
每个索引内具体的参数,最大用32位的变量来表示,即Unsigned32,四个字节。
每个CANopen设备都有一个对象字典,使用电子数据文档(EDS文件)来记录这些参
数,而不需要把这些参数记录在纸上。对于CANopen网络中的主节点来说,不需要对
CANopen 从节点的每个对象字典项都访问。
CANopen 对象字典中的项由一系列子协议来描述。子协议为对象字典中的每个对象都
描述了它的功能、名字、索引、子索引、数据类型,以及这个对象是否必需、读写属性等等,
这样可保证不同厂商的同类型设备兼容。
CANopen 协议的核心描述子协议是DS301,其包括了CANopen协议应用层及通信结构
描述,其它的协议子协议都是对DS301 协议描述文本的补充与扩展。在不同的应用行业都
会起草一份CANopen设备子协议,子协议编号一般是DS4xx 。
对象字典概述
如表 5.1所示,为对象字典索引区域定义,其中标绿色底纹的通讯对象子协议区和制 造商特定子协议区是用户需要关注的区域。
通讯对象子协议区(Communication profile area)
通讯对象子协议区(Communication profile area)定义了所有和通信有关的对象参数, 如表 5.2所示,标绿色底纹的索引范围1000h to 1029h为通用通讯对象,所有CANopen节 点都必须具备这些索引,否则将无法加入CANopen网络。其他索引根据实际情况进行分配 与定义。
通用通讯对象(General communication objects)
由于通用通讯对象十分重要,NMT 主站(CANopen 主站)在启动时,通常都全部或 者部分读取所有从站中通用通讯对象中的索引,所以所有的通用通讯对象都必须在 CANopen从站中实现,使用者也必须熟知这些索引地址与其含义。如表 5.3所示。
制造商特定子协议(Manufacturer-specific Profile)
对象字典索引2000h to 5FFFh为制造商特定子协议,通常是存放所应用子协议的应用数 据。而上文所描述的通讯对象子协议区(Communication profile area)是存放这些应用数据 的通信参数。比如广州致远电子的XGate-COP10从站模块规定了: RPDO的通讯参数存放在1400h to 15FFh 映射参数存放在1600h to 17FFh 数据存放为 2000h 之后厂商自定义区; TPDO的通讯参数存放在1800h to 19FFh 映射参数存放在1A00h to 1BFFh 数据存放为 2000h 之后厂商自定义区。
对于在设备子协议中未定义的特殊功能,制造商也可以在此区域根据需求定义对象字典 对象。因此这个区域对于不同的厂商来说,相同的对象字典项其定义不一定相同。
在CANopen协议中,RPDO的通讯参数存放在1400h到15FFh的范围内。这些参数包括COB-ID(通信对象标识符)、传输类型、定时周期等,它们定义了设备如何使用CANopen网络接收数据。
同时,映射参数存放在1600h到17FFh的范围内。这些映射参数定义了哪些对象字典中的条目(或数据)应该被包含在RPDO中,以及它们应该如何被映射。对于生产者和消费者来说,知道这些映射参数是非常重要的,因为它们需要知道如何从PDO中正确地解释数据。
至于数据存放,它通常位于2000h之后的区域,这部分区域被称为“厂商自定义区”。这是因为不同的厂商可能会有不同的数据需求和存储方式,所以这部分区域允许厂商根据自己的需要进行定义和使用。
总的来说,这些参数和数据的存放位置在CANopen协议中是有明确规定的,这有助于确保不同设备之间的通信能够顺利进行。
标准化设备子协议(Standardized profile area)
标准化设备子协议,为各种行业不同类型的标准设备定义对象字典中的对象。目前已有 十几种为不同类型的设备定义的子协议,例如 DS401、DS402、DS406 等,其索引值范围 为 0x6000~0x9FFF。同样,这个区域对于不同的标准化设备子协议来说,相同的对象字典 项其定义不一定相同。
对象字典和EDS文件实例
对于对象字典和EDS文件的实现,需要使用专用的EDS生成工具,并且能通过CiA的 EDS测试工具进行一致性测试。
对象字典导出后就是所谓的EDS文件