IO模块的兼容性运行

场景

• 当你组态了一个低版本的模块，实际插入一个高版本的模块，那么下载并且可以正常运行。
• 当你组态了一个高版本的模块，实际插入一个低版本的模块，那么下载后模块不能被参数化。
• 当你组态的模块个实际的模块连MLFB和moduleIdentID都不一致，但是官方告诉你可以兼容性运行，那么下载并且可以正常运行。

报错行为

• 如果在博图环境下，兼容性运行大概率可以在IO模块自身的在线诊断中看到不一致的主要内容，但是模块LED的行为绿灯常亮，PLC/IM也不会把兼容性运行表现在诊断buffer或者LED行为中，它们也会保持绿灯常亮。
  
  

这种情况连mlfb，版本，moduleIdentID都不一致，但是官方认为可以兼容性运行（从IO模块固件的角度）。

• 如果在classic step7 环境下，直接表现不出任何不一致信息，你不会分辨出此时模块是否处于兼容性运行状态。
  • 做了一个实验：把同一个IOD在博图和经典step7环境下分别组态然后下载运行，只有博图能看到差异信息。
• 由博图和classsic step7上的行为差异得出结论：IO模块的不一致信息来自于ES的处理结果。

原因分析

• 从PN-CM分析：
  

1. 连接请求和连接应答
2. 参数化请求和参数化应答
3. ready application请求以及module diff报告和ready application应答

• 从IOD应答的报文中，可以找到substitute state,它报告了兼容性差异，注意，这不属于alarm,对于IOC，会把substitute state当作正常模块处理。
  

取决于固件逻辑，固件选择把这种不一致当作兼容性，那么就可以是substitute state；如果固件把这种不一致当成异常，则会给出"wrong module"。
一致的module会被记为proper module, 报文中可能会发，也可能不会，取决于IOC怎么问。

• 上述行为是IOD-IOC之前的PN通信，不涉及ES。但是最终ES表现出来的现象却有差异，只能说明ES之前有差异。

拓展

• 如果想获得模块的实际插槽信息，可以用proneta使用C001得到：
  

proneta在读写任意DS的时候，都会和IOC建立一条隐式的AR，不同于IOC-IOD之间的建连过程，proneta-AR可以不带任何预期组态，比较实际和预期差异的结果(比如预期C000,差异E002)也会是0.