您的位置:控制工程论坛网论坛 » PLC与PAC » PLC 通用性数据通信接口的研究

jshfq

jshfq   |   当前状态:在线

总积分:17995  2024年可用积分:0

注册时间: 2007-08-06

最后登录时间: 2013-11-04

空间 发短消息加为好友

PLC 通用性数据通信接口的研究

jshfq  发表于 2008/3/11 20:18:44      728 查看 0 回复  [上一主题]  [下一主题]

手机阅读









PLC 通用性数据通信接口的研究

 
摘 要: 随着工业自动化的发展,PLC 驱动程序的设计和开发成为最常遇到的问题。信道利用率和数据采集效率直接影响到整个监控系统的性能。本文讨论了设计和开发PLC 驱动程序的方法;详细介绍PLC 底层驱动函数的设计和实现;并探讨了提高信道利用率的几个关键问题。实验证明,能够降低开发成本并大大提高计算机监控系统与PLC 之间的数据通信的效率和信道利用率。 


关键词:可编程逻辑控制器,驱动,MCGS


Abstract: With the development of industry automatization. How to design and development PLC driver programs is coming into been one of the most critical problems.The efficiency of channel data processing is the key of the whole system. In this paper, how to design and development PLC driver programs is explored. This paper give detail design of PLC driver function and discuss several key problems about channel data processing. The experimental results show that, it can save cost and improve efficiency.


Keywords: PLC,Drviers,MCGS


    1 引言


    随着计算机科学技术、工业控制等方面的新技术的迅速发展,使用计算机监控系统与现场PLC 设备进行数据交换得到了广泛的应用。这类数据交换往往具有以下的特点,数据量大,采集点分散,带宽较窄。由于不同厂家所提供的PLC 现场设备的通讯机制并不相同,计算机监控系统软件需要开发的设备通信驱动程序就越来越多。这种复杂的设备驱动程序的开发具有以下的特点:


    首先,上位监控系统与PLC 设备间的数据交换,应用较普遍。


    其次,这种数据通讯过程,缺乏有通用性的框架设计,开发周期长,难度大,难以通用。


    再者,在有限带宽限制条件下的大数据量传输,普遍存在着信道利用率低,系统效率差,不稳定的情况,迫切需要大幅度提高信道利用率的算法。而且在已有的数据交换标准中,对于有限带宽条件下的信道利用率也没有成熟的设计。


    如上所述,开发PLC 设备的通用性数据通信接口具有广泛的应用前景和实现价值。本文主要针对上位监控系统与PLC 设备之间的数据通信进行分析,介绍了PLC 设备的驱动开发的方法,并提供PLC 通信的实例。


    2 PLC 驱动的使用


    本文中以使用串口通讯的PLC 为例进行分析和说明,监控系统为北京昆仑通态公司生产的MCGS 监控软件。开发工具为VC++6.0。


    MCGS 中PLC 已经将串口通讯的波特率设置等功能集成至串口父设备中,因此PLC 设备驱动是作为MCGS 监控软件设备管理窗口中的子设备提供的。它可以使用父设备的通讯功能,即可以与其他设备共享父设备的通讯功能。由于使用串口的PLC 设备较多,在这里我们以使用串口通讯方式的PLC 为例进行说明PLC 通用驱动的构架的开发。如使用自定义编程电缆方式或使用以太网方式连接,此PLC 驱动构架同样适用。


    使用串口通讯的PLC 与上位机的通讯方式中,有RS232、RS485、RS422 多种方式。如果设备是采用RS232 方式通讯,那么在一个串口下面只能挂接一个设备。如果采用RS485 或者RS422 的方式通讯,那么可以使用多个设备构成一个网络,在这个网络中,为了识别各个不同的设备,给每一个设备加上一个标志,一般来说把这个标志称作设备地址。这个总线上的设备分为主设备和从设备两类。在工作时,从设备一直在监听通讯线路上的数据,并对这些数据进行分析,当收到对自己的请求时,会发送一个相应的应答帧。主设备在工作时会根据需要向从设备发送请求帧,请求一些数据或者是发送一条命令,在发完请求帧后主设备需等待从设备的回答,这个等待的过程有一个超时时间限制。如果过了一定的时间还没有收到回答,它会认为本次通讯失败,然后按照一定的逻辑判断是应该重发请求还是放弃。


    通讯使用的通讯协议,分为ASCII 通讯和16 进制通讯两类。PLC 的通讯协议中大多数都是使用16 进制通讯。而且在串口通讯中,为了保证通讯的正确性、完整性,通常在通讯帧的尾部加上校验,常见的有和校验,异或校验,CRC 校验等等。


    在通讯过程中,上位机的MCGS 监控软件调用PLC 驱动,根据具体协议,向PLC 设备发送寄存器的读写命令,并接收应答数据。


    3 主要流程


    3.1 采集流程


    为便于说明,此处以一个采集周期内仅需单次采集的最简情况为例。在5.1 中的密集采集模式中,描述了对一周期内需多次采集的算法。


    采集过程描述如下:首先进行初始化,随后创建通道。进入数据采集周期,在每个数据采集周期中,首先形成读命令,随后校验发送数据帧,读写串口完成一次通讯,如果通讯成功,那么校验后将接收到的数据解码输出到通道,返回成功标识,如果通讯不成功或校验失败,返回失败标识。


    3.2 解析函数流程





    上图为解析数据帧的流程图。不同的设备具有不同的协议内容,使用定义好的模版解析函数只需要开发人员按照设备协议将帧分割为有效的数据部分,添入联合体FrameField 即可。该联合体可将协议数据最小分割为位来进行操作。





    如上图所示,第一个字节为帧头,最后一个字节为帧尾,第二个字节为状态标示,第三至第六个字节为模拟量,第七个字节为单位,第八个字节按位分为四路输入和四路输出。


    4 接口设计


    通常来说,一个厂家的同系列的PLC 产品,通讯协议一般是一样的。区别只是在于其中一些寄存器的大小不同。这样我们就考虑可以让这一个系列的设备使用同一个驱动。为了提高通用性,同时一般情况下,用户也不需要使用所有的寄存器,所以把这种设备构件的通道设计成用户可以在组态时自己进行定义。所有的通道及其所对应的参数(即是寄存器地址)都由用户自己进行定义。驱动程序根据用户定义的信息进行通讯。而且PLC 当中可能有一些参数用户并不常用,如果组成通道,每一个采集周期都要进行通讯,效率比较低下,考虑到这种情况,我们提供了一些外部接口供监控系统调用,在这些接口中可以发送命令,支持所有的寄存器通道。


    而对不同厂家的PLC 设备进行分析,也可以发现,可以将通讯过程和协议方式进行抽象,提取它们的共同点和变化点,封装和隐藏数据交换过程中的细节,达到通用的目的。通过封装格式,规范代码,统一接口,提高驱动开发效率,降低驱动开发的难度。提高代码的重用性,增强驱动的稳定性,减少设计中容易出现的错误。使开发人员把主要的精力放在对设备的熟悉和对协议的分析上,而不是过多地纠缠于编程实现的细枝末节上。


    封装的数据和操作包括:


    隐藏一次数据采集中的底层通讯过程(某些设备完成一次采集需要一次以上的发收过
程,如西门子S7200);封装针对采集点分散的动态采集算法;封装常用的命令操作;对与监控系统间的交互提供统一的接口;PLC 驱动封装了底层的通讯过程,只将接口方法暴露在外面,开发人员以统一的方式去调用这个方法,从而保证软件对客户的透明性,使开发人员从低层的开发中脱离出来,降低开发的难度。


    对驱动的开发人员来说,需要关注的接口仅有以下部分:


    定义设备本身的属性;如地址、实时采集的时间要求等;定义设备的读写操作属性;如通道数量等;通用设计仅提供跟设备协议相关的组包和解包接口,实现过程将由开发人员完成。


    5 关键问题分析


    为提供信道利用率,提高系统效率,在PLC 的通信框架设计中考虑了几个关键问题。


    5.1 三种采集模式


    经过对现有的数据交换的分析,将用户的一般需求拟概括为三种采集模式,即密集采集,按需采集,定时采集。


    密集采集模式:在这种情况下,用户希望能尽量利用物理带宽,保证最快的采集速度和更新。在这种模式下,理想状态是设备始终处于采集状态。采集目前所有激活通道中离需要采集的周期时间最小的通道。保证所有的通道都能获得采集机会,但是相对与其他模式,在该模式下CPU 占用率会比较高。


    按需采集模式:在通讯链路需要受控的情况下,比如用户采用GPRS 进行采集,按流量计费,所以不能进行大量的通讯。这时候通过设置采集模式为按需采集,然后在需要时再调用接口函数启动单次采集。否则不进行数据采集。
    
    定时采集模式:该模式是在CPU 的占用率和采集速度之间进行折衷的采集框式,保证在用户设置的通道刷新周期的时间内进行通道的采集,之后直到下一次通道的刷新周期到达再进行下一次采集。


    在模块设计中,采集模式作为设备类的一个属性,由开发人员根据具体情况,选择合适的采集模式。不同采集模式的采集算法实现如下:


    密集采集执行流程:设置一个采集周期如1000ms。每当开始一个新采集周期时,重新计算采集通道的优先级别。遍历所有的通道,找出目前优先级最高的通道,进行采集。对通道进行分块(块中包含最需要刷新的通道)。进入通讯循环(某些设备进行一次采集至少需要两次通讯所以需要通讯循环)。发送数据请求并等待回应;根据返回的信息解析出结果,并作相应处理;判断是否需要下一次采集,如果不需要跳出循环;更新通道和采集标志;继续发送线程消息启动下一次采集直到一次通讯循环结束;直到遍历完所有需采集的通道。


    按需采集执行流程:循环对每个通道进行采集,保存采集成功的值,并进行后续处理。定时采集执行流程由定时器触发,采集流程与密集采集一样,但在判断没有满足采集要求的通道不进行采集。


    5.2 采集点分散的动态采集算法


    在现有的数据交换过程中,用户关心的数据往往只占全部信息的很小一部分,而且这些采集点分散在海量的数据中,如果不加判断的依次读取数据,有效信息与采集信息的比例很低,实时性差;如果仅采集有效信息,分配的采集粒度过小,又会造成系统效率低下,信道利用率差。针对这一问题,采取以下的解决方法:


    (1)只采集用户关心的数据。如当有多个通道时,只传送当前用户只关心的通道的数据,而不关心其它的通道。保证采集尽量少的通道,为每个需要采集的通道提供更快的采集周期。从而减少通讯量。


    (2)对于待采集的数据分配不同的优先级,对实时性要求高的部分数据优先采集。可以根据用户设置的数据刷新时间来改变其优先级。


    (3)实现一个动态分块算法,在一个合理的粒度上对采集的信息分块传输,兼顾信道利用率与有效信息获取的实时性;实现的分块算法简述如下:在采集时判断,如果当前采集的寄存器类的激活通道可以组成一个数据请求包,则进行处理,提高一次采集的通道数。根据开发人员定义的通道优先级,找出优先级最高的通道地址附近的地址连续(或紧密)的通道,这些通道形成一个通道块。重复同样的过程,将剩下的通道继续分块,直到形成的块数大于某一规定的数值比如20 或将本寄存器的所有通道分配完成。


    (4)根据通讯协议的特点,在打包数据请求时尽量保证包含更多的请求,从而减少请求的总次数。


    6 结论


    根据本文的PLC 通用性数据接口开发人员已开发出多个厂家的PLC 驱动,并在不同项目中得到应用。在此PLC 通用数据接口基础上开发PLC 驱动,缩短了开发时间和难度。投入运行的系统通信稳定,采集速度快,通用性好,可靠性高。保证了项目的顺利实施。本文作者创新点:具有通用性的监控系统与PLC 通信接口设计,能够大大缩短开发时间和难度,并提高通信稳定性、实时性,具有很高的实用价值和经济价值。

1楼 0 0 回复