引用0楼详细内容：

一次帮同事排除RS485半双工通讯故障的经历

  今天上午，我有家事没有去公司上班，同事电话打给我，说公司有一台涂装前处理线设备，由于批量的RS485从站硬件故障更换后，使原有的CB1241通讯信号板没有橙色指示灯的闪烁。我回复说没有闪烁，基本判断可能是因为在线的RS485通讯程序没有写完善，从站修复时出现的错误，或者通过批量的从站硬件故障，造成CB1241通讯信号板硬件的故障均有可能。我让同事在线，监控RS485通讯程序的实际情况，不多一会，同事通过微信把通讯程序发送过来了，图示1：

  看到此，我马上回复说：7000#是modbus_comm_load指令初始化完成的status的状态值，7000#是表示通讯初始化正常完成的状态值。但是，如果一旦通讯故障在排障过程中，也很容易在此掉坑。原因是对于初次使用者，对系统标志位“Firstscan”的工作特性并不会完全理解，当修改指令多次时，一旦编程者没有给plc断电再上电的操作，实际上“Firstscan”是没有正确触发REQ管脚，造成初始化指令失败，结果的通讯无法建立而此时status的状态值实际上仍然是上一次的正常完成值。我在应用RS485通讯初期也多次被此处的标志位“误导”过，所以，我马上回复了我对初始化指令的认识，希望同事能够如法炮制，微信回复图示2：

  modbus_comm_load指令的REQ管脚，我为什么特意加入自定义的用于手动初始化触发位，是基于在调试需要多次重复修改通讯程序时，需要重新初始化指令时的确保，手动使能为1后，再关闭使能，确保modbus_comm_load指令是完整被执行了的。

  此时，同事通过在线，马上回复说确实是通讯轮询过程中，modbus_master指令某一个站点停留住了，没有进行下面的轮询。我说这个问题主要是通讯轮询在从站故障报警时，通讯轮询指令没有做完整，当主站检测到从站丢站后，如果没有把error同时作为下一个modbus_comm_load指令轮询的触发依据，则通讯轮询会停留在故障报警站点的那个指令中。CB1241没有橙色指示灯闪烁，也符合此时的工况。由于，该设备的从站故障报警引起的，我让同事主要查故障报警站点的接线和通讯参数的设置情况，主要是站点；通讯频率；校验；停止位这些基本的通讯参数。很快电话再次响起，同事说原来的站点是14#站，由于没有意设到这个问题，把从站站点设置为24#了，重新将站点设置为14#后，轮询马上就恢复，设备重新启动恢复了前处理工艺，而我且陷入了沉思。每次帮公司同事处理类似的通讯问题，总是各有不同，记得有一次维修经历是一个RS485通讯的从站，由于从站仪表的硬件故障，造成从站数据无法正常读取，通过与同事咨询沟通后，我将该站点屏蔽掉，而数据的采用旁边位置的数据临时替换，几天后，仪表紧急采购到位后，我又将屏蔽了的程序重新恢复了处理。

  这让我也想起另一种触发方式，就是定时器接通延时方式的轮询，此类轮询对数据的响应要求并不高，可以不紧不慢的读一些数据，对数据的实时性要求不高的场合使用，毕竟，此类方法，可以有效的回避了从站故障报警时的正常轮询进程。而我自己在做RS485通讯项目时，还是喜欢用上一个modbus_comm_load指令的done+error状态值，作为下一个modbus_comm_load指令的REQ触发位，这样的方式最有效，图示3：

  通讯报警故障，只要仔细分析当前存在问题的表象，根据报警信息和模块指示灯状态信息，基本是可以判断问题的所在，是有章可循的。