这是以前练习用自由口指令构建串口通信协议的时候做的。架构是完整的，但有两点问题说明如下。

1、这个最初就是自己实验用的。所以在对收到的信息进行解析的部分中，我只按照自己的习惯给自己惯用的数据类型做了解析。按照官方Modbus指令的接口标准，Variant接口应该可以是各种数据类型。各位可以根据各自需求在架构中添加解析元素，比较简单。

2、导入之后直接编译会报错。这个程序分为9个部分，错误在第九个部分中。那是为了调试通信的便利，引用的两个全局变量。你的程序中没有这两个变量，所以会报错。可以删除。但这两个变量的存在对于通信调试是有意义的，建议各位保留试一试。之所以没让他们走接口，是希望保持接口与官方的MB指令一致。

我在试验中的观测是通过单元机制来进行：每执行一次主从问答，通信程序会自动停止，这时候有充分时间观察和分析和调整数据。然后在监视表中再次触发，会再进行一次主从问答，然后再次自动停止。这样方便在示波器上捕捉和观察每回单次问答之间的报文差别。

那两个变量就是单轮控制开关。开关On的时候，通信就是单次执行，手动触发继续。关闭Off，就恢复连续轮询的正常执行。通信任务队列中的每一个任务，不论读写，你都可以单独控制本次轮询是否执行，这样便于观察特定功能码的不同读写任务的执行细节。

3、分享的目的是帮助初学的朋友，去了解完整的通信协议架构如何去搭建。如果理解了，这种架构不仅适用于串口，在以太网中一样的道理，比如通过UDP经过串口服务器透传来进行modbus通信。

用博途V14 SP1写的SCL

MB_Master_PtP.rar

我的程序调试绝大部分用Trace，所以程序中的一些细节是为此存在的。

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

有不明白的可以提出来，包括为什么要这样做，设计思想等。

开源的目的，modbus倒在其次，主要展示如何去搭建任何一种串口通信协议。通信指令和协议，照此码牌，都是死东西。

唯一有可能疑惑的地方，大概是处理循环多次接收多帧来合成一个报文的方式。

这是因为：此前运用官方Master指令的时候，超出一个长度限制会出错，有点奇怪。与北京西门子技术支持讨论过几次，也说不清。后来自己用示波器搭上485线路分析信号，发现了其中的原因。具体观察到的现象和原因分析，参见另一个帖子其中有详述。这件事导致自己写的这个指令。

1200自由口通信的报文和长报文的底层分析

西门子的官方指令也是人做的，照样有缺陷，不要膜拜德国人。用自由口做个Master指令也有这样一层意思。

Master卡死无反应是客观存在的，这和指令的内部设计有关。官方指令不开源，就不知道缺陷所在，也无法修改。直接断掉Master的En就可以了，只要出错，轮询就可以继续了。Block那个参数也没蛋用，还得靠健壮的全场景策略。

习惯用Trace来监控通信程序，这是最重要的。要有迭代演化手段，程序设计的现状并不重要，重要的是按照第一性原则一直往前走。

通信的东西要开放视野，任何技术都只是局部技术，和工程师要做的项目没有必然关系。串口和以太网的各种可能玩法，都要尽量去熟悉，不要遵循教条止步。

我开源的东西里面都有，可以借鉴。

我更倾向于用结构，也就是全局设计，来解决问题，而不是依赖局部的指令。

西门子的利益在于掌控未来的以太网的高端通信格局。串口的老东西，也不是自己掌控的标准，不会花代价去多搞，也就是给大家将就用罢了。

我用UDP来传递Modbus的那个开源，可以多研究一下。还有一篇关于自建UDP可靠协议的帖子。走以太网才是项目未来，串口也就那么回事。玩上位机/第三方，都是以太网。

我把通信当作IO来对待，也是这个原因。它们就是协议化的IO。工控本质上就是玩协议。

现在看OpenHarmony是非常有前途的。这东西设计的非常好，功能被原子化为很多小单元，在通信中高速流转。文档都在码云Gitee。

我分享一些源码的目的，主要是希望帮助大家搞懂内在原理，便于自己可以动手打造自己所需的任何功能，而不是习惯性依赖现成的。

可以看看下面这个源码，比较完整，更有帮助。

【开源】Modbus设备的单FB封装和多设备平行调用的通用架构 ------ 一个温控器案例的完整项目文件

另外这个

通过以太网UDP协议经串口服务器进行ModbusRTU通信的SCL源码