这样的场景，用前面提到的调度结构理念，优先权抢断广播(写0站)，肯定可以。

不管从站挂接有多少，优先执行都是非常快的，仅受限于扫描周期的长短。

但UDP会更好，毕竟MB慢，易干扰。MB根本上不适合要求非常快的场景。

我理解的通信设计，还是要首先从案例需求的根本出发，扩大考量范围。不首先限定于串口还是以太网的某种技术手段。这也就是ElonMask嘴里说的第一性原则。

特别高速的通信需求，PLC就已经有些不适合了。因为一般的PLC编程无法运用多线程，反正我是没见过，CPU资源利用率低。扫描周期的存在，就是个固定的单线程，这是瓶颈。

当然，PLC本身就像面向易用的编程产品，底层的深挖掘和细化定制能力肯定锁死或受限，这是平台的天生局限。

高速通信要求，程序员必须能驾驭每个独立的静态线程，和上位机开发中的策略一样。针对多个设备节点的多个独立静态通信线程，常驻内存，实时的，在平行监听和运转。那个反应速度，PLC根本比不了。我在上位机实测过，TCP传输就比S7快50倍速度。UDP没测过，但肯定更快。

现在上位机开发，目前最好的还是.Net平台。鸿蒙的仓颉语言一直没出来，用TypeScript，但是其生态已经有2000多家支持。且已经有了十几二十款开发板了，主流SoC都逐渐开始支持。但这个如果不是专业弄，根本干不了，也没这精力和资源。

鸿蒙的软总线，是在操作系统的最底层，解决掉设备自动发现和自动互联的问题。煤矿应用中，30%丢包率的场景下，能做到端到端10ms传输，其中主要就是UDP。软总线把7层模型的底下四层给精简合并了。

我个人非常看好鸿蒙OpenHarmony的潜力，它具备颠覆性的工业潜力。目前我知道的国内PLC厂家，只有汇川在2021年加入支持研发，但不知道他们具体会干啥。

前不久，华为发布了一个硬实时操作系统(RTOS)的内核UniProton。它不采用时间片，完全是按照优先级调度，有三种不同的调度速度快慢的选项。目前它可以同时驾驭多个ARM架构的芯片。实时的面向底层，非实时的面向UI。这就是给未来预备的。

闲扯一堆没用了。