这是以前练习用自由口指令构建串口通信协议的时候做的。架构是完整的,但有两点问题说明如下。
1、这个最初就是自己实验用的。所以在对收到的信息进行解析的部分中,我只按照自己的习惯给自己惯用的数据类型做了解析。按照官方Modbus指令的接口标准,Variant接口应该可以是各种数据类型。各位可以根据各自需求在架构中添加解析元素,比较简单。
2、导入之后直接编译会报错。这个程序分为9个部分,错误在第九个部分中。那是为了调试通信的便利,引用的两个全局变量。你的程序中没有这两个变量,所以会报错。可以删除。但这两个变量的存在对于通信调试是有意义的,建议各位保留试一试。之所以没让他们走接口,是希望保持接口与官方的MB指令一致。
我在试验中的观测是通过单元机制来进行:每执行一次主从问答,通信程序会自动停止,这时候有充分时间观察和分析和调整数据。然后在监视表中再次触发,会再进行一次主从问答,然后再次自动停止。这样方便在示波器上捕捉和观察每回单次问答之间的报文差别。
那两个变量就是单轮控制开关。开关On的时候,通信就是单次执行,手动触发继续。关闭Off,就恢复连续轮询的正常执行。通信任务队列中的每一个任务,不论读写,你都可以单独控制本次轮询是否执行,这样便于观察特定功能码的不同读写任务的执行细节。
3、分享的目的是帮助初学的朋友,去了解完整的通信协议架构如何去搭建。如果理解了,这种架构不仅适用于串口,在以太网中一样的道理,比如通过UDP经过串口服务器透传来进行modbus通信。
用博途V14 SP1写的SCL
MB_Master_PtP.rar
我的程序调试绝大部分用Trace,所以程序中的一些细节是为此存在的。
------------------------------------------------------------------------------------------------------
有不明白的可以提出来,包括为什么要这样做,设计思想等。
开源的目的,modbus倒在其次,主要展示如何去搭建任何一种串口通信协议。通信指令和协议,照此码牌,都是死东西。
唯一有可能疑惑的地方,大概是处理循环多次接收多帧来合成一个报文的方式。
这是因为:此前运用官方Master指令的时候,超出一个长度限制会出错,有点奇怪。与北京西门子技术支持讨论过几次,也说不清。后来自己用示波器搭上485线路分析信号,发现了其中的原因。具体观察到的现象和原因分析,参见另一个帖子其中有详述。这件事导致自己写的这个指令。
1200自由口通信的报文和长报文的底层分析