S7-1200与仪表 modbus通信死掉? - 工控编程吧

上传

点击文件名下载附件
如附件，如此简单的调用MB_MASTER程序，还可能怀疑和程序有关吗？
请斑竹给看看，谢谢

------------如果出错的话，是否要对串口进行重新初始化的工作，光靠延时等待串口是不会复位的

--------关键是通信模块的数据收发灯都灭了。

我在现场时，重新调用comload初始化，和重新调用保护MB_MASTER的FC，都没用。
只用把CPU断电，再上电。通信模块的收据收发灯才重新亮起

---------很久之前确实这么用过，EN的条件用常ON。
但是从一个项目发现，这样的话，指令的error信号经常采集不到。也就是某个从站通信线摘掉，也报不出通信错误来。
后来还是在EN端加上了条件。
西门子技术支持说，只有这么用才是对的，EN用触发信号的触点，REQ用触发信号的上升沿。话说的是有点绝对，为了查问题，不争论这个了。
到目前仍在测试中，通信模块的数据收发灯灭掉不干活了，觉得有点不可思议。
平时谈论多的是干扰，但从没见过干扰能把通信模块灭掉的。
链接我稍后看看，谢谢

------------其实，CP340/341，S7-200，ET200等串口通讯都有这个问题，我认为是前错未复位，后错又来了，导致系统内部堆栈溢出，干脆不工作了。我的解决方案就是评估每一次通讯的状态位，做相应的处理，这样就不会导致在短时间内重复出错而使模块停止工作了

--------不知道修改通信模块属性中，“消息终止”的超时时间，会不会有帮助。
--------我在调用MB_MASTER指令过程中，每次调用，50ms（肯定大于扫描周期）的间隔内是切断MASTER的EN使能的，切断时不就是相当于释放掉了嘛。

-------把你的消息开始的画面截张图看看

--------默认值
(, 下载次数: 30)

上传

点击文件名下载附件

----------不对，应该选第二个：以特定条件开始接收。
然后勾选空闲行时间为40个bit（modbus的3.5字符）。
虽然选择默认也是可以通讯上，但是容易出问题。

--------------
(, 下载次数: 23)

上传

点击文件名下载附件
(, 下载次数: 25)

上传

点击文件名下载附件
(, 下载次数: 16)

上传

点击文件名下载附件

--------modbus一个很显著的特征就是消息的启始均有3.5字符以上的延时。所以，
１、你的PLC发送报文的时候也要先发送40位的空闲信号
２、接收报文的启始条件要以线路空闲40位时间以上作为条件
３、接收报文的结束条件同样也要以空闲40位时间以为作为条件。同时消息超时时间和最大字符数量可以根据你实际的项目要求设置。

---------感谢才伊侠深刻的讲解，会在后面找机会按照伊侠讲的来试试。
目前项目现场已经生产，不宜过大动作，降了一档的波特率，目前看有些效果。

另：
1.消息最大长度和用MB_Maste执行一次r读取的数据量要对应？
2.“通过消息超时识别消息结束” 和 “通过字符间超时识别消息结束” 二者取其一，还是都生效呢？
3.S7-1200CPU属性中，有一项是通信负载，默认为20%，有没研究过什么意思呢？我提高到30%，会有和影响呢。

-----1、是的。
2、是ＯＲ的关系，二者都生效。
3、手册上有相关说明，不明白可以度娘。

---------关通信负载，可以理解为通讯占整个循环扫描周期的百分比时间。
但是调节时间比例，带来的结果是什么

--------硬件有问题吧。

-------不怀疑硬件啦

---------关于通讯负载，我是这样理解的。
这里说的通讯负载是指那些作为服务器-客户机之间的数据传输（不用编程的）；运行时，PG对PLC的块上下载和对程序快、数据块监视、测试这些通讯操作所占的比例。它主要是：当出现上述操作时，主循环（扫描周期）时间会加长。如果设置50%，当上述通讯满载时，主循环就加长一倍时间。
这还不包括那些中断（硬件中断、循环定时中断）加入的时间。
所有对IO的访问、对模块的通讯，对分布IO的通讯都不算这类通讯负载。
所以，对此参数的建议是：
除非此PLC主要用于前面说的那类通讯，才增加该值。
其他所有情况下，只应当减小该值。

---------谢谢大家，都有一定道理。
还在寻找更多量化的指标过程中

----------同意19楼的看法

--------还是要考虑通信干扰的问题，我遇到过一次和你相仿的问题，就是由于干扰导致的。

---------楼主问题解决了没有？

------------我也遇到同样的情况。通讯块显示一直处于busy 状态。信号板指示灯不亮。编程软件重启plc恢复正常。平均每两个月发生一次。
plc里面可否有重启指令？当检测到，长时间处于busy状态时，自动复位重启？

---------modbu线有没有接好啊

----------楼主既然降低波特率有改善，说明现场的干扰影响还是比较大的！不知道楼主的通讯距离有多远，可以试着加485隔离器。另外就是两个设备接地以及通讯电缆的进一步抗干扰处理，比如穿管等处理。条件具备的话，建议将CPU和仪表拿到工况较好的环境中做下测试，以便确定程序设定、硬件或者干扰问题。

---------还要看一下线路有没有接好，走向有没有问题，接头有没有做好，

----------重新启动一下呢试试

-----------不知是不是带的从站数量过多导致的，我觉得楼主可以先用其中位置较近的两个从站做实验。这样可以确定程序有无问题，进而再查找其他问题。

--------既然降低波特率能好电磁干扰的可能性最大，考虑一下屏蔽和接地问题，还有两端等电位的问题！

------------这种情况我们遇见过，是网络中某一个仪表内部插板与外壳接线端子接触不良所致，可打开仪表，校正内部的接口，同时用橡皮檫檫接口位置。

----------建议轮询不要用done和error bit来做，很容易出错。我之前这样做的，说什么也不能轮询，看status也看不出是什么问题。最好的办法是用计数器，每个50ms增1，然后用用计数器的数值来调用modbusmaster，不去管什么done或error，机械性的轮询。

-----------modbus通迅本来速度就慢，对响应速度要求很严的场合不适用。

再者写这种程序时，另外再加一个监护程序，当发现轮询跳不动时，或轮询死机时，做一次故障记录并复位重启轮询程序。这样会好很多。

欢迎光临工控编程吧 (https://www.gkbc8.com/)