(笔记)EtherCat报文格式详解

 

说明:本文是从EtherCat初学者的角度来撰写的,详细介绍的其报文格式,特别是应用层与Canopen之间的关系。特别感谢:https://zhuanlan.zhihu.com/p/406428272?utm_id=0的贡献。

 

EtherCAT这个名词不仅仅只是代表着一个报文数据格式约定层面的通讯协议,它的从设备是需要使用专用的通信芯片才可以完成传输的,比如EtherCAT的开发者“倍福(Beckhoff)公司“的官方原厂芯片ET1100,其他的各个芯片厂商会取得倍福公司的内核授权,开发相关芯片,如亚信的AX58100等等。

从物理层来看EtherCAT的通信电信号和我们普通的以太网一样,通信线也是使用普通网线+RJ45接口、或者光纤连接。因此理论上任意一个网卡模块都可以收发EtherCAT的数据内容,因此对于主站而言,使用普通的电脑通过网线连接一个EtherCAT从站就可以实现通信了,但是EtherCAT对于从站的要求就有特殊的定义,必须要使用专业的芯片才能完成,这个芯片被称为ESC。

关于从站芯片的特殊性、从站芯片的数据处理以及实现原理,本文不对此进行深入介绍,因为这部分内容参考倍福公司文档、视频;以及网上的各种资料可以有更好的理解,何况其内容之多是不适合用文档进行描述,本文只是重点介绍应用开发人员需要了解的EtherCAT的通信知识,帮助开发者上手EtherCAT的通信理解。

简单的说,应用开发者可以把EtherCAT分为两层:链路层和应用层,本文是以EtherCAT的从设备开发上,对这两层进行介绍。

 

一、EtherCAT链路层

EtherCAT的从设备是必需要使用专用的通信模块才能实现的,从设备方案上一般是使用MCU(或其他控制器)+ESC芯片来实现。链路层的功能就是在ESC芯片上完成解析、发送的;通过配置ESC芯片,使芯片正常运行链路层功能并把应用层的数据交给MCU。

ESC芯片还具有一个特点,那就是通常会给这个芯片外挂一个EEPROM存储器,里面可以保存一些芯片初始化的寄存器配置,这样就不需要每次上电后由MCU或主站来进行配置了。

 

对于开发者而言,链路层的原理只需要知道EtherCAT的模型概念:

报文是由主站发出,然后像一条列车一样发往各个从站,每个从站认为是串联起来的,会按照目前串联的位置顺序对数据进行发送,就像是列车的轨道一样;每到一站,数据就像货物一样可以以极快的速度进行上下车,到达最后一站就开始原路返回(在网线上看就是在同一根网线里的TX和RX,其中TX就是列车出发的方向,RX就是返程的方向。每个从设备一般有两个以太网口,一个口对接上一个从设备,另一个对接下一个从设备,而对应连接的两条网线在本地被“连接“成了一条网线,所以整个网络的所有网线可以认为是同一根网线。),数据每经过一个往返就完成了一次通信,主站就是列车的起始站,所有通信都是由主站发起并把控的。

 

1.1、EtherCAT数据帧格式

首先,需要了解EtherCAT帧格式,如图:

 

 

如图所示,报文的起始数据我们看到了熟悉的内容:以太网帧头,只是其中的帧类型是EtherCAT专有的0X88A4,后面的就是EtherCAT的数据内容了。这与我们熟知的网络通信格式不同,不是遵循着TCP/IP的分层格式,没有网络层和传输层。

图中清晰明了的显示了EtherCAT的格式中的各个部分,其中“第三行“的子报文格式结构中的”数据“段就是属于应用层的内容了(也称为一个”邮箱“数据),而其他部分都是由EtherCAT的链路层进行解析的,MCU不需要也无法参与其解析工作。

帧格式说明如下图所示(列出了除了子报文格式的其他内容,子报文格式放到1.2章中进行说明):

 

 

其实EtherCAT也还是能支持嵌入了UDP/IP格式的数据帧格式的(只是EtherCAT数据段会让出28个字节长度给UDP/IP段使用),如图:

 

 

1.2、EtherCAT链路层通信机制

要了解EtherCAT的链路层通信机制,首先就要明白EtherCAT通信链路层的通信“目标“,也就是通信到底是需要交换什么东西,数据内容又是怎么呈现的?

这个问题的答案就是:EtherCAT的链路层定义每一个从设备都具有一个数据空间,被称为DPRAM,这段空间长度为16位,范围为0x0000~FFFF,主站与从站的通信目标就是能够读、写这段空间内允许被访问的数据。这段空间存在于从站的ESC芯片里,主站和从站MCU都可以访问这段空间(这段空间需要SM进行管理,后文会进行说明),从而作为中间缓存提供给应用层和主站之间建立起通信的桥梁。

好,明确了这个目标之后,我们就要开始了解实现这一目标的方法了,我们可以分两步来进行:

1、主站与从站ESC芯片通信,并可以通知MCU数据的到达等功能。

2、从站MCU与ESC芯片通信。

其中,第1步就是链路层的通信机制需要实现的内容了,这个通信机制主要的内容就是子报文来实现的。

关于子报文,我们从上文的1.1章可以看到一个完整EtherCAT数据包中可以有多个子报文,这里的多个子报文并不是指有几个从设备就一定对应着有几个子报文,而是每个子报文中都有自己的指令逻辑可以寻址找到要通信的从站。

 

1.2.1、子报文说明

配合1.1章中的EtherCAT数据帧格式,子报文格式说明如图:

 

 

简单的说,主站发出来的子报文就是通过上图中的“命令“配合”地址区“和“长度”寻址到目标从设备,从而对”数据区“中的内容进行读、写操作。这里主要就是对”命令“、”地址区“、“长度”、“数据区”四个部分进行说明,其他的内容不是初学者急需了解的,可以查看相关资料就行。

 

首先需要了解一下子报文的命令码:

 

 

一个子报文想寻址到要找的从站,可以分四种命令:顺序、设置、逻辑、广播寻址。与上图中的指令描述一一对应。

1.2.1.1、顺序寻址与设置寻址

  • 顺序寻址:就是按照网络连接的顺序,从主站往后数的从站编号,按照负数递减寻址对应的从站,比如0为第一个从站,-1为第二个从站……依次递推。
  • 设置寻址:就是给每个从设备分配一个“从站地址”,通过找到对应的从站地址来确定通信的从站,也是传统主从网络中常见的形式。从站地址可以在ESC外挂的EEPROM中预先设置好,也可以是通信过程中进行修改。

由于这两种寻址方式只是固定地址与位置顺序的区别,其他的方面几乎一致,所以也统称为“设备寻址”,设备寻址的指令对子报文格式中的“地址区”的使用如下图:

 

 

其中地址区被分为”16位的从站地址+16位的从站内存地址“,再配合子报文格式中的“长度”和“数据区”,子报文就找到要寻址的从设备,并对数据内容进行交互了。顺序寻址只是在网络初始化阶段时被使用,对每个从站设备的从站地址进行读写,而后面的通信通常都是使用设置寻址来进行。

1.2.1.2、逻辑寻址

逻辑寻址是另一种更加灵活的寻址方式,基本概念主要需要了解以下几点:

1、我们从前文知道了每个从站的ESC芯片中都有一个16位长度的物理空间,其实主站也有自己的空间,不过是32位长度的,4G大小的“数据逻辑地址”空间。

2、逻辑寻址就是把主站的“数据逻辑地址”与从站的“物理空间”映射起来,一旦映射好了之后,主站访问从站数据就像是访问自己的内部空间一样,只需要发出指定要读写的“数据逻辑地址”即可达成目的。所以使用逻辑寻址的子报文格式中的“地址区”的使用就不是前文的设备寻址的格式了,而是一整段32位地址区来表示主站要访问的“数据逻辑地址”。

3、主站的“数据逻辑地址”与从站ESC的“物理空间”映射是需要在使用逻辑寻址指令通信之前就映射好,进行这个映射功能就是由从站的ESC芯片内的FMMU完成的。

 

由于FMMU是ESC中的一个功能模块,在ESC中有专门配置FMMU的相关寄存器,寄存器的具体地址和FMMU的个数可以查看具体使用的ESC芯片手册,但是寄存器的内容都是一样的,如图是一个映射的例子:

 

 

 

 

如图中的例子,映射一旦分配好了之后,主站就可以在子报文中使用逻辑寻址的相关指令,访问“数据逻辑地址”0x00014711时,就可以操作配置了这个FMMU的从站的0x0F01的物理地址的数据了。这里可以看出逻辑寻址有以下几个特点:

1、逻辑寻址完全不关心从站的地址,只关心有配置了FMMU的从站是否映射了当前要访问的逻辑地址。

2、多个从站都可以配置FMMU映射到主站的同一片逻辑地址,这种情况下主站对一个逻辑地址的操作就可以同时对多个映射的从站进行操作。

 

1.2.2、存储同步管理SM

在前文中我们已经了解到了EtherCAT的链路层通信机制,也就是主站是怎么与从站ESC芯片的物理空间进行数据交互的,那么很容易联想到一个问题:ESC的物理空间既可以被主站操作,也可以被从站的MCU操作,怎么保证这两者的操作的正确性,以及通知对方另一方有最新的操作需要处理?

这就是ESC芯片中的一个功能模块:存储同步管理(SM)的功能需要解决的了,SM用于阻止主站和从站MCU同时访问 ESC存储区,确保数据的一致性,以及通知MCU数据到达等功能。也就是说从站MCU与主站之间通信需要指定ESC的物理空间作为缓存,那么这片缓存必然要被SM进行管理才可以合理的使用,SM管理的区域就是从站MCU应用层与主站之间的通信交互通道。

SM既然是ESC芯片内的一个功能块,也和FMMU一样,有专门的寄存器进行配置,具体可以查看ESC芯片手册,寄存器会有以下功能:

 

 

这里不对SM寄存器多做介绍,具体内容还是查看芯片手册,但是需要说明的是SM中可以配置它所管理的物理地址,可以配合FMMU共同指向某片物理空间,使这片空间既可以被逻辑寻址所访问,也同时受到SM的管理:

  1. 当SM配合FMMU共同指向一片物理空间的情况,就是用来传输“周期性过程数据”的,也就是“PDO数据”,此时SM中的运行模式配置为3个缓存区以保证数据的一致性。从站MCU通过分别使用SM2和SM3两个通道来接收和发送主站的数据所指向的物理空间由于有FMMU映射,可以使用逻辑寻址进行访问。
  2. 当SM不配合FMMU共同来管理一片物理空间时,就是用来传输“非周期性数据”的,也就是“邮箱数据”,此时SM中的运行模式配置为1个缓存区,而从站MCU通过分别使用SM0和SM1两个通道来接收和发送主站的数据以避免读写冲突。这一片物理空间由于没有FMMU管理,所以不能使用逻辑寻址访问,而是通过设置寻址进行访问的。

这里的“PDO数据“、”邮箱数据“就是ESC要与从站MCU交互的数据了,这一部分放到EtherCAT应用层进行描述。

 

二、EtherCAT应用层

首先,先看一张EtherCAT描述总图:

 

 

在结合了前文的链路层讲解之后,配合这张图进行进行理解,会有更直观的感受,图中的DL层就是前文1章节的内容了,前文最后提到了邮箱数据和过程数据,就是要提交给应用层的内容了,所以我们可以看到图中的AL层就是MCU内部要处理的应用层了。

EtherCAT应用层协议支持VOE\FOE\EOE\COE等,本文的应用层主要介绍的是COE,也就是CanOpen Over EtherCAT,顾名思义也就是把CanOpen协议通过EtherCAT来实现,CanOpen协议在本文中不做过多的介绍,可以查看CanOpen相关的资料进行了解,在了解COE这部分内容时,要建立在对CanOpen协议了解的基础上进行,本文认为读者已经了解了CanOpen的对象字典、SDO、PDO的前提下进行说明。

 

2.1、CanOpen与COE

在看到COE这个词的时候,最容易想到的一个问题就是:原本CanOpen是基于CAN通信方式来设计并实现的,与EtherCAT的通信链路不一样啊,CAN报文含有的ID和8字节数据段,也不是像EtherCAT的列车式的数据运输方式,那么是怎么移植到EtherCAT上来进行通信的呢?

其实就是EtherCAT把CAN通信中的ID部分做了一些变化,这里就以CanOpen中的两个重要通信数据:SDO和PDO进行描述。

2.1.1、COE中实现SDO

对于SDO数据而言:COE中把CAN ID的概念变成一个“类型“参数与CAN的数据段8字节内容全部放到EtherCAT的子报文格式中的“数据区“里,作为一个“邮箱数据”进行发送。邮箱具有专门的格式,如图所示:

 

 

邮箱数据头说明:

 

 

邮箱协议中的“命令“格式如下图:

 

 

邮箱协议的“命令“说明:

 

 

由以上内容,我们看到邮箱的数据格式里,在“邮箱数据头“和”命令“中各有一个”类型“,一个是用来指示使用的应用层协议类型的,一个是用来指示这段数据是应用层协议中的什么服务类型的。图中展示的就是COE协议类型的服务类型。

这里我们看到了熟悉的名字:SDO请求和响应(这就替代了原本CAN通信中的SDO数据的ID),而紧随其后的“命令相关数据“就是原本CAN通信中的8字节数据部分。格式如下图所示:

 

 

关于标准CanOpen的SDO协议内容这里不做介绍,在上图可以看到SDO数据后面还有一段“可选扩展数据“,COE相当于对SDO数据做了改良:在标准CanOpen协议的寄存上,可以使一个SDO数据发送更多的数据量,而不是仅限于原本使用CAN通信只能发送4个字节的数据了。

MCU对邮箱数据的收发接口可以看第第1.2.2章,SM的介绍。

 

2.1.1、COE中实现PDO

从上文的SDO介绍中,我们看到COE协议类型的服务类型里除了由SDO类型,还有PDO类型,那么PDO是否就如同SDO的实现那样,仅仅只是更改这个类型参数,并解析不同的数据格式就可以实现了呢?

这是初学者容易混淆的一个地方,也是COE对于PDO数据定义上我认为比较乱的一个问题,这个问题的答案是否定的;其实,邮箱协议格式里的COE服务类型的PDO类型只是一个预留,并不使用。可以说邮箱只是用来实现SDO数据传输的,PDO数据传输与邮箱数据并没有关联。

现在回过头看上文的第1.2.2章,SM的介绍。有提到SM配合FMMU的逻辑寻址通信方式,这才是实现COE的PDO数据传输的方式。也可以看第2章开头的EtherCAT描述总图,里面也有显示PDO数据的传输方法。

其实PDO数据采用这个方式也是符合了CanOpen原本的设计理念,PDO的数据报文是为了快速传输对象字典的内容,数据段里全是实际数据,不用解析报文协议格式,如果COE中使用邮箱来进行传输其实是违背这一原则的。

PDO数据格式如下图所示:

 

 

 

 

那么很显然,COE中的PDO报文也同样要由映射参数进行映射,如上图所示的例子中,某一个子报文发送的内容是PDO数据,这个子报文通过逻辑寻址找到与逻辑地址映射匹配的从站ESC,并把数据传入FMMU映射的DPRAM物理空间中,这段空间同时也被SM2所管理,于是SM2通知从站MCU从ESC中取走PDO数据。

MCU拿到这段数据之后会根据对象字典进行查找,这里要重点介绍与CanOpen映射逻辑的区别:

1、CanOpen中PDO具有两个参数:“通信参数“和”映射参数“,在COE中不会使用CanOpen中定义的“通信参数“,COE在对象字典中占用了其他的索引定义了专用的参数进行替代,如图所示:

 

 

其中的0x1C00的子索引1~32定义SM0~31这32个通道的通信数据类型,如果定义的是过程数据类型,0x1C10~0x1C2F就会生效,用来定义SM0~31所使用的CanOpen的映射参数(RPDO映射参数:索引=1600~17ffh,TPDO映射参数:索引=1A00~1Bffh)。

2、由于COE在一条报文中可以包含多个PDO,相当于是CanOpen的多个PDO数据合并到一起发送了,所以需要做两次映射,第一次是根据获取数据使用的SM(n)通道通过0x1C10+(n)对象字典中的参数确认这条COE报文中有几个PDO,以及每个PDO映射的CanOpen的映射参数,第二次就是根据CanOpen的映射参数进行PDO映射,确认具体的对象内容。

以上两点区别,配前面的PDO格式说明的例子,需要反复阅读理解。

 

posted on 2023-03-01 10:36  tdyizhen1314  阅读(5873)  评论(1编辑  收藏  举报

导航