QQ登录

只需一步,快速开始

S7-1200与仪表 modbus通信死掉?

[ 复制链接 ]
S7-1200与仪表 modbus通信死掉?各位大侠,最近遇到一个问题。
我用S7-1200与某仪表通信,一个RS485/422通信模块带14块仪表,仅仅一个读指令读取数据,程序也非常简单。
但是出现一个奇怪的现象:
一开始先上通电7块仪表,也就是一个大循环中,仪表地址1-7是成功done,仪表地址8-14错误error;运行了一周正常。
第8天,地址是8-14的仪表也通电了,相当于14块仪表都可以通信。但是运行了一天,就出现了通信死掉的情况。
现象1:上位机上的值都不变化了,肯定是通信断了。
现象2:通信模块的数据收发指示灯彻底灭掉(正常的时候是频闪)。
各位有没有遇到过此情况,或者谁有好的建议,不胜感激。

S7-1200与仪表 modbus通信死掉?

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使能的,切断时不就是相当于释放掉了嘛。

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

--------默认值
635654842793052777.jpg

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


--------------
635654882415250370.png
635654882514466544.png
635654882615242721.png

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


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

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


-----1、是的。
2、是OR的关系,二者都生效。
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通迅本来速度就慢,对响应速度要求很严的场合不适用。

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




回复

使用道具 举报

大神点评(1)

点击查看
快速回复 返回列表 客服中心 搜索