关于S7-200 modbus rtu通讯报警6#（续）

关于S7-200 modbus rtu通讯报警6#（续）

   在看这篇短文前，请先不要先看括号内红色的文字，这些文字是我写这篇贴子后，按实际真实的验证过程后添加上去的，可以看到查找这个问题时的全过程，自以为别有一番过程，你不妨试试。

   昨天，对于modbus rtu错误报警6的探讨，发帖后我总感觉尚不够理解深刻。虽然由于200（200 smart）库指令的加密，一时无法进一步领悟到其中关联指令的具体内核，故分析起来会可能有一些不足之处。上篇贴子我的判断是modbus rtu初始化指令执行完毕后，Done位（SM0.0的set值）为1后，使MSG指令的First管脚接收到2次脉冲，使MSG错误报警为6。下班回家后想到了一个方法，可以这样来检验是否有真正的2次脉冲可能，于是，再次在原程序的基础上增加检测M0.0是否存在脉冲的程序段，图示：用VB10检测M0.0的脉冲个数。

1）  网络段1，初始化将VB10 = 0（清零）

2）  网络段3，进行对M0.0的脉冲计数

将修改后的程序下载、监控程序，发现M0.0并没有出现我理解中的产生脉冲2次个数，我理解2次脉冲是基于MSG指令错误报警6（modbus正忙于另一个请求，同一个时刻只能激活一个mbus_msg指令）为基础的。居然VB10 = 0，这时First管脚压根没有得到监控状态中的使能位值1，但从状态图表上监控M0.0 = 1了的（糊涂开始中）。

   继续，在First管脚处增加一个M0.2及上升沿，人为加入使能位，看监控状态，这时人为的使能msg指令First管脚，msg指令是一定建立了正常的工作机制下的，图示：

  监控结果，确实如我上面理解的M0.0压根没有给First管脚使能，这个从我外置的VB10 = 0中也可以理解了的。人为加入M0.2 = 1，则MSG指令的error = 3。由此，说明这个error错误报警值仅仅只是一个假象而已（开始清醒了）。干脆，彻底断开First管脚使能，再看结果，图示：

  在First管脚处加入M0.3（NO）触点，看MSG指令的error仍然“错误”报警6，看来M0.0没有使能First管脚的想法是成立的（反复徘徊在清醒中）。

  回想起官方在给出mbus_crtl指令变量表中说明，Done的工作机制是SM0.0的set值，可以理解，当mbus_crtl指令完成后，Done位输出1的状态时，mbus_msg指令尚未完全建立工作机制，故而使First管脚使能1的值失效，也就是说，First管脚没有真正意义上在mbus_msg建立工作机制后被使能为1，但是，这个想法马上又被自己否决掉了，毕竟程序的工作机制一定是遵循原则的，而我上一篇贴子的判断显然不够理解深刻，如果产生了一些有误导的嫌疑，请谅解了我对此认识上的欠缺。

   那是什么原因，让VB10得不到应该有的上升沿脉冲？我模拟官方的Done位说明重新创建一个简单的验证程序（又回到了糊涂中），图示：

VB10的值仍然为0，也就是说网络段1置位M0.0 = 1后，在网络段2的M0.0仍然没有得到一个由网络段1置位的脉冲。但从监控状态看M0.0已经是1，但VB10并没有为1、、、、、、（自此，终于找到真正的原因，狂喜中）。

   哈哈哈，功夫不负有心人啊，没有给First管脚使能上升沿脉冲的真正原因终于找到了。

原因分析：

  当mbus_crtl的Done位完成初始化操作后，在同一个扫描周期内（关键是第一次扫描开始时）已经M0.0已经为1了，那么这个上升沿让它这么会产生呢。回到基本话题，产生上升沿脉冲必须是位值由状态0变化为1的过程，没有这个过程上升沿是不可能产生的。因此，当msg指令EN管脚使能后，First管脚并没有得到一个有效的沿脉冲。

小结：

  网友提问modbus rtu通讯问题，msg指令上电后错误报警6的根本原因是First管脚没有得到应有的使能位，即M0.0根本没有得到位值的跳变。而我错误的判断M0.0 = 1，First管脚就会得到一个沿脉冲，至于说是2个脉冲是基于错误报警6的判断，实际上，msg指令在First管脚没有得到使能时，也是错误报警6（前面已经有图示说明），造成我的假象判断。所以说，编程过程对于一些假象的判断，容易进入一些误区，仅以此贴子给那些尚未理解这个问题的网友一个参考，以加深理解modbus rtu，不，准确的说是最基本编程技能的理解上的提升，对上升沿指令的理解，在此感谢1楼“S”侠的回贴，正因为我看到你的回帖反问，才使我进一步验证、查找这个原因。

还没用到过哈哈，先收藏了

王工，对这个枯燥的问题不弄个水落石出是誓不罢休啊，乐此不彼啊，点赞学习了。

看你了的上篇《关于S7-200 modbus rtu通讯报警6#》，追到这里来，学习了，大赞

黄工好！

   典型的强迫症患者，

持续关注中！

从11楼转过来，楼主的精神值得佩服！

至于没有触发First管脚，而error输出6的原因是：EN管脚的使能位采用了SM0.0，这个在实际应用中并不合理，官方也没有用这样的特殊标志位，这个是我验证时的另一个误区。

这是最基本的职业操守呀，总不至于误导别人。尽自己最大的可能把问题描述清楚是必须的。

那边帖10楼我都提出了这个疑问了。明明M没有产生边缘，也就没有触发，怎么会6？肯定是假报警。

大家应该知道sm0.0是没有上升缘产生的。而这个done性质基本等于en端。如果en端由0.0带动，那么这个done位也无法产生上升缘。

1）产生脉冲我错误的判断是看到是M0.0 = 1，以为可以产生脉冲。实际上，原因上面验证中已经说明了，你在10楼也说明了。

2）产生错误报警6，是我不合理的在msg指令的EN端采用的SM0.0。至于为什么是6，而不是其它报警值，这个应该是msg内部程序的原因，因为该子程序加密，无法真实判断问题的所在，只能在此妄加猜测了。

是的。我们只能用，没权去理解了。

那么msg的en端就用sm0.1的常闭点去接，就可以在第二个周期中马上工作。

msg指令的en端，我认为最好不要使用特殊标志位，那样可以避免一些“人为”的错误判断。

2016年时，网友发给我一个modbus master的源程序，是S7-200写成的，有想研究的，留下联系方式。

求分享，谢谢1259233699@qq.com

还是没有把modbus rtu错误报警6的根源说清楚，已经验证了一些程序执行情况，重新整理后再发帖。

MSG的Error=6的2种情况：

1 上个MSG没执行完，下一个MSG开始执行

2 在执行本MSG时，输入的5个参数发生变化

可实际程序是只有一个MSG指令，运行时并没有修改管脚数据。

只有一个MSG时  可以写成3个同样的。

modbus_master_test.rar

下载了，感谢“Laohuai”侠，我看看。

通过几天和大家的交流，我想写一写通过一个msg指令的主站modbus rtu程序，到时候验证后再发上来，大家看看。

大致的思路有了，用一个msg指令，在msg指令执行完成的done位，当为1时（执行msg指令完成或报警时）修改下一个通讯指令的管脚数据，在下一个周期内开始执行，当通过几个周期后，完成msg指令，又出现一个done = 1，再次重新写入新数据，待下一个周期时再执行，如此循环往复进行，同时，也考虑当error出现数值时的处理。