首先请注意：这不是通常所说的Modbus通信模块。而是一个具体设备的FB，和它在触摸屏上的交互界面。 

Modbus是作为这个设备的IO被嵌入进FB。我追求的是：一个设备只需一个FB实例，通信只是它的IO管脚。

为什么要这样呢？因为作为买来的一个物理实体设备，485和Modbus是长在它身体里的。并不存在一个单独的可以拿在手里的实体物件叫Modbus模块，通信本来就是设备的内在功能的一项。而我喜欢抽象与现实的对称，也就是：现实中的一个可以拿在手里的完整东西，程序中就对应一个FB，这就是它的抽象孪生，除此没了。

我不想额外造出一个在现实中不存在单独对应体的抽象体。

解耦分隔在FB内部就可以了，正如现实中的一个完整设备，它的内部各个组件功能也可以相对独立一样。

设备FB内部采用的是分层解耦。

多个设备FB实例之间，是平行调用的，没有上级管理者。不管是同类设备，还是不同种类的，都可以。

开源的意义在于这个设计背后的思想。至于能理解和启发运用到什么程度，看代码吧。我在其它帖子中介绍过，其实是模仿了法治社会中的自由人的行为方式。

之所以说它是通用架构：如果你理解了，可以按照它的设计思想，很容易把它改写成任何种类Modbus设备，且可以灵活扩展和增减，适应多变且复杂的任何场景需求。这是个面向开放的设计。

其实并不局限于Modbus。任何多个实体之间，存在竞争性协调使用稀缺公共资源的场景下，都可以采用这个架构中的调度和解耦思想。这才是它的真正本意。

我以前分享过用自由口PtP做的MB-Master指令，还有可以运行在UDP上的MB-Master指令，它们可以被嵌入这个框架。

可以体验：一个设备FB，同时具备通过PLC本体485串口，和通过以太网UDP走串口服务器，可以在不同通道间，从HMI界面自由切换，来运转Modbus的效果。

项目是用博图V14Sp1的做的（PLC部分全部是SCL），体积大约40兆，归档后也有2.6兆，只好用网盘分享了，链接是永久的。

链接：

https://pan.baidu.com/s/1BrLdX9dee_lPJErdFWTbmA?pwd=qixe

提取码：qixe

项目硬件：1214C + CB1241 + TP1200 + 5个West品牌的温控器

温控器型号：在HMI首页上可以看到。这个英国品牌现在国产也不贵。如果按照首页上的型号买两个，可以连上PLC实机体验效果，能帮助理解架构设计。

PLC与HMI之间采用的是：读写分离的、接口式的、上下位交互设计。

这个项目中的UDT没用放进库。HMI上没有用面板，用了多路复用。

---------------------------------------------------------------------

退一步，用结构解决问题。不欢喜于局部算法。

用结构把复杂场景分解成简单元素。共性是一种结构，可以为元素进行分类。

把生活投射进结构设计，表里对称。

谢谢大佬分享

先下载了，过后拜读。

下载来看看，感谢分享

感谢分享~下载学习一下，希望能够理解你的思路

已下载，正学习。

感谢分享。。

感谢分享。下载来学习。

通讯大佬又有开源作品了

已下载学习，感谢老哥分享

非常感谢分享

这个开源项目，是我从刚做的几台设备中，特地为了开源的清晰完整和便于理解，单独剥离出来的。设备过几天就要海运发美国了，正在订集装箱，从上海发货。

在出口设备中，这一模块我是用Know-how加密的，不分享给老外。只无偿送给国人。

从xiatianyun的疑问帖子看，估计很多人在最初是不太能理解这个项目的设计思想，会遇到很多障碍。应该是设计路数的差异带来的。

这个项目的结构是适合调试的，用Trace调试，验证，扩展和剪裁。

实际上它就是用Trace迭代出来的。我最初的时候，并没有想要刻意设计这个东西，是随着迭代，逐渐就出现了。

开源的一个重要原因是：我很清楚的明白，虽然是自己弄出了这个东西，但把它攥在我手里并无太大用处，荒废了它的潜力，因为我只是个做单机小项目的非常低端的从业人。放在诸位手里，也许能演化出别的花样，如此便好。

----------------------------------------------------------------------------------

另外，笔记本内存大点还是便利。下图是挂了一个博图V14虚拟机的性能截图。我把虚拟机设置为6核（2*3）与内存32G，实际用不了那么多。

再开一个Eplan虚拟机

就成了下面这样

可以想象继续加大虚拟机的样子。

我喜欢一边设计干活的时候，一边上网听音乐或者追无脑剧，眼神还不太好。所以还矫情需要2个外置大扩展屏。最初Unix诞生的时候，那哥俩就是想要一边干活儿一边玩游戏，才搞出了多任务。由此可见，人只有三心二意，不务正业，会跑偏，会玩儿，才能领会调度的本质和妙处。

如果没有详细的说明是不能正确理解的，程序里面的“ModbusChannel" 似乎和通讯通道有点不同，更像是虚拟的软件通道，楼主能不能给我点提示？

是虚拟的调度通道。

它的作用是给出一个公示区域（Modbus.CB1241）中的数组下标。

该下标会表明：当前占用485通道的从站设备的相关信息。

你可以同时仔细读下面这个帖子，它就是再说这个FB的设计理念。可以先读它或对照着读

Modbus设备FB接口设计背后的理念

仔细看那些UDT的构造关系。

整体设备与Modbus

多数人谈及Modbus，习惯把它作为一个单独的模块。回避了设备整体层面的，灵活多变的外在工艺，所导致的与Modbus衔接的，复杂场景的，整体性问题。而当设备的功能，越来越向复杂化演进，这个短板就愈发突出。

Modbus本身，作为协议化的IO，事实上是个死东西，执行固化。不只是Modbus，事实上所有的通信执行本身，都是死东西，因为你只能按照协议去执行基本指令。

而设备的边界功能，经过调度的转化，与公共通信IO的多变的衔接方式，越发成为编程的挑战。真正富于变化的，是因项目需求多变，导致的功能多变。

当功能场景和调度体系的需求，变得越来越复杂的情况下，就会体会到：Modbus本身，在设备整体之中，变得越来越边缘化，独立性越来越弱。这导致高内聚成为自然的趋势，而一个设备的整体封装，就顺其自然的合理化了。

在这整体封装内部，并不是把一切混成一团浆糊，随意摆放。而是尽量把其内部元素化，保持稳定的低耦合多层结构。以此来保证易于维护，易于调试，易于扩展和收缩的增减改造。保证程序员在框架下的演化移植，不易出错和思路清晰高效。

本项目以某品牌温控器做一个完整的实例，向大家展示：站在一个完整设备FB的高度，在复杂且持续功能演变的前景下，如何通过一个通用普适的架构设计，把表层功能转化为底层的协议化且存在公共竞争的IO。重点在于分层解耦的调度结构，而不再是Modbus的执行。

这是一个面向设备的完整方案。

绝大多数人都能够读懂表面的代码，都能够大致理解这个案例，会得到一个大体的印象。但同时，又会觉得隐含着一些说不清道不明的东西。

这是诸位需要注意的地方，要把全部的细节一同，从多种角度去联系和扩展，才能更好理解它的设计。

学习了，感谢分享

学习一下，感谢楼主

学习一下，感谢楼主

基础指令是死板的，只能做简单、固定、有限的任务，且有很多的约束条件限制。

因此若想要让基础指令，在现实案例中发挥最大的效用，其根本做法就是：程序员要把复杂多变的功能需求，分解为简单固定单一的原子化元素。让指令在场景元素中，扬长避短，发挥效率。

这个过程就是调度，手法就是解耦和分层。而且为了长远的编程效率，解耦的角度本身要和眼前的案例解耦，也就是使其成为长远稳定，可以应万变的框架。

这样经过封装得到的设备整体模块，才是好用的、皮实抗造的、自带诊断修复和调试机制的、可扩展剪裁的、等等。

也就是说，用基础指令算法直接去构造功能，从长远看，未必是好的选择。

比如，有人喜欢在循环指令内部，实现比较多一点的功能。但在我看来，循环操作，不管它转了多少圈，本质上只是一个计算步骤。这就和我写了一个简单语句，没有太大区别。所以，我只用循环指令，做简单的一件事。

记得之前有人写过，如何在循环内部去调试。在我看来，这在退一步大视野的设备整体框架的设计中，是糟糕的选择。

用整体结构去解决问题，而不是直接寄托于局部算法。解决得到的结果，只是框架在本案例凸显出来的一个实例。

宝冬大侠：今天有空看了会，我看ModbusChannel的UDT有个激活波特率的数据，请问是说每个设备都可以有自己的波特率吗？或者说可以让不同波特率的设备挂载在总线上，每和一台设备通讯都根据激活波特率来初始化通讯端口？

还有，通道里面的DeviceQTY是什么意思？

1、今天有空看了会，我看ModbusChannel的UDT有个激活波特率的数据，请问是说每个设备都可以有自己的波特率吗？或者说可以让不同波特率的设备挂载在总线上，每和一台设备通讯都根据激活波特率来初始化通讯端口？

是这样的。每个设备自己单独初始化，这代表它选择如何运用485端口，它有自己的波特率。

每个设备都是自己裁定是否上线通信，是否被淘汰，这是它自己的事情，与其它设备没有关系，所以它可以按照自己的波特率去使用端口。因为对这个设备FB而言，端口就是底层的IO资源，想怎么用就怎么用，与其它设备无关。

这个FB是面向设备封装的，而波特率作为该设备功能全集中的Modbus子集的重要元素，当然是属于设备对象的私有重要属性。这就是面向对象的思想。

再有，这个FB的架构不是为了只能连接在一个固定485端口上设计的。可以根据现场的电路接法，直接在屏幕上根据实际情况，更改或自动匹配波特率。

有一种设计是：485端口也都参数化，在屏幕上为每个设备单独设定。

比如：你在写程序的时候，不确定到底哪些设备，是连到CB1241或哪个CM1241或哪个串口服务器的哪个串口（一个串口服务器有多个串口）。一切都等到了现场再说，根据实际情况从屏幕配置参数。

再比如：你给一个Modbus设备写FB，不止针对眼前案例的PLC本体485模块，也考虑到未来的以太网途径，想一并解决，而不是到时候再为同一个设备写另一种FB。因为没有规定，一个串口modbus设备只能接在PLC本体485模块上，而不是串口服务器的更多485口。

2、通道里面的DeviceQTY是什么意思？

QTY是quantity的缩写。DeviceQuantity，每个通道的设备数量。

每个通道的设备数量只有是1的时候才是正确的，是0或者多个都不对。

在这个案例中，通道是自动分配的。也就是说：各个设备的默认轮询次序被固定了。

其实是可以开放的，由操作者在屏幕上，为每个设备分配通道。这个变量可以用于避免用户的胡乱分配。

手动分配通道，意味着可以在现场改变设备的轮询次序。这对于消除因线路内在缺陷而产生的485网络噪声干扰有妙用（打破噪声干扰的相位条件）。也就是说：先轮询设备A再轮询B，和先B后A，对于线路中噪声共振的影响是不同的。

给定线路上的电磁信号的不同演奏法，就像是不同乐章的乐谱，效果不同。

如果不同波特率的设备接在同一条Modbus总线上，访问任意设备都需要重新设置端口参数然后才能访问某一台设备，端口重新配置会不会消耗时间呢？其他波特率的设备会不会做出错误的相应呢？

哦，我似乎明白为什么波特率是9600、19200之类，而不是跨度较小的波特率了。

如果说轮询次序是为了改变噪声共振干扰，也就意味着需要固定的次序，那么一旦任务被召回是否意味着这种次序被打破呢？

还有，Modbus设备是否存在一个公共的功能来响应主站的访问，比如查询该站是否存在的功能。Modbus有查询设备厂家内部识别码的功能，但好像并非强制的。

1、端口重新配置会不会消耗时间呢？

同步指令，不会。

2、其他波特率的设备会不会做出错误的相应呢？

不会，除非485电气老化会有少量错误。所以可调波特率才显得必要，就是有柔性，适应性，可以调整可以改，不是固定必须如何。现场柔性。

3、如果说轮询次序是为了改变噪声共振干扰，也就意味着需要固定的次序，那么一旦任务被召回是否意味着这种次序被打破呢？

理解的不太对。规律性的是读任务，是主要考虑的。偶发不构成固定次序。次序要看现场的表现，所以需要能够随意更改适配。

4、Modbus设备是否存在一个公共的功能来响应主站的访问，比如查询该站是否存在的功能。Modbus有查询设备厂家内部识别码的功能，但好像并非强制的。

没仔细研究过。这要看具体设备是否支持，还有使用的master指令是否支持。其实意义不大，联系不上支持也没用，联系上了不支持也无所谓。

你还是习惯性的、太过、固定化的、在意底层通信本身。好的全场景覆盖顶层设计，不管底层是什么样都可以调整支持，这才是这个架构的意义。柔性，一切皆有可能。

等你真正理解这个架构，就会明白它在本质上并不是关于通信或modbus，是不是modbus不重要。本项目只是在modbus上的一个应用例子。别把眼前的实例当成架构本身，虽然它是架构的一个表现。要扩展的、开放的、退一步尽收眼底的去理解。

刚才实验了下，端口重新配置并非同步指令，从开始启动配置到配置返回done大约16个循环周期。

实验见真知，我实验的结果是需要多个周期才配置完成。

我估计你实验的配置数据并没有变化，所以端口配置并不需要重新开始。

本案例的运行Trace，刚跑的。

波特率不同，每次都得重新初始化。

Trace我刚用，不过我看到虽然配置有每周期采样的设置，不过X坐标图上似乎是ms，每一格代表一个周期怎么弄的？

16周期是我刚才的数据，不一定，但可以肯定是需要一定时间才能完成。

扫描周期标识 ：= not 扫描周期标识；

你可以继使用你自己的初始化方式，不用和我一样。

我Trace一下高版本的commload速度，确实慢。

在设备实例外部，上电对端口初始化一次即可。

在设备实例内部，端口初始化跳过去，除非自动匹配波特率。加个判断。

因为我从来不用分布式的485模块，只用PLC主体的本地485模块（本项目是CB1241）。所以没必要使用高版本IO，太慢，还臃肿。就用低版本MB指令，速度快，我记得比高版本好像是总共大概少7K的工作内存占用。它这个commload就是同步的。

如果有其它案例需求，我直接就用UDP跑Modbus了，不用西门子模块。一个串口服务器才几十块钱。

这就是框架的便利，适配和修改是解耦的。如果这个案例包含了使用以太网通道的选项，也是在端口初始化环节中添加一些元素即可。

所以还是要读懂框架，它可以匹配各种场景和方案，这就是开放性。之前的端口讨论都只是IO底层中的某些细节。

我设计这个框架就是为开放性准备的。

所以，为什么在项目中，我把这些底层的东西都称为公共IO资源。这个框架就是立足解耦的调度结构，具体IO手段是次要的。

太难了，太高深了

搞个视频讲课指导一下

作为一个指令，单独看新版MB指令，优化空间等，似乎有优势。但是站在现实的设备完整解决方案的范围和高度来看，基础指令本身的好处就未必了。说到底是整体设计，决定最后的设备表现。

这就和有了一个新玩具，新的组件零件，一样道理。它的一些特点，优势和短板，能否发挥到什么程度，要看系统集成的能力，各种制约和细节的代价优劣取舍。对于F35飞机，美国空军不打算采用新开发的变循环发动机来升级，也是类似道理。

感谢楼主分享，学习一下

本来没想买就是瞎转，结果手痒痒。

-----------------------------------------------------

这物流速度够快，顺丰包邮明天就能送来。

闹了半天，他是从我所在地直接调的货源。现在PLC这么不好卖吗，感觉供大于求，很多工厂说今年生意不太好，难道是需求低了。以前买货，也经历过卖家从各地调货拼货源，似乎各地商家之间有某种协作。

-----------------------------------------------------

早上八点半就送来了，从下单到收货16小时。

查记录上一次自己在淘宝买1214是2022年9月25日。这次的价格，比那时候便宜了有500多。这个变化还是反映了一些市场信息。前两年那价格高的离谱。

前两天询价TP1200，才8700元，比上次便宜有1500多。这价格比美国那边便宜好几倍，顺丰空运三天就可以在美国登门送货。现在用顺丰的微信小程序下单，登门取货，非常快速方便。

家里现在有3个1214了，迭代通信框架很方便。

西门子还是暴利，这么一个塑料小盒子，能买一堆谷饲牛排。

我怎么看不到你的项目文件

感谢分享，慢慢消化

先收藏为敬，感谢分享

如何把我先前开源的MB-Master-UDP指令嵌入本案例的项目中，让设备走串口服务器？

看很多朋友用串口服务器的时候，还在用ModbusTCP，太笨重且毫无意义。

一个MB-Client实例占用20K工作内存，无语了。

下面简单说一下UDP怎么用。串口服务器的设置不说了，很简单。

走UDP，不需要像本体485口那样，需要组态。就两件事

1、建立和维护好UDP连接

2、引入协议执行的基本指令（也就是MB-Master-UDP指令的实例），这个指令实例在设备之外的loader中拖拽一个即可。

具体过形成如下

1、在本案例的设备FB的接口中，增加几个参数如下。

这几个参数的类型如下

UDP的连接，要自己单独预备和管理。具体的在Modbus-UDP那个帖子中讲了，有源码，不唠叨了。

说是连接，其实它就是个线程，程序员做的就是用参数设定它。UDP的是无连接通信的，它的线程要简单和轻灵得多。就是个同步指令。

一般串口服务器有多个串口，IP地址相同，每个串口对应的端口号不同。每个设备的端口号，你自己知道到底连了那个设备，赋值一下就行。

2、通信初始化环节，加个当前通道模式判断，或者啥也不做都可以。

3、通信执行环节，加个当前通道模式判断，类似如下

论坛附加图片的像素规定，真是越来越垃圾了。

关于UDP连接，参考下面图片。就是大概意思吧，没细弄，其中还有重复的。

异步与竞争协同

一个设备FB的内部结构，总体上分为功能和IO（本案例中指通信）两部分。

功能部分是指：设备的界面功能，通过调度层，和与通信部分衔接的每一个单个任务之间的，双向过程。

通信部分是指：在单个任务，通过通信层，与底层硬件IO之间的，双向过程。

异步，一个任务需要几个扫描周期才能完成。任务在一个周期启动，在另一个周期结束。

对于走485通道的Modbus通信，在任务执行期间，除了通信部分的执行层，所有其它的通信层，都只能观望，什么都做不了。其它所有参与485竞争的设备FB也一样，所有的通信层都在观望。

但是所有设备的功能部分并未停止。它们一直在于外界交互，每个周期都实时在变化，在为下一个任务做动态准备和随时争夺485通道。

观望是指：即观望自己，也观望别人，而且每个周期都要观望。因为随时在任何一个周期，通信执行层可能会结束，马上就要面临下一个任务的分配。

而所有设备的功能部分，原本都一直在运转。它们都可能已经把各自的下一个任务准备好了，并且比你自己的下一个任务的优先级更高。

在这种密集的竞争过程中，如果你自己的通信执行层反馈回来了执行质量问题，那你可能就没有机会加入下一个任务的485争夺了。

Modbus通道（ModbusChannel）到底是什么？

通道：站在调度必须条件和调度共性的角度，对多个具体的被调度设备的抽象。

一个具体的设备，只是通道的一个被调度实例。这有点像接口，参数实例。

多数编程，都会把Modbus设备的从站号写为常量，波特率写为常量。这样的设备就是一个具体的设备。

针对这样具体设备的直接调度，不具通用性，无法成为通用的调度结构。

各种各样的Modbus设备的具体通信配置，它们的共性就是：它们都有自己的从站号，自己的波特率、自己的校验等。

为什么会这样呢？因为Modbus协议，就是嵌入在串口通信协议的报文中来传输的。这也就是，当你用示波器观察485线路的电压波形，所看到的报文信息，正如下图所示。

对于通信物理通道的竞争性调度，不在于当前正在被调度的这个具体设备，它的从站号和波特率的具体数值到底是多少。

调度规则，唯一在乎的，是眼前设备的这两个参数是否合法，这就足够了。

ProcessRole（工艺角色）

一模一样的设备，它们各自在现实项目过程中，做的事情不同，有各自的分工，这就是工艺角色，ProcessRole。

工艺角色与从站号无关。这都要根据现场设定，而不是作为常量预设在代码中。

工艺角色，决定了每个设备的调度体系中的工艺调度层的做法。

谢谢楼主分享，学习一下 ！

感谢楼主分享经验。

感谢楼主分享!

谢谢分享，学习一下

感谢分享项目!

谢谢分享!