笔者深耕工业通信领域这20多年里，处理过成成千上万通信问题，但是今天要讲的这两个奇怪的IO控制器报错还真是次遇到，非常少见！下面我就把解决这个故障的整个思路和过程分享给你，希望对你有启发。

这个故障发生在一条使用夹具的产线上。每个夹具都配备了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模式冲突根本原因。

就这样，通过一步步抽丝剥茧般的探索和分析，我们终于解开了这个谜团！

作者：赵欣