引用4楼详细内容：

这个MODBUS TCP功能块是这样运行的。

当客户端REQ出现一个0-1的上升沿时，它会复制这些接口的设置到内部一个静态区，然后以这个区为基础；若没有连接，则去建立连接；（占用连接ID，发起连接对方。）然后开始通讯；直到完成，输出Done/Error。在此期间是不理会接口的变化的。若REQ仍然是1，则继续下一个的通讯，把数据区指针的数据加载，发送。若遇到网络断开故障，它会重试。

在此期间，你改变端口设置（是设置，不是内容数据。）是没用的！

（你可以改，为下次REQ上升沿做准备。）

只有下一个REQ上升沿出现时，才会再次复制接口的这些参数到那个静态区。这意味着这个固定连接ID属于“长连接”（不是每次都要握手、完成后自动断开。它一直保持这个连接。）

当服务器（对方）是“挂了”“宕机”，重新启动后，对方就失去了保持的连接。这时，需要本方的客户端复位连接，重新发起连接SYN标识。这样才可以恢复连接。

客户端使用断开连接未必可行。因为断开连接发送的是FIN（断开连接请求！）而重新初始化的服务器是在等待SYN（连接请求。）

因此，复位连接，应该使用的是T_RESET通讯指令。这个在MODBUS _TCP客户端的背景DB中。（怎么使用，我也不知道。）

不行就是自己写一行该指令复位。

引用2楼详细内容：

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

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

具体描述如下：

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

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