這個故障發生在一條使用夾具的產線上。每個夾具都配備了CPU1515F作為智能設備，并且通過一些復雜的設置與IO控制器X2接口相連。然而，使用”ReconfigIOSystem”在使能設備加入的過程中，IO控制器卻報出了兩個奇怪的錯誤：“Diagnostics available and is Being processed”和“Multi-interface mismatch-inconsistent parameterization for sending LLDP data”。
為了揭開這個故障的神秘面紗，我們決定進行抓包分析。通過 Bany 捕捉使能智能設備加入前后的報文，希望能找到故障產生的根源。我們發現子槽號0x8000為接口模塊上存在錯誤1，Fault:Fault available，但詳細原因卻不得而知，只知道這與控制器診斷緩沖區中的提示“Diagnostics available and is Being processed”一致。
進一步探究發現，控制器發送Read.Req給智能設備以獲取詳細診斷信息，最終確定故障為擴展通道的診斷，即ExtChannelDiagnosis(0x8002)，錯誤類型為“Multiple interface mismatch”。這也與控制器診斷緩沖區中的提示Multi-interface mismatch-inconsistent parameterization for sending LLDP data”一致。
但這些故障信息在西門子手冊和網站中都無法找到，只能參考 PROFINET 相關的標準文件。深入研究這些標準文檔，我們需要理解多接口這個神秘的概念。
現場設備通常只有一個接口，如ET200SP，其LLDP報文有著特定的規則。然而，有些智能設備，例如CPU1515卻存在2個網絡接口，情況變得更加復雜。
回到故障中，我們發現報文中的一些細節暗示著多接口模式存在問題。繼續在標準中探索，終于了解到Multipleinterfacemode.nameofdevice模式沖突的真正含義。
而多接口模式的設置，竟隱藏在連接過程的寫數據記錄中。
經過仔細分析，我們發現還是硬件組態出了問題。原來，控制器寫入了單接口模式給智能設備，但默認的智能設備的硬件組態LLDP v2.3，那么必然在用戶的硬件組態中，有其它的IO設備有一個被設置為LLDP v2.2模式，最后在IO控制器的X1接口所連接的一個IO設備發現了這個不經意間所組態的LLDP v2.2。這就導致了一系列連鎖反應，最終使得智能設備的兩個接口出現了Multipleinterfacemode.nameofdevice模式沖突根本原因。
就這樣，通過一步步抽絲剝繭般的探索和分析，我們終于解開了這個謎團！
作者：趙欣
