今天跟大家分享客戶使用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通訊的相關問題，歡迎留言與我們討論。