分享

记以太网环网故障的一次解决过程

 甲基丁酸 2019-02-21

1. 项目基本信息

Basic Project Information

食品饮料行业。主干网为6台414的交换机组成光纤环网,连接plc与所有pc站以及服务器。Plc侧的PN IO以及第三方的非实时数据通讯都由plc上的cp443来完成。下面再通过若干个x208采取就近的原则接线方式,将设备组成网络。并且x208与x414是连接在一起的。两台服务器一主一备,通过OPC-Server采集下面S7设备的数据,上位机为IFIX。现场有很多第三方的设备接入网络中,而且网络没有划分子网,仅是根据不同的ip地址来区别。下面是网络主拓扑结构。

2. 现场问题描述

the problem description

用户反映在生产过程中,第一ifix数据刷新慢;第二偶尔有网络掉线的故障,恢复时间为秒级,或者毫秒级恢复,发生的时间不确定。问题解决的难点,在于用户无法提供现场网络的实际拓扑及接线图,而且处于生产状态,没法停机检查,给故障的排场增加了很大的难度。

3. 现场问题分析

Problem Analysis

第一个问题,数据刷新慢的话,可能出现的可能就是网络拥堵,网络负荷大;还有就是opc server里面的刷新周期设置是否为最小250ms,还有就是在ifix里面的对外部数据库链接的刷新周期是否合理。通过在服务器侧Ping现场的设备,延时大都在10ms之内,并且在服务器侧以及工程师站对plc进行上传下载程序,以及在线监控数据时,速度都很快,所以证明不是网络负荷的问题。建议用户检查ifix及其相关的opc设置。

第二网络掉线问题,

1)     检查网线及接口及带有fc变频器的et200s站的接地,以及ip地址检查。

2)     检查x208的日志报文。

3)     数据通讯的性能判断。

4)     数据响应检查。

5)     cp1613的性能检查。

6)     opc_server的检查。

7)     plc的性能检查包括连接资源以及通讯负荷。

通信资源就是通信双方为了执行通信服务而进行的连接资源和通信任务资源的分配。通信双方的数据交换需要通信资源,由其中的连接资源和通讯任务资源两个参数决定。当超过连接资源,新加入的通讯双方无法进行通讯。例如CPU319-3PN/DP具有16个S7连接资源,当通过NetPro组态S7 Connection通讯连接设置为16个后,就无法再加入其它的通讯Partner与该CPU进行通讯。当超过通讯任务资源,其它连接资源的通讯双方无法进行通讯。例如CPU319-3PN/DP组态了16个S7 Connection通讯,其中一个连接使用了32个通讯任务,那么CPU319就无法与剩余的15个连接Partner进行通讯。在S7-300的CPU属性中可以分配S7连接资源给相应的S7通信服务。而S7-300的CPU中路由连接资源是独立提供的,并不占用CPU所提供的其它相应S7的通信服务。例如:根据CPU319-3PN/DP的技术数据,PN接口的路由资源数最大为48。其它S7相应的连接资源为32个,这些连接资源用于PG/OP/S7 Basic/S7通讯服务。

在S7-400的CPU属性中无法分配相应的S7连接资源。相应的S7通讯服务共同占用CPU所提供的所有的S7连接资源。只能通过CPU在线的方式查看CPU的S7连接资源的占用状态。例如:CPU416-3PN/DP

S7-300与S7-400区别,前者的扫描循环检查点CCP处输出通讯数据,后者每个时间片都可以发生输入输出通讯。如果通讯任务量大且实时性要求高,则应选择S7-400的PLC,而不要选择S7-300的PLC。

S7-300而言可以释放在硬件组态里面的设置的通讯所占的比重,来改善通讯的实时性!

4. 现场问题处理步骤

Problem Solving Steps

网络掉线问题

1)     现场的通讯电缆检查,用户已经更换新的通讯电缆。检查变频器的接地,以及核对各个组件的ip。

2)     检查x208的日志,未发现异常。

3)     检查网络的通讯性能,通过ping的方式。响应时间在10ms之内,说明网络数据响应正常。

4)     cp1613的最大连接支持120个,而实际现场为70个。

5)     opc_server数据量核查,最多可以支持100000多条。

6)     对plc和cp443上的诊断进行分析,发现,如下图

在plc的诊断信息里,总是有信号报警,查看信号的地址,再查看上一级的pn io的地址。发现在plc的pn io的刷新时间不是一定的,有2ms,4ms,8ms,16ms,256ms等。并且发生这种信号报警的所在的站点的刷新时间多为2ms,4ms。然后进行了下网络性能测试,方法 运行-CMD-PING 10.155.28.81,测试对其中一个ET200S的通讯性能。结果数据没有发生丢包,延时时间平均为4ms。从以上说明中判断,pn io的刷新时间过短,因为此工艺段包括pn io设备25个,而且同时兼顾上位机的通讯,以及十几个连结的s7通讯和tcp的通讯。如果pn io的刷新时间过短,又由于整个网络的负荷,可能造成网络的数据通讯不正常的影响,甚至掉线。查看plc的扫描时间平均为30ms左右,所以可以把pn io的刷新时间放长点。更改为8ms。修改完,正常生产了一天,检查plc的诊断缓存区发现无信号报警。见下图

修改完后,ping测试网络性能。延时时间3ms,见下图

在S7-300 cpu硬件属性里把通讯负荷由20%更改为40%,这样预留更多地资源给通讯。更改完后,监控两天,没有发生掉线的事故。

5. 处理结果

the final result

将pn io的刷新周期变为8ms。并且在S7-300 cpu硬件属性里把通讯负荷由20%更改为40%,这样预留更多地资源给通讯。更改完后,监控两天,没有发生掉线的事故。

6.基于现场的实际情况,希望通过销售给用户的建议:

Suggestion to customer:

在后续的项目中,针对用户这种有大量的设备需要挂在网络节点上的使用方式,可以通过划分不同的子网,这样便于故障的分析查找,以及数据的隔离!

大锅饭不是那么好吃的,以太网虽强,但大家都在抢资源,也会堵车的,414-3E交换机喃喃地说。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多