回复：用自由口通信制作的ModbusRTU协议的Master指令的SCL源码-技术论坛-工业支持中心-西门子中国

回复：用自由口通信制作的ModbusRTU协议的Master指令的SCL源码

宝冬

帖子

197
精华

26
被关注

248

论坛等级：奇侠

注册时间：2016-07-06

黄金如何晋级?

发布于 2023-04-02 17:22:31

63楼

展开查看

以下是引用hubo在2023-04-02 15:34:56的发言 >61楼：

宝冬大侠，以前自己也用S7-1200PLC做modbusRTU轮询和自由口通讯，但一直有一些问题没弄清楚，请教一下。先不说是基于哪种形式或理念的轮询方式，单就只针对西门子的指令库中的modbus_master指令，如果根据西门子对该指令的帮助文件说明，在modbus_master指令一直调用的情况下，用本次通讯任务的Done或Error脉冲去触发下一个通讯任务，不论在什么故障情况下都应该有error位的产生，通讯不会卡在那里，但实际上由出现的卡死现象，不知道是什么原因？对于一个通讯报文，既有在CM1241中设置的“报文开始条件”（默认是以任意字符）又有”完成接收条件“（默认是通过消息超时识别200ms），还有Comm_Load的从站超时检测和重发次数等手段，那么最多就是从站掉站或者因为干扰导致接收报文错误，总应该有个故障信号吧。modBus RTU通讯并不抽象，测试时用示波器测量，发送的请求报文时间、从站响应报文时间、接收报文的时间都能测量出来，但就是找不到卡死的原因，不得不人为加一个超时检测，当然超时检测的时间到大于重发报文的总时间。另一个问题是关于modbus_master指令的Blocked_Proc_Timeout 参数，在测试的时候各种操作，例如向一个从站一直发报文，然后断开该modbus_master的EN端，又立即向下一个从站发报文等等，反正是没试出Blocked_Proc_Timeout 参数的效果，倒是16#8200出现几次，16#80C9这个故障一直没试出来。谢谢

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

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

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

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

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

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

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

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

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

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

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

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