关于200smart PLC调用modbus rtu通讯轮询时的问题

   今天，下午在“找答案”中看到有一侧关于200smart PLC调用modbus rtu通讯轮询时，无法正常轮询的问题。根据提问者描述：“当与一个从站通讯时，通讯正常。而2个从站（需要轮询时）无法正常通讯（无法实现轮询工作机制）”。

   看了提问者的程序，感觉没有什么疑点，因为提问者描述是按官方的例子程序编辑的。记得初次做modbus rtu通讯项目时，我也是按官方的例子程序测试过，没有发现什么问题。

   提问者的编程思路基本与官方的基本一致，开始也是先调用特殊标志位SM0.1将所有的触发位清0，然后初始化modbus rtu通讯指令，待初始化完成后，进行MBUS_MSG指令的轮询。具体问题链接：

http://www.ad.siemens.com.cn/service/answer/solution.aspx?Q_ID=189072&cid=1076

   晚上回家想起下午的那个问题，总感觉在那处出现不妥，于是，再次上网查看该提问。重新按提问者编辑了程序测试，发现没有报警错误error管脚数值0，但确实没有实现轮询工作，监控各标志位没有被正常轮询触发，图示：

打开帮助手册，仔细核对官方例子程序，发现有其中一个程序段与官方的有一些差异。即网络2与网络3的位置有区别，别的程序段均一致。

发现实际V1.3并没有随着初始化指令完成被触发，同时监控其它MBUS_MSG指令的触发位均为0，说明V1.3并没有被真正的有效触发过。

为验证给V1.3是否被V1.0触发，我在程序网络3中再增加了一个加1指令，数据地址VB100，图示：

监控结果仍然是没有被触发加1指令。

打开200smart 的系统手册，看是否能够找到该指令的具体说明。

关于modbus rtu主站初始化指令及MBUS_MSG指令的时间说明，图示：

这个初始化指令的执行时间在0.2mS ~ 0.1mS之间，并不存在plc的扫描周期的关联（程序的每一次扫描周期一定是大于该初始化需要的时间值）。

既然没有与初始化指令有时间上的冲突，尝试着将V1.0（NO）修改为SM0.1（NC）后测试，目的是先初始化完成一个周期后，再执行轮询工作机制，图示：

这个测试，说明当modbus rtu通讯的初始化程序正常后的第2个周期，触发MBUS_MSG指令程序可以轮询，这个与官方的例子程序的工作机制相吻合。

刨根到底想问题，为什么在同一个周期中，初始化完成标志位Done位无法触发下面的V1.3？

当只有这样的情况时，才有可能没有沿的作用，即SM0.0与V1.0在同一个周期内同时被置1，就没有沿跳变。因为库指令被加密了，无法再看到内部的处理程序段。为验证这个可能原因，我在网络4中增加一个验证程序段来验证这个想法，图示：

果不出其然，VB100并没有被激活加1，原因是特殊标志位SM0.0每次刷新的同时，与上升沿在同一个周期内，所以，沿无效。

那么，模糊的问题开始清晰起来了。如果V1.0等同于SM0.0的状态值，则实际上并没有沿跳变的可能条件，也就没有下面的轮询工作机制的环境。

小结：

该轮询机制无法正常工作的更本原因是：

1）  没有严格按官方的例子程序执行编程；

2）  看似正常的程序段，由于在特殊条件下（V1.0相当于SM0.0状态时）不能够正确产生沿的作用；

3）  程序段的结构非常重要，必须认清程序的扫描机制和特殊标志位是作用；

   程序虽然严格按自左而右，自上而下的扫描工作机制执行，但如果遇到特殊程序段应用时，确实需要思考可能存在的原因。有时候，我在编辑程序时也会无意间出现一些自己“匪夷所思”的现象，我会很“自觉”的有意把程序网络段置换个位置测试，可能会达到预想不到的效果，这个实际上仍然是对程序工作机制的理解程度问题，所谓“小问题，大智慧”。