1026 【万泉河】优雅到极致的MODBUS库函数计划

在工控行业，无论使用哪一个品牌平台的PLC， MODBUS都是其中最重头的通讯协议。 而因为MODBUS通讯协议性质本身，实现通讯有一定的难度。 而且每做一个新项目，通讯程序都还要重新再调试一遍，所以比较头疼。 这是因为MODBUS的轮寻机制是必须在程序中编程实现。

比如一个COM端口， 一条485总线上面挂了N个MODBUS设备， 那么就需要做循环，对每个设备的每个数据区轮番做READ或者WRITE查询。而如果设备的类型不同， 还需要每个单独处理数据区和数据。

这一点在自动化项目时非常令人头疼。 所以，大家伙在入门之后，就不满足于仅仅能实现通讯功能了， 纷纷摸索实现模块化的方法，以期实现MODBUS通讯的优雅实现。

然而，最优雅的MODBUS通讯见过没？

最理想的优雅到极致的模块化的实现方式应该是：

比如485网络上有一台MODBUS通讯的DANFOSS变频器，那么只需要一个完全定制封装好的FB库函数：

拖到OB1程序来，管脚参数中标明这台变频器的MODBUS地址，然后就可以实现以通信方式的控制了。

当然不是指一定要直接在OB1中，而是指在OB1架构下，只需要这一个模块的一个调用。 除此之外所有类似于初始化，通讯握手等的指令，一概不需要做了。 因为全部在这一个模块内部实现了。

而如果有多个站，也只不过是再拖入调用多个实例。

而如果485总线上有多个类型的站点， 那么通过设计不同设备类型的FB， 也是同样拖入，即可实现通讯功能。

这是在面向对象架构，把设备全部都作为对象处理的情况下。 本人专著《PLC标准化编程原理与方法》中P149页开始的2个节有介绍过。

书中介绍的变频器是ABB，而本文中发的是DANFOSS。即，其实我们在后期随着工程应用的需要，已经把这2个品牌型号的变频器的通讯控制都做成了库函数。

而在非面向对象的架构下， 比如文章《0905 【万泉河】80模拟量例子程序升级版V2.0》中介绍的使用MODBUS通讯的远程IO， 则可以使用低一层的封装块：


其中数据区BUFF，指向了一个定义好的全局数据块：

这样数据块中的数组内的数值4X[1]就直接代表了此站点模块的40001通道的数值，就可以直接在程序中使用了。

注意看到上面的FB的管脚都有一个SUBNET， 含义是如果1个PLC系统内有多条485的总线，也是可以的。 比如需要通信的站点比较多，在一个总线上面轮询的周期太长， 数据刷新不够快的情况下，可以通过增加PTP模块或者MODBUS TCP转RTU网关的方式，增加到多条总线。

而在设备的参数部分，只需要输入总线编号和站地址，就可以区分了。

前面的介绍没有区分MODBUS RTU和TCP， 其实这两者都是需要轮询的。 即便是TCP，理论上讲可以使用多个端口同时通讯，但在实际操作中，PLC系统分配给TCP通讯的通讯资源是有限制的。 如果要同时通讯， 一个站点的读和写就要分别占用了2个端口，资源会快速耗尽。

而在MODBUS TCP的协议定义中，也仍然有站地址的标记，我们现在知道了，是为了TCP/RTU的网关设计的，即当使用网关把485总线转换为以太网之后，报文中仍然需要有站地址的区分， 以实现一整条485总线上的所有从站的数据，都可以有区分地被主站读取。

我们设计的SUBNET网络的定义，在100以下为RTU，而100以上为TCP，由此实现了通用兼容。

这些功能，在书中只是做了介绍，但并没有直接讲解实现的代码。 因为这些是属于底层的搭建库的需要，书中只是介绍方法，具体的设计工作仍然需要工程师各自实现。

甚至对烟台方法的学员，这部分的库和代码也并没有提供。 烟台方法提供的只是思想架构方法，并不提供程序代码，更不承担代码正确的责任。 这是烟台方法和市面上的制作库函数售卖或者分享的一些个人不同。因为做的是完全不同的事情。

甚至， 我也鼓励一些学员可以尝试使用各种各样的现成的库函数来做自己公司的标准化项目。那些库函数，在标准化烟台方法的眼里，都是基石，可以选择用来盖房子的砖头。 而烟台方法是帮助工程师搭建房子的顺序方法，每个公司各自的企业标准就是所谓的房子。

那么，这套MODBUS的库函数，本质上也是砖头。 是用来实现标准化的模块。当然是有相关功能需求的公司才需要，而没有用到MODBUS的公司则不需要。

这套库函数，我已经开发完成将近三年了。 而三年中，我们自己的项目在不断使用，并打磨，逐渐升级完善。 而对外，则只是一小段时间内做过小范围的出售。 大部分时间里则是雪藏的。并没有过多宣传，也没有推广。

最近，有学员和网友来咨询在西门子之外的PLC平台实现的方法，加上我自己正在编著《三菱PLC标准化编程烟台方法》的专著，对MODBUS部分库的欠缺，也有些焦虑。

所以，有计划把这套库函数再次拿出来，以低成本的方式分享给同行。

分享的目的主要是为了扩展。通过扩展，建立一个比较庞大齐全的生态社区。

扩展分两个维度。

首先是设备的类型，比如支持MODBUS的各种现场设备如变频器，仪表等等，都需要封装成专用的库函数。做好了之后需要的时候， 从目录中找到对应型号的库函数，直接拖入使用即可。

这部分的技术难度比较小。 比如从ABB变频器到DANFOSS变频器，只不过是各自的参数地址不同， 控制字和状态字的定义不同，制作时只需要照猫画虎，在原有的库函数基础上改一改，参数部分改好了， 经过实际应用检验通过了，就可以反馈加入到列表中，这样再有人需要的时候，就可以直接使用了。而不需要再去翻手册找参数，调试实验通讯。

另一个维度的扩展是不同的PLC品牌和型号，这部分的难度比较大。 我目前已经做了2个系列，分别是SIEMENS S7-1200/1500和S7-200 SMART。 而其它的品牌的PLC， 我虽然大都已经开发了标准化方法，但MODBUS通讯部分， 目前基本空白。 甚至，大部分品牌的基本的MODBUS 通信我都不会，因为没做过。

当然，主要还是我个人目前为止，这两个维度上的需求都没有。 而要扩展到那么多的自动化产品厂家，工作量也是巨大的。

所以，希望的是群策群力，大家一同贡献， 一同分享的模式。 所有有能力有兴趣的同行一起来做这件事，大家一起贡献，同时又可以都有回报。

这就需要一个比较完善的分享和贡献回馈机制，而不是简单一个免费分享能做到的。

具体的分享方法，会在近期整理推出，当然也不会一次性固化，先搞一个基本的架构做起来，以后再持续完善。

在此期间， 也欢迎同行给我私信提供宝贵建议。

我预期的是，将来实现MODBUS通讯的人工调试成本大幅度降低。 比如有人要做某个PLC与某个设备的MODBUS通讯，只需要来我们这里翻一翻库里的目录，选择好，拿去直接使用，一次性使用费用在几十元以内，如果有多个类型的设备，加起来也不过几百元。 比起个人抠抠搜搜搭台子做实验，要简便和高效地多。 尤其不需要个人独立面对通讯失败的糟糕局面了。 购买之后，有相应的开发者在后台辅助服务。

我在刚开始做这套库函数的开发的时候，写过文章《【万泉河】MODBUS并行通讯实现》
https://mp.weixin.qq.com/s/PZX-E3PKicYADcA_yzNlIg
然后就有看不懂的杠子手来杠我不懂常识， MODBUS跑的物理介质都是485总线是串行的， 并不能并行，指责我怎么可以并行通讯。

废话， 如果它天生支持并行，就没我什么事了。 恰恰因为他底层是串行，我们才可以通过自己的努力，在应用层面实现一个貌似的并行，哪怕是伪并行，也是我们能做到的贡献。

那么，我们以后就为这套库机制专门起个名字，就叫优雅MODBUS库好了。 翻译到英文，我称其为Grace Modbus Library ，简称GML。优雅库为优雅烟台方法服务，也可以为未使用烟台方法的同行服务。

有老外做过一个开源的REXHIP项目，我研究过也分享过。 但我对他的实现方法不满意。 认为比我现在做到的优雅程度还差许多。所以不赞成加入他们的开源贡献计划， 而是搞一套我们中国人自己的库。