关闭

项目那点事之OPC

标签: opc
1292人阅读 评论(0) 收藏 举报
分类:

这段时间实验室做一个智能监控的项目,涉及到现场多个设备的控制以及数据采集。计划采用PLC通过485总线与各个设备进行数据交互,同时增设一台工控机进行上位机操控,与PLC进行数据通信,一方面通过上位机程序对各设备进行控制,另一方面实时显示各设备的运行状态。

我主要负责工控机这边上位机程序,采用LabVIEW语言编程,需要跟PLC进行通信,然后再借由PLC与现场设备进行数据交换。实验室采购的PLC型号是西门子的S7-1200系列,该型号PLC支持两种通信方式,一是485,二是以太网,由于PLC不仅需要跟工控机通信,而且项目也计划在远端增设一个监控室,远程去对现场设备进行监控,因此决定选择以太网进行通信,采用TCP/IP进行数据通信,这里又存在一个问题,如何确定服务器和客户端?按理来说,数据采集端也即PLC应作为服务器,工控机和远程监控室计算机作为客户端去访问PLC,这种思路去设计程序是比较合理的,但是也不知道当时是怎么想的,硬是将工控机作为了TCP服务器,PLC和远程监控室计算机作为客户端了,这样设计的话,相当于将工控机作为一个数据转发的平台,一方面将PLC采集到的设备数据显示在本地,另一方面将数据转发给远程计算机;而对于远程计算机所发出的控制指令,也通过工控机进行中转后,再发送给PLC,最后经由PLC将控制指令送达各设备。

大方向就不用说了,不管那个作为服务器哪个作为客户端暂且不管,接下来最大的问题是如何设计这个网络应用程序,我的第一反应是采用TCP/IP协议,也就是说我们需要直接操作OSI 7层模型中的传输程,在LabVIEW中,已经给我们提供了进行网络通信的各种VI,可直接调用这些VI即可完成一个基于服务器/客户端模型的网络应用程序,但是事情往往没想象那么简单,首先,工控机与PLC进行数据交换的协议虽然LabVIEW已经给我们做好,但是仍然需要我们对每个数据定义出自己的封装,也就是需要重新数据帧格式,另外,由于TCP/IP协议只是提供了两个应用程序进行通信的底层协议,具体的比如说服务器的建立,侦听以及接受客户端连接等所有过程还是需要我们自己在程序中去设计,因此总的来说,我们还是需要编写大量的代码去实现就算是一个温度采集或者远程开关这么小的功能。因此,采用TCP/IP进行编程不是一个最优的方法。

我们知道TCP/IP协议属于网络层,直接操作需要对该层协议有充分的理解,如果能够避开该层操作,有现成的应用层协议可以使用的话将大大减少开发的难度。如果大家都遇到类似的问题,那么总有解决方案为之应运而生了,这里OPC技术挺身而出了。

什么是OPC,全称是OLE forProcess Control, 也即微软的对象连接与嵌入技术在工业过程控制中的应用,OPC基金会负责OPC协议的制定和发布。什么是OPC,说白了也是一种网络协议,封装了TCP/IP协议,因此该协议处在应用层。它能够为我们的编程带来什么好处?首先,在我们传统的工业过程控制中,现场设备种类繁多,并且各个设备之间的通信没有固定的协议标准,有的采用485通信,有的采用以太网通信等等,这带来的麻烦就是,我们需要对每个设备都要编写不同的驱动程序,如果设备进行升级或者硬件上的微小改动,都有可能导致驱动程序的重新设计,因此系统集成商和开发商急需一种具有高效性、可靠性、开放性、可互操作性的即插即用的设备驱动程序,在这种情况下,OPC标准应运而生。现在市场上的大多数工业控制设备均支持OPC协议,因此大大简化了我们编程的难度。

首先,s7-1200自带OPC Server,另外也非常惊喜的发现LabVIEW的DSC 2012模块支持OPC协议,并且包含有S7-1200驱动程序,也就是说我们只需要在工控机上采用LabVIEW编写一个Client就可以利用OPC强大的数据访问能力完成工控机与PLC的数据交互,并且大大简化编程。具体如何在LabVIEW中去创建OPC Client以及如何与OPC Server 进行通信参见NI 教程。

教程链接:http://download.csdn.net/detail/fukai555/6644739

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:32716次
    • 积分:709
    • 等级:
    • 排名:千里之外
    • 原创:38篇
    • 转载:4篇
    • 译文:0篇
    • 评论:2条
    文章分类
    最新评论