PortArray

这也是个以数组为主体的UDT类型的管脚参数，但这个名称起的不好。准确说，它是连接到一条modus通路的所有设备FB实例之间的公共数据展示和交互区。是个全局数据。

这和人类在社会生活实践中的经验和道理是一样的。

一个公共的工具或者叫资源，如果被众多人使用，一定会存在竞争与协调的问题。

事情总有先来后到，也总有轻重缓急。这就像行车的红绿灯，讲究先来后到，可是警车与救护车也可以优先通行。

这样的协同工作，需要知道：当前这个工具，都有哪些人想要参与使用而正在排队？目前正在被谁使用？当前使用者的使用状态？占用是否结束了？是否有人提出了要优先使用，需要加塞儿？等等。

这样的信息在本质上是属于公共信息，而非私有。

也就是：因为自己要参与竞争使用公共资源，这是要获得一种权利。那么相应的，自己就要承担义务，也就是对外公开自己的使用信息。同时自己还要公平对待自己和别人的需求。

这也是通信作为公共IO资源，与普通IO的不同之处。普通IO都是固定独占的，没有竞争。

这是权利和义务之间的对等公平原则，也是法制的基础。这是每个人对其他人负责的方式。公平需要公示为基础。

那么这些公开信息，应该由谁来掌控呢？有两种方式。

1、如果公共资源的管理和分配是由某个管理者来掌控，那么这些信息就应该由这个管理者掌握，而每个参与竞争者并不知道。管理者之所以能合理调配资源，也是基于它掌握了这些公共信息。

2、如果每个参与的竞争者，都是能按照公平规则执行办事的主体，那么道理上讲，这些人不需要管理者，他们完全可以作为独立的自由主体，彼此按照规则协调。这种情况下，这些公开信息，就是应该由所有参与者都公平知晓。也就是行为规则体系和公共过程信息，都是公开透明的。

我采用的是这第二种策略：公示公开透明，自主协调。

落到程序中，就是所说的各个Modbus设备实例之间的平行调用。它们没有上级管理者，就是拖拽几个并行实例，连接好公共参数即可。

把这个公共数据区，连接到所有参与该端口竞争的设备实例的PortArray管脚。这样彼此间就可以共享信息和通知了。

而且因为是全局数据，它们可以被显示在HMI界面上，给现场做参考。

这个UDT内部包含了以下信息：每一个参与的设备实例，都有属于自己的一个记录区。因为有多个竞争者存在，所以这是个记录区的数组。每个记录区之内，显示了该设备的从站号、波特率、是否允许在线，是否被临时淘汰出通信等。

这个UDT还包含了：当前正在使用者的数组下标；提出需要优先使用的设备的数组下标。

这样的公共数据区，每个公共通信的IO通路，都需要且只需要一个。不管它是PLC直连的485串口，或者以太网的TCP管道，或是以太网的UDP连接。

因为这些物理方式的不同，只是底层IO，也就是通信指令，也就是前述的IO资源，它们内部解决的问题。并不影响顶层的设备之间，在功能层面的，调度机制。

上述这些表明了，每个设备内部都需要封装公共的行为规则。当然不排除，因为工艺的使用差别，每个设备对自己的规则做出调整。

不管当前的资源由谁在使用，使用者都会随时按照规则来判定，这个IO资源在当下是应该由自己使用，还是转让给下一个排队的或者需要优先使用的人。

这就是使用公共IO的代价。时刻不能忘记自己的义务，实时需要考虑别人的情况。

每一个参与者的情况都是在随时变动的。有可能随时就不符合使用条件失去资格了，或者它虽获得使用机会但是随时有可能自己就状态不佳了。

资源总是要高效运转，避免无效占据浪费。

总之，通过上面的叙述可以看出：这个公共数据区的存在，仅仅是因为多个设备要竞争性使用一个公共IO资源。多主体竞争，就需要通知和公示，就这么简单。

如果没有竞争关系，都是独占IO使用，那么本例中的FB就会退化为和普通任何种类的设备FB的结构设计，没有任何区别。