EtherCAT 網路已進入 OP，為什麼資料仍無法即時更新？
本案例將 HORIBA 流量計透過 Anybus ABC3113 接入西門子 PLC。系統雖然能夠建立通訊，流量計也已進入 EtherCAT OP 狀態，但 PLC 端的數值卻可能經過數分鐘才出現變化。
經過 EtherCAT 封包擷取、正常組對照與初始化設定比對後，最終確認問題來自流量計 EtherCAT ESC 與 I/O Mapping 模式的相容性。將映射方式由 Legacy Mode 改為 Overlapping Mode 後，流量計即可正常回應 LRW 訊框，PLC 端資料也恢復即時更新。
Application background
案例背景：將 EtherCAT 流量計接入西門子 PLC
客戶希望將具備 EtherCAT 介面的 HORIBA 流量計整合至西門子 PLC。由於控制器端使用 PROFINET，因此系統採用 Anybus ABC3113，在兩種工業網路之間交換製程資料。
在這套架構中，ABC3113 於 EtherCAT 網路擔任 MainDevice，負責掃描及管理流量計；另一端則以 PROFINET IO-Device 身分與西門子 PLC 通訊。PLC 因而能夠透過 PROFINET 取得流量計的 EtherCAT Process Data。
這套架構需要完成的三項工作
- 在 EtherCAT 網路中辨識流量計並建立循環資料交換。
- 將 EtherCAT Process Data 映射至閘道器的內部資料區。
- 透過 PROFINET 將對應資料提供給西門子 PLC 讀寫。
Observed symptom
異常現象：通訊已建立，資料卻數分鐘才更新
現場網路可以建立通訊，EtherCAT 流量計也已進入 OP 狀態，但西門子 PLC 讀到的數值變化非常緩慢，有時需要兩分鐘以上才更新一次。這與流量計實際持續變化的量測結果明顯不符。
為了排除流量計本身的量測問題，技術人員將同一台流量計直接接入 Beckhoff PLC，並透過 TwinCAT 觀察資料。測試結果顯示數值能夠即時更新，因此問題較可能出現在兩套 EtherCAT MainDevice 的初始化方式或循環資料交換差異。
Packet analysis
擷取 EtherCAT 訊框，找出正常組與異常組的差別
ABC3113 發出 LRW，流量計卻未穩定回應
由於僅從 PLC 數值難以判斷原因，技術人員進一步擷取 EtherCAT 網路封包。分析結果顯示，流量計雖已進入 OP 狀態，ABC3113 也持續發出邏輯讀寫 LRW 訊框，但流量計多數時間沒有回應。
這項結果可以直接解釋資料更新緩慢的現象：當 SubDevice 沒有正常處理循環訊框，閘道器就無法持續取得新的輸入資料；偶爾出現的回應也沒有固定週期，因此 PLC 端只能不規則地看到數值變化。
接入 Beckhoff PLC 時，LRW 回應與資料更新均正常
同一台流量計接入 Beckhoff PLC 後，封包中可以觀察到裝置持續回應邏輯讀寫 LRW 訊框，TwinCAT 內的數值也能即時變化。這項對照進一步排除了流量計量測功能及一般線路連接問題。
Configuration comparison
深入比對：FMMU 起始位址與 I/O Mapping 模式
確認兩套架構的封包表現不同後，排查重點轉向 MainDevice 對流量計的初始化設定。比對結果發現，ABC3113 與 Beckhoff PLC 在 FMMU 起始位址及 I/O Mapping 模式上存在兩項差異。
差異一：FMMU 起始位址不同
FMMU（Fieldbus Memory Management Unit）負責將 EtherCAT 邏輯位址對應至各 SubDevice 的實體記憶體區域。案例中，ABC3113 使用的 FMMU 起始位址為 0x00000000，Beckhoff PLC 則使用 0x01000000。
0x00000000 開始。
0x01000000 開始。FMMU 位址差異提供了一個排查方向，但後續分別調整兩項設定後，確認它並不是造成此次異常的主要原因。
差異二：Legacy 與 Overlapping I/O Mapping
真正影響流量計回應的是 I/O Mapping 模式。ABC3113 原先採用 Legacy Mode；Beckhoff PLC 則使用 Overlapping Mode。兩者都是 EtherCAT 規範中的資料映射方式，但輸入與輸出資料在邏輯位址中的安排方式不同。
| 比較項目 | Legacy／Non-overlapping Mode | Overlapping Mode |
|---|---|---|
| 資料安排 | 輸入與輸出使用分開的邏輯位址區域。 | 輸入與輸出資料可在同一段邏輯位址中重疊配置。 |
| 訊框配置 | 資料配置較為直觀，但使用較大的邏輯位址空間。 | 可讓循環資料配置更緊密。 |
| 本案例表現 | 流量計未能穩定回應 LRW 訊框。 | 流量計正常回應，資料恢復即時更新。 |
| 選用原則 | 應依 SubDevice 使用的 EtherCAT ESC、設備文件及實際相容性測試決定。 | |
Root cause and result
根因確認：流量計 ESC 不支援 Non-overlapping Mapping
技術人員分別修改 FMMU 起始位址與 I/O Mapping 模式進行驗證。測試結果顯示，只有將映射方式改為 Overlapping Mode，才能讓流量計持續回應 ABC3113 發出的 LRW 訊框。
重新檢查流量計文件後，進一步確認該設備使用 TI AM335x EtherCAT ESC，而文件註明其不支援 Non-overlapping Mapping。這表示原先採用的 Legacy Mode 雖屬 EtherCAT 支援的映射方式，卻超出該流量計 ESC 的實際相容範圍。
最終解決結果
改用 Overlapping Mode，資料恢復即時更新
- 流量計開始持續回應 ABC3113 發出的 LRW 訊框。
- 西門子 PLC 能夠正常取得即時變化的流量資料。
- 確認 FMMU 起始位址不是本次異常的主要原因。
- 後續透過韌體調整，將 Overlapping Mode 納入對應產品版本。
Troubleshooting workflow
EtherCAT 資料更新異常的排查流程
當 EtherCAT 網路已進入 OP 狀態，但 PLC 端資料沒有更新或更新速度異常時，應從實際循環資料交換開始驗證，而不是只依賴裝置狀態或設定畫面。
-
1
確認網路狀態與異常範圍
確認 MainDevice、SubDevice 是否進入 OP，並判斷異常發生於單一設備、單一 PDO，或整個 EtherCAT 網路。
-
2
比對實際量測值與 PLC 數值
確認感測器或設備端的資料是否持續變化，避免將量測來源沒有更新誤判為通訊異常。
-
3
擷取 EtherCAT 循環訊框
觀察 MainDevice 是否持續發送 LRW，以及 SubDevice 是否正確處理訊框與更新 Working Counter。
-
4
建立正常組進行對照
將同一設備接至已知可正常運作的 EtherCAT MainDevice，比對封包、初始化流程及資料更新情況。
-
5
比對 FMMU 與 PDO 設定
檢查邏輯位址、輸入輸出長度、PDO 順序與資料方向是否一致，並確認沒有位址重疊或缺口。
-
6
確認 I/O Mapping 模式
比較 Legacy、Non-overlapping 或 Overlapping 等映射方式，確認 SubDevice 使用的 ESC 是否有特定限制。
-
7
查閱設備與 ESC 文件
確認設備製造商是否註明支援的 EtherCAT 功能、Mapping 模式、PDO 限制或已知相容性問題。
-
8
調整後重新擷取與驗證
完成設定或韌體調整後，再次確認 LRW 回應、Working Counter、PLC 資料及長時間運作穩定性。
Integration planning
規劃 EtherCAT 與 PROFINET 整合時，應確認哪些條件？
選擇工業通訊閘道器時，不能只確認兩端是否列出 EtherCAT 與 PROFINET。還需要確認閘道器在兩端扮演的角色、可管理的裝置數量、Process Data 規模，以及 SubDevice 的 EtherCAT 功能與映射限制。
整合前的四項確認重點
- 兩端通訊角色 確認 EtherCAT MainDevice／SubDevice，以及 PROFINET Controller／IO-Device 的對應關係。
- Process Data 規模 盤點輸入與輸出資料量、PDO 數量、資料方向及 PLC 所需的更新週期。
- 設備相容性 確認 EtherCAT ESC、CoE、PDO 與 I/O Mapping 模式的支援範圍。
- 驗證與診斷方式 確認是否能查看裝置狀態、資料交換結果，並在異常時進行封包與 Working Counter 分析。
專案評估資訊
- 設備端協議
- EtherCAT
- 控制器端協議
- PROFINET
- 設備角色
- MainDevice／SubDevice
- 資料項目
- 輸入、輸出與 PDO
- 更新需求
- 週期與即時性
- 驗證依據
- 封包與設備文件
實際選型仍應依 PLC 型號、設備數量、PDO 配置、通訊週期、EtherCAT ESC 與現場網路架構進行確認。
Conclusion
從 OP 狀態深入到實際 Process Data
這起案例說明，EtherCAT 網路能夠進入 OP 狀態，不代表所有循環資料都已按照預期交換。面對「通訊正常但資料不更新」的問題，封包擷取、正常組對照及 ESC 文件往往比反覆修改 PLC 程式更接近真正原因。
透過比較 LRW 回應、FMMU 起始位址與 I/O Mapping 模式，技術人員最終確認流量計不支援 Non-overlapping Mapping，並以 Overlapping Mode 解決資料更新異常。這套排查方法也能作為其他 EtherCAT 裝置整合專案的參考。
Frequently asked questions
EtherCAT I/O Mapping 常見問題
EtherCAT 已進入 OP 狀態，為什麼 PLC 資料仍不更新？
OP 狀態表示 SubDevice 已進入可交換 Process Data 的運作階段，但不能單獨證明每個循環訊框都獲得正確回應。應進一步檢查 LRW 訊框、Working Counter、PDO 映射與 PLC 端的實際更新情況。
Legacy Mode 與 Overlapping Mode 的主要差別是什麼？
Legacy／Non-overlapping Mode 將輸入與輸出配置於分開的邏輯位址區域；Overlapping Mode 則允許輸入與輸出資料重疊配置，使資料安排更緊密。兩者都屬 EtherCAT 映射方式，但設備使用的 ESC 不一定同時支援兩種模式。
本案例是修改 FMMU 起始位址後解決的嗎？
不是。FMMU 起始位址是排查過程發現的差異之一，但分別修改設定後，確認真正產生影響的是 I/O Mapping 模式。改用 Overlapping Mode 後，流量計才恢復正常回應 LRW 訊框。
如何判斷 EtherCAT 裝置是否有 I/O Mapping 相容性問題？
可將同一台設備接至已知正常的 EtherCAT MainDevice，比對 LRW 回應、Working Counter、FMMU 與 PDO 配置。接著查閱設備及 ESC 文件，確認是否限制 Non-overlapping 或其他 Mapping 模式。
ABC3113 在本案例中扮演什麼角色？
ABC3113 在 EtherCAT 端擔任 MainDevice，負責管理流量計並取得 Process Data；另一端則作為 PROFINET IO-Device，將對應資料提供給西門子 PLC。
所有 EtherCAT 資料更新異常都能透過 Overlapping Mode 解決嗎？
不能。Overlapping Mode 是本案例的解決方式，但資料更新異常也可能由 PDO 長度、位址配置、線路品質、同步設定、Working Counter、設備狀態或 PLC 程式造成。應先取得封包證據，再依設備文件調整設定。
Industrial communication integration
需要整合 EtherCAT 裝置與既有 PLC 網路？
宏虹可依設備角色、通訊協議、資料量與控制架構，協助評估 Anybus 閘道器選型及整合方向。
