EtherCAT I/O Mapping映射模式

今天跟大家分享客户使用Anybus EtherCAT主站网关ABC3113将HORIBA流量计接入西门子PLC时遇到的问题和解决过程，这既是一个典型的应用案例，又让我们在解决问题的过程中加深了对EtherCAT协议的理解。

1.客户需求

客户使用EtherCAT主站网关ABC3113，将HORIBA流量计（EtherCAT接口）接入西门子PLC中，这是一个非常常见的应用，通过网关实现不同网络协议的设备与PLC之间的数据交互。

2.客户遇到的问题

客户反馈整个网络可以通讯，但是在PLC中读到的流量计的数据变化很慢，大概2分钟或者更长时间才改变一次，但实际上流量计的数据变化基本上是实时的。同时客户也测试了将流量计直接接入倍福PLC中，在TwinCAT中看到数据变化是实时的。

3.初步分析

根据客户的描述，我觉得非常奇怪，这个网关很多客户已经用在将伺服驱动器接入西门子PLC的现场应用中，没有反馈有数据更新慢的问题。我的第一反应这个流量计有问题，但是客户测试了接在倍福PLC中没问题，数据的变化是实时的。这就很让人费解，并且我跟客户进行了远程测试，确实如客户所说数据变化非常慢。

至此，仅从表面现象很难确定问题在哪，只能抓取EtherCAT网络数据报文来进行分析。

上图是流量计接入网关ABC3113中EtherCAT网络报文，可以看到已经进入OP状态，但是逻辑读写LRW报文只有网关发出的报文（红色方框标记），没有流量计回复的逻辑读写LRW报文，这样就解释了为什么读取到的数据几乎没有变化，因为流量计基本不回复，输入数据当然不会变化了。

同时我们也抓取了流量计接入倍福PLC中的报文，流量计正确的回复逻辑读写LRW报文，数据在实时变化。

4.深入探究

现在有了报文，也从报文上解释了通过网关读取到的数据变化非常慢，从抓取到的报文看到流量计大部分时间不回复逻辑读写LRW报文，偶有回复也很随机，有时两三分钟，有时半个小时毫无规律。那么为什么会出现这种问题呢？为什么网关发送的报文流量计不回复，倍福PLC发送的报文它就回复呢？带着这个问题，我们对网关和倍福发送的初始化报文进行了梳理和对比分析，发现了2处不同之处：

1. FMMU的起始地址不同

在网关中FMMU起始地址是从0x0开始，倍福PLC使用的0x01000000。

2. I/O mapping方式不同

网关使用的是Legacy mode，倍福PLC使用的Overlapping mode。

解释一下这两种模式，我们把数据看做是一个高速行驶的列车，列车头是前面的报文头，数据部分是一节节车厢。如下图所示，主站发送输出数据，数据经过每一从站设备时，设备从输出区取走数据，并把输入数据填入输入区。这两种映射方式都是协议规范支持的，只是Overlapping mode更紧凑一些。

5.问题解决

有了这2个方向的猜测后，我们修改了网关底层固件，分别修改了FMMU起始地址和I/O映射方式。经测试后发现将网关的I/O映射方式改为Overlapping mode，流量计就可以正确的回复报文了。

从下方的报文中，我们可以看到流量计都正确的响应了网关发送的LRW报文（红色方框标记）。

最后我们又仔细查看了流量计手册，发现它使用的是TI AM335x ESC芯片,从该芯片手册中看到“TI EtherCAT 从站不支持non-overlapping映射模式”，同时也不对该bug进行修复。鉴于别的厂家产品也可能会用到TI的这款ESC芯片，我们对网关的固件进行了正式升级，使用Overlapping mode取代Legacy mode的I/O映射方式。

纸上得来终觉浅，绝知此事要躬行。

最后大家如果有关于EtherCAT通讯的相关问题，欢迎留言与我们讨论。

审核编辑 黄宇