引用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。

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