黑河莺落峡站全自动水文缆道调试中出现故障及排除方法

2010-09-05陈学林王伟民王学良

水利规划与设计 2010年6期

关键词：计数器限位编码器

陈学林王伟民王学良

(1.甘肃省张掖水文水资源勘测局甘肃张掖 734000;2.甘肃省水文水资源局兰州 730000)

1 黑河莺落峡站现状和新建全自动水文测验缆道概况

水文缆道是最基本的测验渡河设施,是进行水文测验的物质基础。铅鱼缆道和吊箱缆道是目前普遍采用的两种水文缆道型式,主要由缆索与支架、驱动与控制、流量测算与处理三大系统组成,可根据测站的河道水流条件选择建设。

1.1 现状流量测验缆道

莺落峡站位于甘肃省张掖市龙渠乡三清湾村,距张掖市34km,是黑河上游水量进入中游的控制站。莺落峡站测验河段内现有铅鱼测验缆道1座、拉偏缆道1座、浮标投掷器1处,这些测验设施多建于1975年,部分建于1975年以前。由于受当时经费及技术等条件限制,普遍存在着设计建设标准低、设备配置落后、操作使用不便、测验费时费力等问题,再加上年久失修,缆道支架扭曲变形 (见图1)、主索锈蚀严重、驱动控制系统操作不灵等,不仅不能满足测验工作的基本需要,而且还直接威胁着测验人员的人身安全。

1.2 全自动水文测验缆道

莺落峡站位于深山峡谷的出口处,水深流急,为确保测验人员及设施安全,设计建设全自动铅鱼缆道及拉偏副缆各一处。通过黑河流域综合治理中黑河水量调度管理系统建设项目实施。通过对水文测验设施的建设、更新和改造,来完善水文测验设施设备,提高测洪能力,实现对缆道站的测验控制、信号传输、信息处理、数据存储等将会有比较大的改进。

全自动铅鱼缆道是集交流变频调速技术、光栅编码测距技术、缆道测流技术、计算机技术和数据整编技术于一体的、自动化程度较高的水文缆道。该缆道实现了流量信息采集的智能化,具有自动、半自动、手动及图像监视等多种功能,具有技术含量高、操作使用方便、节约人力资源、提高测验效率等特点,适合在水深较深,流速较急的河道断面上建设。

图1 莺落峡站新建水文缆道示意图

2 全自动水文测验缆道组成

莺落峡全自动水文缆道主要是为了实现及时、准确的测量水流,报告水情而研发的一种测流设备。该系统主要包括以下几个部分:

①双电源控制箱。双电源控制箱内布设了两种电源进线途径,各自通过一个漏电断路器来作为电源进线总开关,两种电源采用了机械互锁,当其中一路电源出现故障时,另一路电源就可及时的接通,不影响我们对水文缆道测流的正常进行。

②控制柜。控制柜是我们进行测流的主要设备,它类似于我们一台计算机的CPU,是水文测流的核心。柜内主要由工控机、触摸显示屏、变频器、PLC、变压器、交流接触器、中间继电器、热继电器、互感线圈、电流电压表及一些按钮指示灯等组成,共同完成测流任务。

③驱动电机、减速器和旋转编码器部分。该部分主要是用来控制铅鱼的上升、下降、前进、后退等动作,从而完成我们对起点距、水深等数据的采集和传输。

④钢架及缆索结构。该部分是组成缆道的重要硬件,它主要由钢架、主索和副索等构成。

⑤铅鱼。铅鱼主要是现场进行采集数据的设备,其上面装置了无线水文收发器,来进行河面、河底、流速信号的传输。

3 调试中出现故障及排除方法

3.1 PLC与工控机通讯不上

3.1.1 故障现象

在进行PLC与工控机通讯过程中,发现PLC与工控机通讯不上,连接超时,而且PLC各指示灯均不亮。

3.1.2 解决思路

首先、检查PLC与工控机之间的通讯设置,看是否有设置错的,更改完参数后,发现仍然连接不上,故障现象依旧;其次、检测通讯电缆的质量问题,经检测,发现不了问题;最后、根据PLC各指示灯都不亮的现象,把问题归结于PLC的硬件连接及产品质量问题上。

3.1.3 解决办法

将PLC从控制柜内拆除,进行检测,根据硬件接线规则,发现PLC的电源进线端接错了,错误接线如图1所示。

在图2(a)中,错将电源进线AC220V与N端接到PLC的N与地线端,导致PLC不能正常工作,由于这样接线,并未对PLC造成损坏,需要以后接线时注意认真检查接线线路,以免造成不必要的麻烦。图2(c)才是正确接法。

图2 PLC与工控机连接方式

在处理该问题上,了解到该型号的PLC若错误的将电源进线按图2(b)的错误接法,将对PLC造成致命的损坏,值得以后注意。

3.2 限位开关的接法,不能很好满足用户需要

3.2.1 故障现象

原来只是在软件方面考虑了限位信号的作用,并没有考虑在硬件上的限位作用,所以需要对限位开关的接线进行修改。

3.2.2 解决思路办法

由于我们需要将工频和变频控制回路都接上限位,而现场只有一组干接点信号,故需要增加继电器来实现该功能。将现场的限位干接点信号采集过来,接至限位继电器的线圈,同时再通过限位继电器的2个干触点,分别接至工频和变频控制回路。改动后的电路图如图3所示:

图3 限位继电器控制电路

工、变频电路如图4所示:

图4 工、变频控制电路

经实验后,能可靠的实现硬件限位的作用。在此更改之前,也曾经对限位继电器电路做了下面2种接线方式,每种又有不同的错误。

图5 限位继电器控制电路

在图5(a)中,我将各限位继电器进行了互锁。实验表明:虽然可以实现限位控制,但是却不能解开自锁,致使上升限位到达以后,下降不到下降限位时,上升限位就一直接通,致使铅鱼不能够上升,这样显然不符合限位的作用。

在图5(b)中,我产生这种既不采用自锁,也不采用互锁的接线方法的思想的原因是:对方的限位信号能可靠的接通,故直接采用了上述接线方式。经过实验发现:铅鱼上升时,可以实现很好的限位,而在铅鱼下降时,由于铅鱼的自重,导致铅鱼总是在到达限位的位置时,在自身重力的作用下,还继续下降,所以这种接法也行不通。

于是在综合了上面2种行不通的接法的基础上,我采用了如图4的接法,并且达到了预期效果,满足了现场铅鱼工作的需要。

3.3 Fix数据库与PLC连接不上,直接造成Fix工

3.3.1 故障现象

Fix工控界面上的按钮动作时,PLC没有执行相关的动作。

3.3.2 故障分析

针对二者之间无法连通的问题,我分为四步来查找产生故障的原因。

①确认 PLC能与计算机通讯良好,且保证PLC是在运行状态。在Step 7-Micro/Win软件中,实现程序对PLC的控制,二者之间的参数设置如下:

a)计算机COM口设置如下:

b)PLC通讯端口设置如下:

当我们用通讯电缆连接后,可以实现PLC与计算机之间的通讯。

②检测PLC与PC Access之间的通讯连接问题。这步测试,主要是通过仿真测试,来检测二者之间的连接。我们将PC Access内的任意一项放到测试客户端内,然后启动仿真测试,经过测试,状态为良好 (GOOD),这说明问题也不在这里,需要进一步测试。

③检测S7200.OPC Server与PC Access之间的通讯连接。我们使用的I/O驱动器的名称是:OPC Client V7.32C。在运行OPC Server时,发现通讯质量为Bad,而且Data一项为空白,没有任何数值传送过来。经过OPC POWER TOOL界面上的各个选项逐一对照,具体修改如下:

将各个项目代码Item界面上的Enable后的方框选中 (即在方框内点上"∨"),再次进行启动测试后,状态良好,PC Access里的数据能够传送至OPC Server。

④建立Fix数据库与OPC Server之间的通讯连接。把 Access中的 Item1换为 MicroWin.PLC226.ZJT LDSDZSD后,并且将Fix数据库中的各项的I/O地址改为OPC里的Access的内容后,OPC Server能将数据传送至Fix数据库。确认以上四步之间的通讯连接无误后,看到PLC的内容及状态可以成功的在Fix数据库中显示出来。

3.4 编码器与PLC之间的硬件连接问题

3.4.1 故障现象

当Fix数据库已经建立与PLC之间的通讯连接后,发现计数器并没有计数,而且当前值始终是0,没有变化。这样影响了整个工程的进度,需要及时解决。

3.4.2 解决思路

仍然根据 “先硬件、后软件”的原则,来逐步找到原因。

3.4.3 解决方法

检查编码器的连线是否正确,有没有接错或接反的现象,尤其是电源进线,在仔细核对了编码器的五根接线后,发现硬件并没有接错,但是PLC各输入端指示等也不亮,这样就感觉编码器与PLC之间的连接好像有点问题,于是就从这里作为一个突破口。

首先从欧姆龙编码器与欧姆龙的PLC的连接着手,发现它与欧姆龙PLC连接的接线规则:对于其内部结构是NPN型的编码器,连线时将PLC的COM端接至直流电源 “+”端,而将PLC的其他I/O输入口的公共部分接至直流地 (如图6(NPN型)所示);相反,PNP型编码器与PLC的接线方式是将PLC的COM端接至直流电源 “-”端,将其他的I/O输入口的公共部分接至直流电源"+"端 (如图6(PNP型)所示)。

图6 NPN、PNP型编码器与PLC接线规则

根据这个接线规则,我们重新寻求西门子技术支持,了解西门子PLC与编码器的接线规则与这个一样,于是对线路做了如下调整,如图7所示:

图7 编码器与CPU226接线

经过线路改动后,PLC的I/O口也出现了闪烁,说明已经正常接通。

3.5 关于S7200高速计数器程序问题

3.5.1 故障现象

在正确接线之后,PLC工作也正常的情况下,使用高速计数器指令,发现高速计数器当前值一直是0,感到程序应该出现了问题。

3.5.2 解决办法

在几次试验失败之后,借助于高速计数器指令向导,来配置高速计数器初始化指令,配置过程如下:

首先根据指令向导,配置HSC0在模式10下工作的初始化程序:

Network 1//指令向导HSC

//欲在程序中启用此配置,请使用SM0.1或某边缘触发指令从主程序块调用此子例行程序一次。

//为模式0配置HC10;CV=0;PV=0;向上计数;

//启用中断和开始计数器。

图8 HSCO初始化子程序、主程序

经过这样对计数器进行配置后,又做了主程序的配置 (如图8),这样就在程序中看到了计数器的当前值。先前出现不了数值的原因,极有可能是因为对特殊存储器SM标志位使用不当造成的。原来配置的初始化程序中,在调用初始化子程序HSC_INIT时,使用了SM0.0,而在初始化里使用了SM0.1,结果导致高速计数器没有显示,即工作不正常。

由于在该工程中,只需要将高速计数器的当前值读出来,其它的不需要,还需要将当前值失电保存,所以需要在原来的基础上,做上计数器清零程序 (如图9所示)和计数器当前值掉电保持程序(如图10所示)。

图9 HSCO复位子程序

图10 HSCO当前保存子程序

3.6 编码器读数始终徘徊在-600～+600之间,数

3.6.1 问题分析

因为编码器读数只在一个脉冲范围内变化,所以估计与编码器工作的模式及接线有关系,所以进行如下尝试,终于找到了原因。

3.6.2 处理方法步骤

①缩短编码器通讯线的距离,来进行测试。因为本工程所使用的编码器通讯线的距离是3m左右,而现场的通讯距离大约在10m左右,于是首先进行了缩短通讯线距离的试验:将现场其中一个编码器拆除,移至PLC旁,即在其通讯距离范围内,看计数器是否能显示正常读数。试验表明,与未拆除之前的效果一样。

②将编码器输入端的Z项拆除。因为在模式10时,Z项表示复位脉冲,是不是在每转一圈时,都将产生一个复位信号,致使编码器不能累加计数呢?拆除Z项后,计数器不再出现复位信号,而且能连续增减计数,符合该工程中计数器的使用。

③实现第二步的功能后,我们又进行了第三个测试,也就是通讯距离在10m左右时,能否正确计数。将未拆除的编码器也按上面的接线方式连接后,也能正常工作,这跟我们预期的结果一样。

④进一步修改计数器程序,最终将程序更改如图11所示。

图11 初始化子程序和主程序

经过这次修改后,基本上在数据方面不存在什么问题,为下一步工作奠定了一个很好的基础,在修改软件程序的同时,也将硬件连接改为如图12接法:

图12 编码器与CPU226

3.7 Fix数据库与PLC之间出现通讯时间过长,影

3.7.1 出现现象

在工控界面上点击"按钮"后,PLC将会在5～7秒之后响应所执行的命令,延迟这么长时间,不符合工程中的规范要求。

3.7.2 问题分析

因为我们这个响应过程是按照下面的 “级联”关系进行的,所以需要我们从各个环节中去寻找延迟环节。

3.7.3 解决途径

把各个环节之间的关系网画出来,如图13所示:

图13 级联网

从上面这个级联网中,我们能够看到,从Fix工控界面到PLC响应需要经过3个中间环节,其中任何一个环节都可能造成响应延迟的局面。经过逐步检查,最终发现延迟环节是在从Fix工控界面到Fix数据库的连接过程中:当我们点击工控界面上的按钮后,Fix数据库中按钮的状态在5～7s之后才会发生改变。

①检查Fix数据库的设置问题,并未发现有什么不当的地方。

②检查OPC Server的刷新速率,原来设置的更新速率是 1000us,现将该值更改为100us。另外,在OPC Server中发现Item无用选项特多,都是在书写所需的Item时,自动生成了很多无用的Item,也可能是造成PLC反应较慢的原因之一。

在对OPC Server中的Item进行删除的时候,发现OPC Server中的Item删除之后,会在后面继续增加无用的Item。换句话说,直接在OPC Server中进行删除的方法是不可行的,必须通过其他途径来进行删除。

在Fix数据库中,有导入、导出项,可以对数据库进行编辑,先导出来,然后进行修改,而且在数据库里面也可以直接进行修改,不会产生无用的选项。而在OPC Server里面没有导入、导出的功能,所以也就不存在将数据进行导入、导出的操作了。在进行OPC Server数据库进行保存的时候,我们发现将其另存为 .scv文件后,我们可以在 .scv文件中进行修改数据库的操作,修改完毕后,可以还保存在这个文件中。当我们下次打开OPC Server后,在打开菜单栏里选择所修改后存储的.scv文件即可。

③由于系统的上位机与下位机之间的通讯,采用的是串口通讯,加上串口通讯自身的限制,通讯波特率较低,反应时间长等因素,也可能是造成上位机与下位机通讯反应慢的原因。

④在PC Access的扫描设置上,发现扫描时间是1000us,也将此设置值更改为100us。

在测试过程中,发现只要Fix数据库中的状态一反应过来,PLC就迅速执行相关动作,并且,将PLC程序缩短后,也一样是反应慢,故基本可排除下位机自身程序长造成PLC反应时间长的可能。