引用8楼详细内容：

通信总是异步的。异步就是指CPU线程(thread)的同时平行执行。

这可以理解为：在同一个瞬间，有好几个OB1在同时平行的执行。我看倍福的PLC中就允许程序员自己主动控制4个线程。

所以本质上，这不是通信的问题，而是多线程之间的数据互操作问题，只不过线程的内容是通信，人们就说这是通信问题。其实通信的本质，就是指线程之间的数据交换。数据交换的本质就是协议。IT的尽头就是设计协议，协议的尽头是设计标准和形成生态。

所以一定是要接口式隔离，彼此的数据区和上下文都要分开。所有的操作系统内核中也是这样的设计，尽管宏内核和微内核在做法上有不同。

我的这个设计是为了(1)程序设计解耦，(2)满足任意数量的外部多节点写入的需求。

在程序员的职业生涯中，各种项目差异、需求和设计总是不断变化和复杂的，不可能让异步机制来束缚程序员的结构设计。所以要隔离，低耦合的一种运用。

PLC程序设计是面向变化和扩展的，不能假设在未来只和特定节点通信。多个HMI，多个外部任意品牌第三方的PLC、云节点、上位机等等，都有可能。

所以与外部节点交互的数据，要放在特定的DB中作为固定接口区，且必须是标准兼容存储格式，不能是优化的。

以.Net上位机为例，面对例如几万个bytes的PLC数据，实用的上位机通信设计，都是采取成片成片的连续读取和覆盖。

尽管上位机操作者在UI上感觉只是写了一个数字，在位于上位机架构中底部的通信层的读写操作，都是实时优化组合成连续大片进行的。

而且PLC几万个变量，上位机要如何知道每个变量，要通过自动生成xml配置文件，上位机自动载入和解析，并自动据此生成通信层中的多个静态线程的平行运转，否则程序员自己输入要累死。通常上位机要和多个PLC节点同时进行通信。

提到几万个字节的通信，就会涉及到S7的缺点。

现在的上位机S7通信，都是采用开源库。也可以自己学习去写，虽然麻烦些，但所有协议的解析，就跟打麻将码牌差不多，最终都是体力活。这样做的好处就是，可以自己去扩展写出所有品牌PLC和第三方节点的通信库。

S7虽然不开源，但是人们摸索出的几种常见读写基本操作，都已经成熟可靠了。实践中运用最多的，还是经过优化组合的连续读写操作，便于框架设计和兼容场景更广。

但S7协议，是嵌入在TCP中的OSI应用层协议，打包和拆包的代价很高。比TCP慢了很多。

我在自己做的.Net上位机中测试，几万个字节的话，即便是在优化组合的尽量缩短时间的设计下，大数据量读写，S7比TCP慢50倍。

这对于满足上位机的实时性需求差很多，而且要考虑到上位机架构中业务层的数据库吞吐，包括PLC变量的报警等等操作。而且同样的信息交换，S7需要产生更多的TCP包流量，面对干扰的以太网环境和现实带宽，这都是弊端。如果自己设计UDP可靠传输协议，就比TCP还更好。