conopen协议是怎么回事

Posted 2023-03-28

参考技术A CANopen协议包括通讯子协议（Communication Profile）和各种设备子协议（Device Profile）。通讯子协议描述对象字典的主要形式和对象字典中的通讯子协议区域中的对象，通讯参数，同时描述CANopen通讯对象，这个子协议适用于所有的CANopen设备，如CIA-DS301。设备子协议为各种不同类型设备定义对象字典中的对象，并为对象字典中的每个对象描述了它的功能、名字、索引和子索引、数据类型，以及这个对象是必需的还是可选的，这个对象是只读、只写或者可读写等等。目前已有多种不同的设备子协议，如：DS401、 DS402等。CANopen标准的核心部分是通过对象字典（Object Dictionary）对设备功能进行描述。通过对象字典的入口可以对设备的“应用对象”进行基本网络访问，设备的“应用对象”可以是输入输出信号、设备参数、设备功能和网络变量等。CANopen设备的功能及特性以电子数据表单（EDS）的形式描述，实际的设备设置通过设备配置文件（DCF）进行描述。
大多数重要的设备类型，例如数字和模拟的输入输出模块，驱动设备，操作设备，控制器，可编程控制器或编码器，都在称为"设备子集"的协议中进行描述。设备子集定义了不同类型的标准设备及其相应的功能。依靠CANopen协议集的支持，可以对不同厂商的设备通过总线进行配置。
CANopen标准最核心的部分是通过对象字典（Object Dictionary）对设备功能进行描述。对象字典分为两部分，第一部分包括基本的设备信息，例如设备ID，制造商，通信参数等等。第二部分描述了特殊的设备功能。
一个16位的索引和一个8位的子索引唯一确定了对象字典的入口。通过对象字典的入口可以对设备的"应用对象"进行基本网络访问，设备的"应用对象"可以是输入输出信号，设备参数，设备功能和网络变量等等。
CANopen设备的功能及特性以电子数据单（EDS）的形式描述，EDS采用ASCII格式，可以将EDS理解成某种形式的表格。实际的设备设置通过所谓的设备配置文件（DCF）进行描述。EDS和DCF都可以从Internet上下载，并可以存储在设备之中。

象其他知名的现场总线系统一样，CANopen也分为两种基本的数据传输机制：通过进程数据对象(PDO)对小型的数据进行高速数据交换以及通过服务数据对象（SDO）对对象字典进行访问。后者主要用于在设备配置过程中传输参数以及传输大数据块。进程数据对象通常采用事件触发、循环或请求方式发送，作为广播对象，它的上层并没有附加协议。一个PDO最大可传输8字节数据。在连接一个同步报文的时候，整个网络都可以采用同步方式对PDO进行传送和接收(Synchro-nous PDOs)。通过存储在对象字典中的PDO映射(PDO Mapping)结构，可以对应用对象到PDO对象的分配(Transmission Object)进行调整，这可以保证设备可以对不同的应用需求进行调整。
通过传输SDO可以实现可靠的数据传输，由两个CAN对象在两个网络节点间通过点对点的通信来实现这一过程。通过传输对象字典的索引以及子索引，可以定位相应的对象字典入口。通过SDO传送报文可以不受长度的限制，但传送SDO报文需要额外的协议开销。
标准化的事件触发的高优先级突发报文用于报告设备故障，可以通过中心时钟报文来提供整个系统的系统时钟。准备和协调建立一个分布式的自动化系统所需的功能都适于CAL网络管理（NMT）定义的机制，同样可应用于周期性的节点维护(node guarding)。
可以选择通过"Heartbeat Message"来显示CANopen设备的通信能力。PDO和SDO的CAN报文标识符可以直接通过对象字典的数据结构的入口标志符进行分配,或者，在简单的系统中，也可用预定义的标志符。

对象字典（Object Directory）
对象字典是每个CANopen设备的中心元素，它描述网络上设备的所有功能。对象字典描述了网络和应用程序之间的接口，所有对象字典的入口都引用16位的索引和8位子索引。对象字典包含所有通过网络访问的参数，例如：设备标识符、生产商名，PDOs和SDOs的通信参数，设备监控（“error control”）都保存在对象字典的通用区。设备描述区包含IO功能（开关量和模拟量的输入和输出），设备参数，PLC映射。如果发生错误，对象字典还可以配置其行为。因此，对象字典可以使设备行为符合各自的应用。
设备描述
设备描述表描述了自动控制系统中主要设备类型的属性和特点。定义了标准设备类型的功能和参数，所有的参数都保存在对象字典中。这样，就保证了CANbus用同一方式访问CANopen 设备。通过不同生产商设备的互用性和可交换性，为广大的多客户需求提供了先决条件。为开关量和模拟量的I/O设备，PLC设备和控制器定义了设备描述表。在标准的EDS文件中用ASCII形式描述了CANopen设备的参数和属性。它作为一个包含所有设备属性的表格访问网络。专门设备配置的实参保存在DCF（device configuration file），DCF是继承于EDS。
使用PDO/SDO进行数据传输
CANopen的数据传输包含两个不同的数据传输机制，CANopen是用过程数据对象（PDOs，Process Data Object）处理短过程数据的快速交换。通过SDO（Service Data Object）访问对象字典的入口。PDO根据事件约束，循环或查询传输，其传输是无协议广播形式。一个PDO传输可以达到八个字节，一个同步信息同步网络上数据的发送和迁移。每个PDO的属性可以在对象字典中配置，包含通信参数（CAN标识符，传输类型等等）和为每个PDO映射分配过程数据。SDO通过2个CAN-telegrams证实数据传输，两个设备间建立了点对点的通信。这样，大的数据包（大于8字节）能被传输给每个SDO。
网络管理
网络管理(NMT)用来管理网络设备的状态，它是主从关系的结构。CANopen设备通过一个启动报文发送一个信号给NMT master，这个启动报文是在网络上被初始化、激活的。用NMT命令可以改变单个设备或整个网络设备的状态，每一个设备的状态是由特定属性决定的。只有在OPERATIONAL状态，PDO才能被传输；在PRE_OPERATIONAL的条件下配置设备。监控CANopen设备的通信状态可选“Node-Guarding”或“Heartbeat”，为报告设备错误定义了报警报文，这些高优先级的紧急报文通过事件导向传输；错误发生时，标准的错误代码详细描述了错误信息。
CANopen Safety
CANopen网络上集成了安全功能（例如：Emergency OFF，Two-handed operation），可以安全传输信息。专用的safety－relevant services（SRDO，Safety Relevant Data Object）接受通信，一个SRDO传输高达8个字节的安全信息，传输数据是在一个定义的时间窗口中完成的。
协议介绍：
CiA DS 301: CANopen 应用层和通讯的描述
CiA DS 304: CANopen 安全相关的通讯架
CiA DS 401: CANopen 本地I/O模块的设备描述
CiA DS 404: CANopen 检测设备和闭环控制器的设备描述
CiA DS 405: CANopen 符合IEC61131-3便准的可编程设备的设备和接口描述
CiA DS 406: CANopen 编码器的设备描述
DS301：定义了应用层和通讯规范，包括对象字典、服务数据对象、过程数据对象、网络管理对象等。
DS302：定义了网络启动的步骤、主节点和管理节点的定义、可编程设备的输入/输出定义、冗余通讯的方式。
DS305：待查
DS401：定义了通用I/O模块的设备规范，主要定义了对象字典中6000H到6FFFFH之间的内容。
DS402：定义了运动控制的设备规范。
DS405：定义了IEC61131标准设备规范，主要定义了A000H到A6FFH之间的内容。
其中DS401、DS402和DS405均提供了默认映射数据。

wireshark抓包，协议全部显示为unknown是怎么回事

协议没有启用

全部启用,OK

参考技术A For libpcap, the first thing you’d need to do would be to get DLT_* values for all the link-layer protocols you’d need. If ISO 9141 and 14230 use the same link-layer protocol, they might be able to share a DLT_* value, unless the only way to know what protocols are running above the link layer is to know which link-layer protocol is being used, in which case you might want separate DLT_* values.
For the rest of the libpcap discussion, I’ll assume you’re working with libpcap 1.0 or later and that this is on a UN*X platform. You probably don’t want to work with a version older than 1.0, even if whatever OS you’re using happens to include libpcap - older versions are not as friendly towards adding support for devices other than standard network interfaces.
Then you’d probably add to the pcap_open_live() routine, for whatever platform or platforms this code should work, something such as a check for device names that look like serial port names and, if the check succeeds, a call to a routine to open the serial port.
See, for example, the #ifdef HAVE_DAG_API code in pcap-linux.c and pcap-bpf.c.
The serial port open routine would open the serial port device, set the baud rate and do anything else needed to open the device. It’d allocate a pcap_t, set its fd member to the file descriptor for the serial device, set the snapshot member to the argument passed to the open routine, set the linktype member to one of the DLT_* values, and set the selectable_fdmember to the same value as the fd member. It should also set the dlt_count member to the number of DLT_* values to support, and allocate an array of dlt_count u_int+s, assign it to the +dlt_list member, and fill in that list with all the DLT_* values.
You’d then set the various *_op fields to routines to handle the operations in question. read_op is the routine that’d read packets from the device. inject_op would be for sending packets; if you don’t care about that, you’d set it to a routine that returns an error indication. setfilter_op can probably just be set to install_bpf_program. set_datalink would just set the linktype member to the specified value if it’s one of the values for OBD, otherwise it should return an error. getnonblock_op can probably be set to pcap_getnonblock_fd. setnonblock_op can probably be set to pcap_setnonblock_fd. stats_op would be set to a routine that reports statistics. close_op can probably be set to pcap_close_common.
If there’s more than one DLT_* value, you definitely want a set_datalink routine so that the user can select the appropriate link-layer type.
For Wireshark, you’d add support for those DLT_* values to wiretap/libpcap.c, which might mean adding one or more WTAP_ENCAP types to wtap.h and to the encap_table[] table in wiretap/wtap.c. You’d then have to write a dissector or dissectors for the link-layer protocols or protocols and have them register themselves with the wtap_encap dissector table, with the appropriate WTAP_ENCAP values by calling dissector_add_uint().