CAN(Controller Area Network)现场总线仅仅定义了物理层、数据链路层,没有规定应用层;本身并不完整,需要一个高层协议来定义 CAN 报文中的各个数据位的具体作用。同时,随着 CAN 总线在工业自动化的应用越来越需广泛,就更加迫切的需要一个开放的、标准化的高层协议。
CANopen 是一种以 CAN 为基础的上层协议,是 CiA(CAN-in-Automation)定义的标准协议,在发布后不久就获得了广泛的承认。依靠 CANopen 协议的支持,可以将不同厂商遵循CANopen 标准的设备通过 CAN 总线进行网络连接。
咳咳,简单来说就是,CAN总线报文太简单了,没有一个协议,就像你有网线却永远只能发送0001111这样,所以我们要定义一个协议在这个网络上面用。所以CANopen就出来了,这就类似于我们计算机中的应用层的TCP协议,自己封装包,自己解包
在 OSI 模型中,CAN 标准与 CANopen 协议之间的关系如下图所示:
CANopen 协议提供了一套标准的通讯对象:包含过程
数据对象 PDO(Process Data Objects)、服务数据对象 SDO(Service Data Objects) 和一些特定功能的时间戳(Time Stamp),同步信息(Sync message),紧急信息(Emergency message);
另外还制定了网络管理数据(network management data),
如开机信息(Boot-up message)、网络管理信息(NMT message)和错误控制信息( Error Control message)。
为了减小简单网络的组态工作量,CANopen 定义了强制性的缺省标识符(CAN-ID)分配表。这些标志符在预操作状态下可用,通过动态分配还可修改它们。CANopen 设备必须向它所支持的通讯对象的提供相应的标识符。
缺省 ID 分配表是基于 11 位 CAN-ID,包含一个 4 位的功能码部分和一个 7 位的节点
ID(Node-ID)部分,如下图所示:
Node-ID 范围是 1~127(0 不允许被使用)。
预定义的连接集定义了 4 个接收 PDO(RXPDO),4 个发送 PDO(TXPDO),1 个 SDO(占用 2 个 CAN-ID),1 个紧急对象和 1 个节点错误控制(Node Error Control)ID。也支持不需确认的 NMT 模块控制(NMT Module Control)服务,同步(SYNC)和时间戳(Time Stamp)对象的广播,定义如下表所示。
COB-ID可以理解是CAN-ID 功能码+节点ID
ID 地址分配表与预定义的主从连接集相对应,因为所有的对等 ID 是不同的, 所以实
际上只有一个主设备(知道所有连接的节点 ID)能和连接的每个从节点(最多 127 个)以对等方
式通讯。两个连接在一起的从节点不能够通讯。
注意:
⊙ PDO/SDO 发送/接收是相对于从(slave)CAN 节点方而言的。
⊙ NMT 错误控制包括节点保护(Node Guarding),心跳报文(Heartbeat)和 Boot-up 协议。
4 号从站 TXPDO2 的 COB-ID 为 280h + 4 = 284h。
了解一下这个就好,我也不大懂是干嘛的,等深入了解过后再来更新
**对象字典(Object Dictionary)**是一个有序的对象组;每个对象采用一个 16 位的索引值来寻址,为了允许访问数据结构中的单个元素,同时定义了一个 8 位的子索引,对象字典的结构如下表:
CANopen 网络中每个节点都有对象字典——包含了描述这个设备和它的网络行为的所有参数。
节点的对象字典是在电子数据文档(EDS:Electronic Data Sheet)中描述的。如果节点严格按照 EDS 描述其行为,也是可以的。其实,节点只需要能够提供对象字典中必需的对象(在CANopen 规定中必需的项实际上是很少的),以及其它可选择的、构成节点部分可配置功能的对象。
CANopen 包含了较多的子协议;其中,通讯子协议(communication profile),描述对象字典的主要形式和对象字典中的通讯子协议区域中的对象、通讯参数;同时描述了 CANopen通讯对象;这个子协议适用于所有的 CANopen 设备。
另外,还有各种设备子协议(deviceprofile),为各种不同类型设备定义对象字典中的对象。设备子协议为对象字典中的每个对象描述了它的功能、名字、索引和子索引、数据类型,以及这个对象是必需的还是可选的,这个对象是只读、只写或者可读写等等。设备子协议定义了对象字典中哪些对象是必需的,哪些是可选的;如果需要的项超过了设备子协议中可以提供的,在设备子协议中已预留足够空间提供给厂商的特定功能使用。对象字典中描述通讯参数部分对所有 CANopen 设备(例如在对象字典中的对象是相同的,对象值不必一定相同)都是一样的。对象字典中设备相关部分对于不同类的设备是不同的。
说人话就是说,这个字典定义了所有在CANopen协议中的所有功能表示,包括里面有什么参数,参数是什么类型的,属性是什么,是不是必须传入的,都定义在对象字典里面
DS 301 中规定了对象字典的基本结构,如下表:
对象类型
NMT 提供网络管理服务。 这种服务是采用主从通讯模式(所以只有一个 NMT 主节点)来实现的。
NMT 模块控制
只有 NMT 主节点能够传送 NMT 模块控制报文,所有从节点必须支持 NMT 模块控制服务,NMT 模块控制不需要应答。其消息格式如下:
第一个字节的数据列表
命令字 | NMT服务 |
---|---|
1(01H) | 启动远程节点 |
2(02H) | 停止远程节点 |
128(80H) | 进入预操作状态 |
129(81H) | 节点复位 |
130(82H) | 通讯复位 |
第二个字节代表被控制的节点 Node-ID,
如果要对整个网络所有节点同时进行控制,则这个数值为 0 即可。
NMT 节点保护
通过此项服务,NMT 主节点可以检查每个节点的当前状态,主节点发送远程帧格式如
下:
NMT 从节点应答报文格式如下:
数据部分包括一个触发位(bit7),触发位必须在每次节点保护应答中交替置“0”或者“1”。触发位在第一次节点保护请求时置为“0”。位 0 到位 6(bits0~6)表示节点状态,其取值与状态的对应关系如下表所示:
注意:状态 0 不在节点保护应答中出现。
一个节点可被配置为产生周期性的被称作心跳报文(Heartbeat)的报文。
NMT Boot-up
NMT 从节点发布 Boot-up 报文通知 NMT 主节点它已经从初始化状态进入预操作状态。
NMT 通讯状态机
设备初始化(图中初始化、重置应用及重置通讯的统称)完成后进入预操作状态。在这一状态的设备可通过 SDO(例如使用配置工具)设置参数和分配 ID。然后,节点直接进入操作状态。
这里也看得晕晕的,这个NMT主要叙述了在通讯过程中的一些状态控制以及心跳包的报文解析之类
PDO 采用生产者/消费者模式,PDO 数据传送可以是一对一或是一对多的方式进行。
每一个PDO信息包含了发送**PDO(TxPDO)**和接收 **PDO(RxPDO)**信息,其传送方式定义在 PDO 通讯参数索引。
所有的 PDO 传送数据必须透过对象字典映像到对应的索引区上。以 DSP 402 中定义的 1600H 及 1A00H 对象为例:
下图较详尽的表述了 PDO 参数(1400H)与 PDO 映射(1600H)之间的关系及 PDO 数据的传输过程(以节点 2 为例),图示箭头的方向表示主站数据处理方向。
主站接收信息从站返回的信息
下图较详尽的表述了 PDO 参数(1800H)与 PDO 映射(1A00H)之间的关系及 PDO 数据的传输过程(以节点 2 为例),图示箭头的方向表示从站数据处理方向。
SDO 用来访问一个设备的对象字典。访问者被称作客户(client),对象字典被访问且提供所请求服务的 CANopen 设备别称作服务器(server)。
客户的 CAN 报文和服务器的应答CAN 报文总是包含 8 字节数据(尽管不是所有的数据字节都一定有意义)。一个客户的请求一定有来自服务器的应答。
累了,完