这个问题，其实官方没太说清，基于个人经验分享一下。

TCP/UDP通信的一个连接资源，是用一个CONN-ID来标识，其实就是一个static thread（静态通信线程）。

什么是静态线程？玩过上位机的都明白。就相当于平行运行在另一个CPU核芯中的一个OB。

这个OB有自己的扫描周期。这个OB里面就是具体完成TCP/UDP的底层实现细节的代码和实例。这一切都被官方隔离看不见，只暴露了一个线程实例对象的CONN-ID作为使用接口。

自己开发上位机也是如此。上位机需要为每一个下位的PLC节点保持一个通信线程，保持持续的侦听和收发。这个线程对象必须是静态的，保证它的持续存在和数据一致。

比如你有5个下位PLC，就要建立5个静态通信线程对象，各自独立平行运转，构成一个上位机整体框架中的位于最底部的通信层。

通信层之上的业务数据的往来处理和数据库进出，还有顶部的UI层，都是建立在最底部的多个通信线程对象的基础上，也都是由多个不同功能的对象组成。所谓层就是多个对象的集合，这就是通常所说的面向对象编程。对象就是PLC中所说的实例，Instance。

至于构成这些各层的对象从哪里来？都是从负责生产具体功能对象的工厂对象来，这就是IT行业的设计模式中提到的几种工厂模式。

现在人们都普遍采用面向接口的抽象框架，这种与实体对象的解耦设计。所以上位机的主体框架，都变成由一大堆抽象接口搭建构成，而执行具体功能的诸多对象都被剥离出去，单独管理。这被称为控制反转和依赖性注入。目的就是为了使整体框架的共性基础本质的抽象更纯粹，而不是为了特定对象才设计出来的，增加通用性和扩展性。

这另外一个CPU核芯，可以是分时间片运行CPU机制中的另外一部分，比如通信负荷的20%设定之类，也可以是真正多核CPU的另外一个物理核芯。这就要看价钱，以及官方有多么垄断黑和暴利。

所谓通信资源的数量限制，就是允许你建立多少个不同的专用线程。这种限制就是真正榨利润的拿捏之处。其实这东西成本根本不值钱，都是论斤批发上货的。

通信是工业的核心基础，所以线程的限制往往都卡在通信上。为啥S7不开源。都是垄断和利益之争。

进口、国产、软硬件生态之争都在其中，正在发生。

其实所有的后台异步指令，都是像这样存在于平行运转的另外CPU核芯中。区别就是线程的内容不同，静态与动态的选择不同。

动态的对象，才是人们通常所说的对象。随着需求，被临时创建出来，用完了就销毁和释放资源，下次用到再重新创建和分配资源。temp变量就这样。static变量都是相对多耗费资源的。

当PLC的TCP/UDP通信出现故障的时候，这也包括ModbusTCP和S7通信故障，这个后台通信线程其实还是一直存在的，CONN-ID还是被一直占用的，只是线程里面的运行出了问题。

这时候，你如果想直接建立一个相同ID的新连接是不行的，必须先把此ID的连接断开，也就是先把这个线程对象释放和摧毁掉，然后新建一个相同ID的新线程，这就是重建。

如果你新建的连接ID是不同的，那就是另建一个连接。

关于新建、重建、另建，需要用到以下4个官方指令。这几个指令的合理运用，可以保证连接修复是可靠的。连接的存在和状态可控了，在此连接之上运用的各种以太网协议收发指令就容易和OK了。

TCON：建立以太网连接

TDISCON：断开以太网连接

T_DIAG： 诊断连接

T_RESET： 复位连接

以下给了几个代码截图例子，演示一下这几个指令运用的可选思路，供大家参考。

1、用TCON和TDISCON去新建和另建的基本逻辑。这是一个单元FB的内部。

2、上述单元被调用，去上电后建立两个UDP连接的一个例子。

3、当连接出现阻塞故障的时候，用T_Reset去重建这两个连接的例子。

修复UDP连接的过程和效果，如下Trace图

T_DIAG指令可以获得连接的状态信息，比较简单不展示了，看看帮助就懂。

其实都是在理解原理基础上的调度设计，也不复杂，根据各自场景需求，灵活多变。

再有，连接这件事尽量用指令控制，而不要用组态。组态等于用常量编程，且组态在代码之外。

尽量一起用代码叙述，便于资源控制和调试诊断；尽量用变量编程。