目录

  • 简介
  • CAL(CAN Application layer)
  • CANopen
    • CANopen对象字典(CANopen Object Dictionary)
    • CANopen communication
      • 管理消息(Administrative message)
      • 服务数据对象(Service Data Object,SDO)
      • 过程数据对象(Process Data Object,PDO)
      • 预定义消息或特殊功能对象(Predefined messages or Special Function Objects)
        • 同步(Synchronization,SYNC)
        • 时间戳(Time Stamp)
        • 紧急(Emergency)
        • 节点/生命守护(Node/Life Guarding)
        • 启动(Boot-up)
      • 小结
    • CANopen预定义的连接设置(Predefined Connection Set)
    • CANopen标识符分配(identifier distribution)
      • 使用预定义的Master/Slave连接集
      • 上电后修改PDO标识符
      • 使用CAL DBT服务
      • CANopen 启动过程(boot-up process)
    • CANopen消息语法的细节(Details of CANopen message syntax)
      • NMT模块控制(NMT Module Control)
      • NMT节点守护(NMT Node Guarding)
      • NMT启动(NMT Boot-up)
      • PDO
      • SDO
        • 初始化下载域(Initiate Domain Download)
        • 下载分段域(Download Domain Segment)
        • 初始化上传域(Initiate Domain Upload)
        • 上传分段域(Upload Domain Segment)
        • 终止域传输(Abort Domain Transfer)
        • 初始化块下载(Initiate Block Download)
        • 下载块段(Download Block Segment)
        • 结束块下载(End Block Download)
        • 初始化块上传(Initiate Block Upload)
        • 上传块段(Upload Block Segment)
        • 结束块下载(End Block Upload)
        • SDO终止码(SDO Abort Codes)
      • 紧急对象(Emergency Object)
  • 总结

本文是对《CANopen high-level protocol for CAN-bus.pdf》的翻译及解析。由于作者能力有限,如有错误,望纠正!
交流QQ群:429346143。
《CANopen high-level protocol for CAN-bus.pdf》的翻译及解析下载地址: https://download.csdn.net/download/xiuhua_wu/10916762

简介

从OSI七层网络模型角度来观察,现场总线网络(Fieldbus networks)通常只有第1层(物理层,Physical Layer)、第2层(数据链路层,DataLink Layer)和第7层(应用层,Application Layer)。CAN(Controller Area Network)总线也是如此,CAN总线只定义了第1层物理层和第2层数据链路层(ISO1 1898)。这两层完全由CAN硬件处理,从而大大地提高了现场总线节点固件的开发效率。

CAN总线的高级协议通过定义CAN报文的11位标识符和8字节数据的使用方式,从而保证了基于CAN标准的工业化系统的互操作性和互换性。不同制造商要求使用标准化的应用层协议和配置文件(profiles),从而实现了通信系统、设备功能和系统管理的标准化。

  • 应用层(application layer):提供一系列的服务和协议给网络上的每个设备。
  • 通信配置文件(communication profile):提供配置设备和通讯数据的方法,并定义数据如何在设备之间通信。
  • 设备配置文件(device profiles):为设备添加特定于设备的行为。
OSI(七层网络模型) CANopen标准在OSI网络模型的映像

下面将介绍CANopen标准所在的CAN网络CAL(CAN Application layer)、CANopen本身以及定义CANopen的配置文件。

CAL(CAN Application layer)

CAL(CAN Application layer)是基于CAN网络的高层通讯协议之一,由飞利浦医疗系统发展而来。它被独立的CAN用户和制造商集团CiA采用,并进一步开发并发布了一系列的标准。CAL提供了4个应用层服务元素:

  • CMS(CAN-based Message Specification,CAN报文规范):提供了变量(Variable)、事件(Event)、域(Domain)类型的对象,设计和指定如何通过CAN接口访问设备(节点)的功能。
  • NMT(Network Management,网络管理):提供支持网络管理的服务,如:初始化、启动/停止节点、检测节点异常。这个服务是基于master-slave概念实现的。
  • DBT(Distributor,经销商):为网络上的节点提供一个动态分配的CAN标志符(官方称为:COB-ID,Communication Object Identifier)。这个服务是基于master-slave概念实现的。
  • LMT(Layer Management):提供改变层参数的功能,如:改变节点的NMT地址、改变CAN接口的bit-timing和baud-rate。

CMS定义了8个优先级组,每组有220个COB-IDs,取值范围:[1, 1760]。0和[1761, 2031]是NMT、DBT和LMT的保留标识符。在CAN网络中,COB-ID的数值越小,其在网络上的优先级越高。

NOTE:
CAL标准假定CAN2.0A(CAN Standard Message Frame)有11位的标识符,取值范围为[0, 2047],但由于历史原因,实际取值范围限定在[0 , 2031]。在使用CAN2.0B(CAN Extended Message Frame)时,其有29位的标识符,取值范围和优先级仍符合上图的描述,图中的11位范围映射到29位COB-ID的11个最重要的位,表中的COB-ID范围将增大。

CANopen

CAL提供了所有网络管理服务和报文协议,但是它并没有定义CMS对象的内容或通讯对象的类型(it defines how, not what)。CANopen建立在CAL之上,使用了CAL服务和通讯协议的子集,提供了基于CAL服务和协议的分布式控制系统(A distributed control system)的实现,使网络节点能够从简单的功能扩展至复杂的功能,同时不影响网络节点的之间的互操作性。

CANopen的核心概念:设备对象字典(the Device Object Dictionary, OD),这是在其他现场总线系统中使用的概念(Profibus, Interbus-S)。

NOTE
设备对象字典(Object Dictionary)的概念并不是来至CAL,它是CANopen的一个实现方式。

下面,首先先介绍设备对象字典,然后再接收CANopen通讯机制。

CANopen对象字典(CANopen Object Dictionary)

CANopen对象字典(OD)是对象的有序分组,每个对象使用16位索引寻址。为了实现对数据结构体的各个元素进行访问,还定义了一个8位的子索引(sub-index)。CANopen OD的总体布局如下图所示。

NOTE:
不要被OD中小于0x0FFF索引值的数据类型(data type)所迷惑,它们主要是为了定义而存在的。节点OD的实际相关范围为[0x1000, 0x9FFF]。

网络上的每一个节点都存在一个OD,OD包含了描述设备及其网络行为的所有参数。节点的OD主要是以EDS或纸质的数据库(database)形式存在。这不一定需要通过CAN总线查询(interrogate)节点OD中的所有参数,只要节点的行为和其在纸上的OD描述完全一致,就足够了。节点本身必须能够显示所有强制性OD条目(由CANopen指定,这些条目实际上非常少)和可选的条目(如:节点的可配置功能)。

CANopen是通过配置文件(profiles)形式定义的:

  • 通讯配置文件(Communication profile):描述了OD的一般形式、OD中通信配置文件相关的对象以及通讯参数,通常也描述CANopen的通讯对象(Communication object)。这个配置文件适用于所有的CANopen设备。
  • 设备配置文件(device profile):各种设备配置文件为特定类型的设备定义OD对象。现在大约有5种不同的设备配置文件,还有几种正在开发中。

配置文件描述了每个OD对象的功能(function)、名称(name)、索引(index)、子索引(sub-index)、数据类型(data type)、对象是否强制的(mandatory)或可选的(optional)、对象是否只读(read only)、只写(write only)或可读/写(read/write),等等。

NOTE:
设备通讯功能和对象、其设备特性相关的对象及其默认值的描述是以电子数据表(Electronic Data Sheet, EDS)的形式提供,EDS是具有严格定义语法ASCII文件。

The description of a device’s communication functionality and objects and its device-specific objects and their default values is proviced in the form of an Electronic Data Sheet (EDS), an ASCII file with a strictly defined syntax.

单个设备的对象配置描述以设备配置文件(Device Configuration File, DCF)形式提供,其结果与EDS相同。

A description of the object configuration of an individual device is called a Device Configuration File (DCF) and has the same structure as an EDS.

EDS和DCF的文件类型都在CANopen规定中定义。

配置文件定义了哪些OD对象是强制的,哪些OD对象是可选的。强制对象的数量需要保持在允许的最小实现(lean implementation)。通讯部分和设备特性相关的部分的可选功能可以根据需求添加,以扩展CANopen设备的功能。若有更多的特征被要求加入配置文件,那么配置文件需要有足够的空间来添加制造商相关的功能。

因此,描述通信参数的OD部分对所有CANopen设备都是相同的(也就是说,放置在OD中的对象是相同的,而不是对象的值)。同时,OD中不同设备特性相关的部分对于不同设备来说是不同的。

CANopen communication

上面我们已经介绍了对象字典的概念,那么现在我们来看看CANopen网络中通讯报文的内容和功能,换个词语表达:CANopen 通讯模型(CANopen Communication model)。

NOTE:
请确保OD对象(以OD索引和子索引作为特征)和通讯对象或消息(以COB-ID或CAN标识符为特征)已区分。

CANopen通讯模型定义了4种消息(messages, communication object):

  • 管理消息(Administrative meaasge)
  • 服务数据对象(Service Data Object, SDO)
  • 过程数据对象(Process Data Object, PDO)
  • 预定义消息或特殊功能对象(Predefined messages or Special Function Objects)

上述的communication object以小节的形式进行描述。

管理消息(Administrative message)

管理消息(Administrative meaasge)包含三个内容:

  • 层管理(Layer Management)
  • 网络管理(network management)
  • 标识符分发服务(identifier distribution services)

如:初始化(initialisation)、配置(configuration)、监督网络(supervision of the network,包含节点/生命守护(node/life guarding))等。

服务和协议是依据CAL的LMT、NMT和DBT服务元素定制的。这些服务都是遵循Master-Slave 概念:在CAN网络中,有且只有1个LMT、NMT和DBT Master,有1个或多个Slaves。

服务数据对象(Service Data Object,SDO)

每个SDO作为客户机(client)通过对象字典的索引(index)和子索引(sub-index)访问设备字典(设备作为server)中的条目,索引信息包含在CAN消息中的前几个字节中。

依据CAL的表述,SDO被实现为“多路复用域”(Multiplexed Domain)类型的CMS对象,因此允许传输任意长度的数据。在必要时数据会被分割成多个CAN消息,此时,数据占用超过4个字节。

SDO协议属于“确认服务”(confirmed service)类型:每个CAN消息生成一个应答(一个SDO需要2个CAN 标识符)。SDO请求和应答消息总是包含8个字节,因此通过SDO进行通信的开销相当大。携带协议信息的非有效字节数总是最为第一个字节的一部分显示。

过程数据对象(Process Data Object,PDO)

PDO用于传输实时数据:数据从一个生产者(producer,有且只有1个)传输至一个或多个消费者(consumers)。数据传输限制在1~8字节,如:一个PDO最大可传输64个数字I/O值或4个16位模拟输入。

PDO没有协议开销(It has no protocol overhead)。PDO的数据内容仅通过其CAN 标识符定义,并且假定发送方(sender)和接收方(receivers)都知道该内容。

每个PDO由对象字典中的两个对象描述:

  • PDO通讯参数(PDO Communication Parameter):包含PDO的COB-ID、传输类型、抑制时间和计时器周期。
  • PDO映像参数(PDO Mapping Parameter):包含映射到PDO的对象字典中的对象列表,包含它们的大小(单位:bits)。PDO的生产者(producer)和消费者(consumers)都必须知道映射关系,以便能够解析PDO的内容。

PDO消息的内容都是预定义的或者在网络启动时配置的。应用程序对象在PDO中的映射都是在设备字典中的PDO映射参数中描述的。如果设备支持可变PDO映射,那么还可以通过SDO消息对PDO消息的内容进行配置。

PDO有如下的传输模式:

  • 同步(Synchronous):通过接收同步对象(SYNC object)进行同步。
    ♢ 非周期(Acyclic):同步非周期信息。
    █ 远程传输请求:传输是由来自另一个设备的远程传输请求“预先触发”(remote transmission request)。
    █ 指定对象(设备)特定事件:传输是由设备配置文件中指定的对象(设备)特定事件的发生“预先触发”。
transmission is ‘pre-triggered’ by the occurrence of an object- (device-)specific event specified in the device profile.

♢ 周期(cyclic):每1/2条或最多240条同步消息后,会周期性地触发传输。

transmission is triggered periodically after every 1, 2 or up to 240 SYNC messages.
  • 异步(Asynchronous)

    • 传输由来自另一个设备的远程传输请求(通过CAN远程帧)触发。
    • 传输是由设备配置文件中指定的对象(设备)特定事件的发生触发的。如:an input-change-of-value 或计时器事件。

下图介绍了CANopen中PDO传输类型的定义。对于类型1到240,数字表示两个PDO传输之间的同步对象的数量。

每个PDO可分配1个抑制时间(inhibit time),用于定义两个连续PDO传输之间的最小时间,以防止网络上的等待(starvation)。抑制时间是PDO通信参数对象的一部分。类型:unssigned 16-bit;单位:100us。

每个PDO可以分配一个事件计时器周期(event timer period)。在一个时间计时器周期内,当指定的时间已经过去,PDO传输将周期性地触发(没有出现替代触发器)。类型:unssigned 16-bit;单位:1ms。

依据CAL的说法,PDO是一个存储-事件(Stored Event)类型的CMS对象的实现。这意味着数据PDO数据传输是没有协议开销的,并且消息没有应答机制(PDO只需要1个CAN标识符)。最大能传输8字节(64比特)的数据。

预定义消息或特殊功能对象(Predefined messages or Special Function Objects)

预定义消息或特殊功能对象包含如下内容:

  • 同步(Synchronization, SYNC)
  • 时间戳(Time Stamp)
  • 紧急(Emergency)
  • 节点/生命守护(Node/Life Guarding)
  • 启动(Boot-up)

同步(Synchronization,SYNC)

SYNC用于网络范围内的同步任务(尤其是与驱动程序相关的任务)。实际输入的数值准时地(quasi-simultaneously)存储在全网中,若要求传输,输出值将根据上一次的SYNC接收到的信息进行更新。

Used to synchronize tasks network-wide (particularly relevant for drive applications): actual values of inputs are stored quasi-simultaneously network-wide and subsequently transmitted (if required), output values are updated according to messages received after the previous SYNC.

SYNC基于Master-slave概念:SYNC主机发出周期新同步对象,SYNC从机在接收端(reception)执行(carry out)同步任务。

关于SYNC消息传输的同步PDO的传输是在给定的时间窗口内进行的。

Transmission of a synchronous PDO is within a given time window with respect to the transmission of the SYNC message.

SYNC在实现中是“基本变量”(Basic Variable)类型的CMS对象。

CANopen建议在高优先级组中设置一个COB-ID,确保定时同步信号。为了保证消息尽可能的短,SYNC不传输任何数据字节。

时间戳(Time Stamp)

Time Stamp为应用程序设备提供公共的时间帧参考,在实现中是“存储事件”(Stored Event)类型的CMS对象。

紧急(Emergency)

Emergency是右设备内部故障的发生而触发的,在实现中是“存储事件”(Stored Event)类型的CMS对象。

节点/生命守护(Node/Life Guarding)

Node/Life Guarding基于Master-slave概念。

Life Guarding:NMT Master 监控节点的状态称为生命守护(Life Guarding)。在接收到来至NMT Master的第一个节点守护信息后,Life Guarding在NMT Slave中启动。

检测(Detects)到设备网络接口中的错误,而不是设备本身的错误,将通过Emergency报告。

Node/Life Guarding根据NMT节点保护协议实现。一个从NMT Master到特定节点的远程传输请求,将触发一个应答,应答中包含节点的状态。

启动(Boot-up)

Boot-up基于Master-slave概念。通过发送Boot-up消息,NMT Slave 向NMT Master表明其已经从初始化状态过渡到运行前(peroperational)状态。

小结

SDO和PDO都是用于数据传输的,它们实现了两种不同的数据传输机制。

  • SDO用于(大的)低优先级的设备之间的数据传输,最常应用于CANopen网络设备的配置。
  • PDO用于快速的8字节的数据传输,或者,没有协议开销的数据传输(这意味着数据内容要预定义)。

CANopen设备必须支持许多的网络管理服务,并至少需要一个SDO。每个CANopen设备,无论是生产者(produces)或者消费者(consumes)要处理数据就必须有至少一个PDO。所有的其他通信对象都是可选的。

CANopen设备的CAN通信、OD和应用程序之间的关系如下图所示。

CANopen预定义的连接设置(Predefined Connection Set)

为了减小简单网络的配置工作量,CANopen定义了一个强制性的默认CAN标志符分配方案。这些标志符在初始化后立即进入预操作状态(Pre-Operational State),可以通过动态分配(dynamic distribution)的方式进行修改。设备必须仅为支持的通信对象提供相应的标识符。

分配方案(The allocation scheme)是基于将11-bit的CAN标识符分成4-bit功能码(function code)和7-bit节点标志符(Node-ID)实现的。

Node-ID是由系统集成商(system integrator)定义的,如:在设备上设置DIP开关。Node-ID的取值范围为1~127,0值是不允许使用的。

预定义连接设置定义了:

  • 4个接收PDOs
  • 4个发送PDOs
  • 1个SDO(出现2个CAN标志符)
  • 1个Emergency对象
  • 1个Node-Error-Control标识符

预定义还支持未确认的NMT模块控制服务(NMT-Module-Control services)、SYNC和Time Stamp对象的广播(broadcasting)。

CAN标识符分配方案如下图所示。


标识符分配对应Master/Slave连接集,因为所有对等(peer-to-peer)的标识符都是不同,那么实际上只有Master设备才知道所有已连接的Node-IDs,Master设备可以与任意单个已连接的Slave节点(up to 127 nodes)以对等的方式通信。两个已连接的Slave是不能够通信的,因为他们并不知道对方的Node-ID。

将默认的CANopen集合(set)的标识符映射与CAL的映射进行比较,可以清楚地看到,具有特殊功能定义的CANopen对象映射到CAL的通用CMS对象时,表明CANopen通过使用更通用的CAL设施(facilities)实现一个系统。

CANopen标识符分配(identifier distribution)

CANopen的CAN标识符(或者COB-IDs)的分配有三种改变途径:

  • 使用预定义的Master/Slave连接集
  • 上电后修改PDO标识符
  • 使用CAL DBT服务

使用预定义的Master/Slave连接集

标识符的分配是默认的,无需配置。若节点支持对PDO数据内容进行配置,那么PDO可配置是必须的。

上电后修改PDO标识符

当节点是预操作状态,使用SDO写入新值到节点OD的合适位置。

使用CAL DBT服务

连接到CANopen网络的节点或者Slave最初是通过已配置的Node-ID标识的。Node-ID可以通过设置设备上的DIP开关或者通过CAL的层管理服务(LMS)来进行配置。当网络初始化或引导时,网络Master首先与每个已连接的Slave通过“连接远程节点”(Connect Remote Node)电报(telegram)方式建立(establishes)个对话框(dialog)。

NOTE:
连接远程节点电报(Connect Remote Node telegram)是一个CAL NMT服务。

一旦建立此对话框后,用于SDOs和PDOs通讯的CAN标识符将分配到使用CAL DBT服务的节点上,这要求节点必须支持扩展启动(extended boot-up)。

CANopen 启动过程(boot-up process)

在网络初始化过程中,CANopen支持所谓的扩展启动(extended boot-up)以及所谓的最小启动过程。扩展启动时可选的,但是,所有CANopen设备或节点必须支持最小启动。这两种类型的节点可以同时存在于同一个网络中。

当标识符是通过CAL的DBT服务分配的,那么节点必须支持扩展启动。两种初始化过程都可以用设备或节点状态转换表示,如下图所示。

NMT服务用于在任意时间将选定的或所有的节点带入各种操作状态。携带NMT服务的CAN消息由CAN-Header(COB-ID=0)和2个字节组成。第1个字节包含请求服务(“NMT命令说明符”(NMT command specifier)),第2个字节包含Node-ID或者0(0表示寻址所有的节点)。

在CAN网络中,有且只有1个节点是NMT Master。NMT Master发出NMT消息并控制节点初始化过程。

若CANopen设备只支持最小启动,那么这个设备称为:最小功能设备(minimum capability devices)。最小功能设备在设备初始化结束后,自动地进入Pre-Operational状态。在这种状态下,可以通过SDO对设备参数化(device parameterization)和COB-ID分配。

通过将设备切换到Prepared状态,设备被迫地完全停止通信,如果设备支持并处于活动状态,那么设备仍可进行NMT服务和节点保护(node guarding)。

CANopen消息语法的细节(Details of CANopen message syntax)

在下面的章节中,将介绍COB-IDs是如何在CANopen预定义连接集中定义的。

NMT模块控制(NMT Module Control)

只有NMT Master能发出NMT模块控制消息,所有的Slaves必须支持NMT模块控制服务。NMT模块控制消息是没有响应的。NMT模块控制消息格式如下:

NMT节点守护(NMT Node Guarding)

NMT Master通过使用节点守护可以检测每个节点的当前状态,尤其是,当这些节点没有定期轮循数据时,这个方法特别有用。

NMT Master发送一个CAN远程帧(remote frame,no data bytes)格式如下:

NMT Slave回复如下:

或者(Alternatively),节点可以配置为周期性的心跳消息(periodical Heartbeat message):

当带有心跳的节点启动时,它的启动信息是其第一个心跳消息。心跳用户通常是NMT Master,它应该为每个带心跳的的节点提供超时机制,并且在超时后提供适当的操作。

NOTE:
节点不允许同时支持节点保护和心跳协议。

NMT启动(NMT Boot-up)

NMT Slave发出启动消息,向NMT Master表明它从初始化状态进入了预操作状态。

PDO

举个例子,假设第2个发送PDO的映射如下所示(在CANopen中,由OD的0x1A01条目描述):

在CANopen的I/O模块的设备配置文件(CiA DSP-401)定义中,对象0x6000的子索引0x02是节点的8bits数字输入的第二个集合;对象0x6401的子索引0x01是节点的16bits模拟输入的第一个集合。

PDO发送的CAN消息包含3个数据字节,如下所示:

通过改变对象0x1A01的内容,可以改变PDO的内容(如果节点支持可变PDO映射(variable PDO mapping))。

多路复用PDO(Multiplexor PDO,MPDO)定义,允许单个PDO通过在消息字节中包含源(source)或目标(destination)Node-ID和OD索引和子索引来发送多个变量。举个栗子,某个节点有64个16Bits模拟通道,如果没有这样的机制(mechanism),那么需要16个不同的发送PDOs来发送它的消息。

SDO

SDO用于访问设备的OD。OD访问的请求程序,称为Client;若CANopen设备的OD被访问并为请求提供服务,那么这个设备称为Server。Client的CAN消息和Server 回复的CAN消息均是由8Bytes组成(尽管并非所有字节都必须包含有意义的数据)。Client端的请求总是由Server的回复确认的。SDO传输有两种机制:

  • 快速传输(Expedited transfer):用于长度不超过4字节的数据对象。
  • 分段传输(Segmented transfer):用于长度超过4字节的数据对象。

SDO的基本结构:

SDO Command Specifier 可包含如下信息:

  • 下载/上传(download / upload)
  • 请求/响应(request / response)
  • 分段/快速传输(segment / expedited transfer)
  • CAN帧的数据字节数量(number of data bytes in this CAN-frame)
  • 每个后续段的交替切换位(alternating toggle bit for each subsequent segment)

SDO共有5种请求/响应协议:

  • 初始化下载域(Initiate Domain Download)
  • 下载分段域(Download Domain Segment)
  • 初始化上传域(Initiate Domain Upload)
  • 上传分段域(Upload Domain Segment)
  • 终止域传输(Abort Domain Transfer)

在最新的CANopen通信配置文件版本中,一个新的SDO传输机制是这么介绍的,块传输(Block transfer):为了增加长度大于4字节的对象的总线吞吐量,多个段数据由1个确认消息确认(从Server下载,从Client上传)。相关协议如下:

  • 初始化块下载(Initiate Block Download)
  • 下载块段(Download Block Segment)
  • 结束块下载(End Block Download)
  • 初始化块上传(Initiate Block Upload)
  • 上传块段(Upload Block Segment)
  • 结束块上传(End Block Upload)

NOTE:

  • Download:写到OD中;Upload:从OD中读出。
  • 这些协议的SDO Command Specifier(SDO CAN消息的第一个数据字节)的语法和细节如下面小节所示。
  • “-”表示don’t care,应该置为0。

初始化下载域(Initiate Domain Download)

下载分段域(Download Domain Segment)

初始化上传域(Initiate Domain Upload)

上传分段域(Upload Domain Segment)

终止域传输(Abort Domain Transfer)

SDO的Client或者Server可以通过发送带以下SDO Command Specifier的消息来终止一次SDO传输。

在终止域传输的情况下,数据字节0和1包含对象的索引,字节2包含对象子索引,数据字节4~7包含描述中止原因的32位中止码。

初始化块下载(Initiate Block Download)

下载块段(Download Block Segment)

结束块下载(End Block Download)

初始化块上传(Initiate Block Upload)

上传块段(Upload Block Segment)

结束块下载(End Block Upload)

SDO终止码(SDO Abort Codes)

SDO终止码(SDO Abort Codes)在byte4-7,大小:32bits。

紧急对象(Emergency Object)

Emergency messages 是由设备内部(致命)错误情况发生而触发的,并从相关应用程序设备传输到具有最高优先级的其他设备。它们也用于中断类型错误警报。一个Emergency messages由8字节组成,格式如下:

紧急错误码(Emergency Error Codes)如下表所示。其中,“xx”部分表示有设备配置文件定义。

错误寄存器是在设备OD(索引:0x1001)中。设备可以在这个状态字节中映射内部错误,提供当前错误的快速概览。位含义如下图所示:

Bit Error type
0 通用的(generic)
1 电流(current )
2 电压(voltage)
3 温度(temperature)
4 通信(communication)
5 设备配置文件特性(device profile specific)
6 Reserved(=0)
7 制造商特性(manufacturer specific )

NOTE
制造商特性(manufacturer specific )错误字段可能包含关于错误的任何奇特与设备相关的附加信息。

总结

综上所述,基于CAN总线的完了通讯 CANopen标准具有如下的特点:

  • 设备功能的标准化描述是设备对象字典的一种方式。
  • 设备的标准化描述和它的配置都是采用ASCII格式文件:电子数据表(EDS)和设备配置文件(DCF)。
  • 基于CAL CMS的数据交换与系统管理。
  • 基于CAL NMT的标准化系统启动和节点保护。
  • 系统范围同步操作的定义。
  • 定义特定于节点的紧急消息。

通过遵循CANopen通信配置文件和相应的CANopen设备配置文件中包含的指导方针,两个独立的制造商可以生产标准化的设备,这些设备可以被合并到同一个CANopen CAN网络中。

可以区分下面3个级别的兼容性(安装兼容性的增加顺序):

  • 一致性(Conformance):应用层兼容性。设备可以连接到CANopen网络,而不会干扰其他设备的通信。
  • 互操作性(Interoperability):通信配置文件兼容性。设备可以与网络中的其他节点交互数据。
  • 可交换性(Interchangeability):设备可以替代另一个设备配置文件兼容性。

CANopen设备至少需要(最小能力设备):

  • 一个Node_ID
  • 一个OD(内容由设备功能而定)
  • 一个支持强制OD条目(read-only)的SDO
  • 支持以下NMT Slave服务
    • Reset_Node
    • Enter_Preoperational_State
    • Start_Remote_Node
    • Stop_Remote_Node
    • Reset_Communication
  • 默认配置文件ID分配

【CANopen】CAN总线的高级协议详解相关推荐

  1. CANopen总线的高级协议详解

    目录 简介 CAL(CAN Application layer) CANopen CANopen对象字典(CANopen Object Dictionary) CANopen communicatio ...

  2. CANopen总线的协议详解

    目录 简介 CAL(CAN Application layer) CANopen CANopen对象字典(CANopen Object Dictionary) CANopen communicatio ...

  3. AXI接口协议详解-AXI总线、接口、协议

    转自:https://cloud.tencent.com/developer/article/1695010 AXI接口协议详解-AXI总线.接口.协议 AXI 总线 上面介绍了AMBA总线中的两种, ...

  4. NVMe协议详解(二)

    NVMe协议详解(二) 2. PCIe寄存器配置 2.1 PCIe总线的基本结构 2.2寄存器配置 2.2.1 PCI header 2.2.2 PCI Capabilities 2.2.3 PCI ...

  5. STM32常用协议之IIC协议详解

    提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档 IIC协议详解 前言 一.IIC协议简介 1.1 简介 1.2 IIC物理层 1.3 协议层 1.3.1 IIC基本读写过程 1.3. ...

  6. APB3.0协议详解

    文章目录 1.协议详解 1.1协议发展 1.2master与slave区别 2.APB3.0端口列表 3.读写时序 1.写数据无等待 2.写数据有等待 3.读数据无等待 4.读数据有等待 1.协议详解 ...

  7. 大数据WEB阶段(八)Tomcat服务器安装与详解、HTTP协议详解

    Tomcat 一. 服务器 动态web资源运行需要服务器环境 客户端发送请求到服务器 , 服务器调用动态web资源 Servlet容器 . web容器 .服务器 Servlet容器 java中的动态资 ...

  8. FPGA学习之路—接口(2)—I2C协议详解+Verilog源码分析

    FPGA学习之路--I2C协议详解+Verilog源码分析 定义 I2C Bus(Inter-Integrated Circuit Bus) 最早是由Philips半导体(现被NXP收购)开发的两线时 ...

  9. 协议详解_I2C协议详解

    I2C通信协议 I2C通信协议的基础 简介 I2C「Inter-integrated Circuit」总线支持设备之间的短距离通信,用于处理器和一些外围设备之间的接口,它只需要两根信号线来完成信息交换 ...

最新文章

  1. Visual Assist x 无法自动补全Snippet提示的解决方法
  2. Linux+GitLab+Jenkins实现项目的持续集成
  3. AT2339-[AGC011C]Squared Graph【黑白染色】
  4. Mac软件损坏,无法打开,允许任何来源后依旧损坏
  5. CLISP语言中的哈希表
  6. 入门嵌入式HTML/CSS/脚本引擎 sciter
  7. Sql Server约束的学习一(主键约束、外键约束、唯一约束)
  8. 数据挖掘技术研究现状
  9. WidsMob Viewer Pro Mac(照片与视频管理查看工具)
  10. OC Foundation框架 集合
  11. 2016年服装行业软件排名—许鹏
  12. 互联网公司创业的7道槛
  13. linux ubuntu bionic,如何升级Ubuntu到18.04 LTS Bionic Beaver
  14. 基础知识之————直方图
  15. c语言输入任意长度字符串,读取不定长字符串输入
  16. 互联网公司程序员完整的晋升路径!
  17. ElasticSearch windows部署(避坑干货)
  18. android微信下拉页面,Android仿微信下拉列表实现
  19. 软件工程——软件测试(黑盒测试、白盒测试、测试分析报告)
  20. 玩转Java8Stream之函数式接口

热门文章

  1. C语言,有一个已排好序的数组,要求输入一个数后,按原来排序的规律将它插入数组中
  2. 使用Arduino UNO以及好盈电调控制无刷电机
  3. 测试不同体重体型软件样子的,为什么有的人身高、体重相同,体型却不一样?这是体脂率在作祟...
  4. 实现阿里云物联网平台设备信息到微信小程序分享过程
  5. 阿里云Nginx配置站点403Forbidden问题
  6. β版本展示博客-第二组(攻城喵组)
  7. J2EE--自定义mvc增删改查
  8. 笔记本当服务器显示器怎么连接,笔记本连接显示器,详细教您笔记本怎么连接显示器...
  9. 电子邮件客户端:Mail Pilot 3 for Mac
  10. 创建nfs服务器启动httpd服务但是访问的一直都是欢迎页面