這裡有關於產品的常見問題及解決方案。

相較於純軟體主站，EtherCAT硬體主站晶片 (Hardware Master) 有何優勢？

硬體主站方案透過專用晶片處理底層協定，將「通訊」與「控制演算」分離，硬體主站專責「EtherCAT通訊」，上位控制器負責「控制演算法」，核心優勢有：

1. 極致的確定性與低抖動 (Determinism & Low Jitter)

  • 說明：硬體主站的封包發送由專用晶片負責，完全不受上位機作業系統的干擾。

  • 效益：確保微秒級同步精度，滿足高階 CNC 與機器人控制需求。

2. 運算卸載與 CPU 資源釋放 (CPU Load Offloading)

  • 說明：將繁重的 EtherCAT 協議堆疊與錯誤處理工作「卸載」至晶片執行。

  • 效益：上位控制器僅需專注於應用層邏輯，即使是低階 MCU 也能駕馭複雜系統。

3. 硬體級別的故障隔離 (System Isolation & Safety)

  • 說明：硬體主站獨立運作。

  • 效益：即使上位機軟體失能，硬體主站仍能維持EtherCAT週期通訊，防止機械失控風險。

4. 降低開發門檻 (Lower Development Barrier)

  • 說明：無需配置複雜的即時作業系統 (RTOS)。

  • 效益：大幅縮短產品開發週期。

5. 優化總體擁有成本 (TCO Optimization)

  • 說明：無需昂貴的高效能工業電腦 (IPC) 硬體成本與軟體主站授權費用。

  • 效益：顯著降低物料清單 (BOM) 成本。

6. 極致能效與綠色永續 (High Efficiency & Eco-friendliness)

  • 說明：專用晶片功耗僅為毫瓦 (mW) 等級；相較之下，運行軟體主站的高時脈 CPU 功耗動輒數十瓦 (W)。

  • 效益：

    • 節能減碳：大幅降低設備運行時的電力消耗與碳排放，符合全球 ESG 與淨零碳排 趨勢。

    • 散熱優勢：低廢熱特性使得控制器設計更易於實現無風扇 (Fanless) 散熱，進一步提升系統可靠度並延長設備壽命。

7. 長期供貨與維護穩定性 (Long-term Availability & Stability)

  • 說明：

    • 硬體主站：晶片採工業級標準，提供長期供貨保證 (Long-term Supply)。硬體規格一旦定案即「凍結」，不會隨意變更。

    • 軟體主站：PC 環境面臨頻繁的 OS 更新、Patch 修補或驅動程式升級。

  • 效益：杜絕「重複驗證」的夢魘。使用硬體主站，能確保工業產品在生命週期內維持一致的性能表現，無需擔心因為一個 Windows 更新或 Linux Kernel 升級，導致即時性 (Real-time) 失效而必須重新耗時調校系統效能。

EtherCAT主站控制晶片ECM-XF、ECM-XFU 與 ECM-XFL有何主要差異？

這三款晶片的主要差異在於上位控制介面 (Host Interface)、最小通訊週期 (Min. Cycle Time) 以及 SPI 傳輸資料量 (Data Size) 範圍。

ECM-XFU: 包含SPI及USB介面，最小可設定週期時間為0.125ms，SPI Data Size可設定32至1048Bytes

ECM-XF: 僅提供SPI介面，最小可設定週期時間為0.125ms，SPI Data Size可設定32至1048Bytes

ECM-XFL: 僅提供SPI介面，最小可設定週期時間為1ms，SPI Data Size 固定112Bytes

ECM-XF系列晶片是否支援 CoE (CANopen over EtherCAT) 或 FoE (File over EtherCAT) 協定？

是的，ECM-XF、ECM-XFU 與 ECM-XFL 全系列皆內建支援 CoE 與 FoE 功能。

但在使用 FoE 進行檔案傳輸時，請留意以下規格限制與對應方案：

  • 單次傳輸限制：晶片內建的 FoE 功能，其單次檔案傳輸大小上限為 256K Bytes。

  • 大檔案解決方案(>256K Bytes)：建議依據從站（Slave）能力選擇以下兩種方式之一：

    1. 分次傳輸 (Split Transmission)：將檔案切割後分批傳送（需確認從站設備是否支援此機制）。

    2. Raw Command 模式：利用 Raw Command 自行實作 FoE 完整傳輸流程（不受晶片緩衝區限制，但使用者需自行處理 FoE 協定封包與狀態機）。

ECM-XF系列主站晶片是否支援FSoE (Safety over EtherCAT) 或 EoE (Ethernet over EtherCAT) 通訊協定？

晶片本身不具備原生的協定堆疊 (Protocol Stack) 支援，但保留了開發彈性。

具體說明如下：

  • 非原生支援：ECM-XF/ECM-XFU/ECM-XFL 的韌體層並未內建 FSoE 或 EoE 的處理邏輯。

  • 進階實作可行性：晶片支援 Raw Command (原始指令透傳) 模式。若您的上位控制器 (Host) 具備處理 FSoE 或 EoE 封包的能力，可利用此模式將晶片作為傳輸通道，自行封裝與解析相關封包。

⚠️ 注意事項：採用 Raw Command 方式開發，使用者必須對 EtherCAT 協定底層有深入了解，並需自行負責協定層的邏輯實作。

上位控制器 (Host) 是否必須搭載即時作業系統 (RTOS) 才能運作？

不需要。ECM-XF系列晶片不強制要求上位控制器具備 RTOS。

由於晶片內部設計了 硬體 FIFO (先進先出緩衝區) 機制，即使上位控制器是非即時系統（Non-Real-Time OS），晶片也能自行調節並維持 EtherCAT 通訊週期的穩定性。

常見的控制方式包含：

1. 使用一般PC或筆電Windows當作上位控制器透過USB與ECM-XFU溝通。

2. 使用嵌入式系統 (Bare-metal):如MCU STM32 或 Arduino等)透過SPI與ECM-XF溝通。

3. 使用單板電腦 (General OS): 如樹苺派 或 BeagleBone 透過SPI與ECM-XF溝通。

💡 何時需要 RTOS？ 雖然晶片能確保「通訊傳輸」的穩定，但「控制運算」的即時性仍取決於上位機。

  • 一般應用 (IO/位置控制)：非 RTOS 系統即可勝任，晶片會處理通訊抖動 (Jitter) 問題。

  • 高階應用 (扭力控制/高速同步)：若您的應用需要極短的響應時間（High dynamic response），建議上位控制器仍應採用 RTOS，以確保控制演算法的運算也能達到嚴格的即時要求。