关于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”侠的回贴，正因为我看到你的回帖反问，才使我进一步验证、查找这个原因。