引用12楼详细内容：

    佩服!

    我手头刚好有个案子，正有此疑惑：一台1214C接串口服务器，串口服务器有８个串口，各接一个外围485设备。

    PLC用ModbusTCP通信，做客户端；串口服务器做服务器端，里面设置好每个串口对应一个485设备的ID号。

    假设串口的顺序是X1、X2、X3、X4、X5、X6、X7、X8，对应外围设备的ID号顺序是9、10、11、12、13、14、15、16。如下图

    PLC先读X1串口的485设备（用了一次MB_Client指令），读完后，要去读X2串口的485设备，这时就修改MB_Client背景数据块里的ID号，即MB_Unit_ID，修改完后，再启用MB_Client指令。那么，在二者切换的时候，要不要先断开，再重建，才能真正实现轮询?

引用3楼详细内容：

Conn-ID是对一个已经存在的通信线程对象的引用。

你自己改的数值，这个数值对应的通信线程对象为null，根本不存在，所以指令自动给修复回来。

但是TCP通道传输，那是高速行为，对时序动作的要求是非常严格的。虽然连接ID自动修复回来了，但在这之前，server指令就已经因为参数错误，被破坏了。server端，因为瞬间突然失去通信线程对象，功能失败。

可以按照我顶楼说的原理和例子，一旦出错，就摧毁连接并重建，并停止MBTCP指令调用。

client和server两端，都是这样重建conn，诊断确认conn的状态ok后，再调用Client端指令，重新开始ModbusTCp。

80A3这个代码是T_Diag的status码，它的含义就是指通信线程对象不存在。

在MB-Server实例内部，你可以看到，其实也是通过那几条基础指令来实现功能。所以高层通信指令，都是底层通信指令的应用实例。

引用2楼详细内容：

再贴一下我遇到的问题吧，因为ModBusTCP也是基于楼主提到的那些基本的TCP/UDP指令封装的。遇到问题后我通过操作背景数据块，测试了一些重连方法，并没有解决问题。

当然，这些纯属好奇，因为正常程序不会有我这种手动更改Connection_ID操作。

具体描述如下：

两个西门子PLC走MODBUS TCP，通讯成功的情况下，手动把服务器的Connection_ID改掉，虽然系统会马上把你手动改的值覆盖成正确值，但此时通讯已经掉线，服务器这边会报80A3。

这种状态下重启服务器可以恢复通讯，暂时没找到其他方法。