OPC通信速度不慢！ 点击：11912 | 回复：64
发表于：2007-10-28 16:40:00
楼主
“创世纪32”GENESIS32的好处是OPC核心软件，不像其他软件如inTouch、iFix、Citect、TracMode、紫金桥、组态王、力空、杰空、易控、世纪星、开物…等等，他们都有自己的IO驱动程序，都是专用的、封闭的，他们各自开发的IO驱动程序只能够在自己的系统运行，不能互用。
OPC是一个标准、开放的IO服务器（等于他们的IO驱动程序），但是OPC可以安装和运行在任何SCADA/HMI系统，当然这些系统必须支持OPC啦，对最终用户是一件好事情，因为他们就不会受限制于这些专用的、封闭的软件系统，如果他们不给你开发一些新的IO驱动程序，你根本不可能把现有的系统连接到一些新的设备或者系统，用户根本就没有办法，只能够忍耐、等待他们大发慈悲给您开发，或者您要付出一笔可观的费用请他们帮您开发IO驱动程序。
此外，这些SCADA/HMI系统都说可以连接OPC，其实，他们只是写了一个OPC的IO驱动程序去连接OPC服务器，做工程时要建立2个数据库：
1)如果您用Kepware OPC服务器，首先您要建立Tag在KepwareOPC服务器中，
2)然后，再利用这些软件的OPC IO驱动程序去连接Kepware OPC中的Tag，把这些Tag连接到自己数据库的Tag。
等于做了两次数据库，比较麻烦！
“创世纪32”GENESIS32的优点是可以直接浏览Kepware中的Tag，马上可以连接到动态图上，不需要再建立Tag才可以连接到动态图，很方便，做工程会节省不少时间，时间就是金钱啊！
有不少人都说OPC很慢，其实他的观点有些不对，由于过去他们只用这些非OPC核心的软件去连接OPC服务器，感觉上动态图的动态点刷新时间会比用他们自己的IO驱动程序慢，问题不是在OPC服务器上，问题是在这种接法而产生的，事实上肯定会慢，动态图的动态点首先从他们自己的OPC IO驱动程序去读/写Kepware OPC的Tag，然后Kepware OPC服务器又去读/写PLC的点，中间就多了一层通信，肯定慢。
但是，“创世纪32”GENESIS32是OPC核心软件，动态图中的动态点直接就访问Kepware OPC中的Tag，是直接读写，是很快的，这是我做工程的经验。
OPC是一个标准、开放的IO服务器（等于他们的IO驱动程序），但是OPC可以安装和运行在任何SCADA/HMI系统，当然这些系统必须支持OPC啦，对最终用户是一件好事情，因为他们就不会受限制于这些专用的、封闭的软件系统，如果他们不给你开发一些新的IO驱动程序，你根本不可能把现有的系统连接到一些新的设备或者系统，用户根本就没有办法，只能够忍耐、等待他们大发慈悲给您开发，或者您要付出一笔可观的费用请他们帮您开发IO驱动程序。
此外，这些SCADA/HMI系统都说可以连接OPC，其实，他们只是写了一个OPC的IO驱动程序去连接OPC服务器，做工程时要建立2个数据库：
1)如果您用Kepware OPC服务器，首先您要建立Tag在KepwareOPC服务器中，
2)然后，再利用这些软件的OPC IO驱动程序去连接Kepware OPC中的Tag，把这些Tag连接到自己数据库的Tag。
等于做了两次数据库，比较麻烦！
“创世纪32”GENESIS32的优点是可以直接浏览Kepware中的Tag，马上可以连接到动态图上，不需要再建立Tag才可以连接到动态图，很方便，做工程会节省不少时间，时间就是金钱啊！
有不少人都说OPC很慢，其实他的观点有些不对，由于过去他们只用这些非OPC核心的软件去连接OPC服务器，感觉上动态图的动态点刷新时间会比用他们自己的IO驱动程序慢，问题不是在OPC服务器上，问题是在这种接法而产生的，事实上肯定会慢，动态图的动态点首先从他们自己的OPC IO驱动程序去读/写Kepware OPC的Tag，然后Kepware OPC服务器又去读/写PLC的点，中间就多了一层通信，肯定慢。
但是，“创世纪32”GENESIS32是OPC核心软件，动态图中的动态点直接就访问Kepware OPC中的Tag，是直接读写，是很快的，这是我做工程的经验。
发表于：2007-11-09 14:05:00
22楼
对OPC技术的评价，还是尽量客观些吧，OPC的初衷是统一设备访问接口，提高不同厂商产品之间的互操作性，这一点无疑是正确的。从最初以DA为首的几个规范标准看，其思想、架构都比较符合工业控制领域数据通信的特点。不过值得商榷的是它的通信基础。这有一定的历史原因，如果有人在90年代初，甚至80年代就开始制订这个标准，而不是几乎被MS统治一切的90年代中后期，那么我们所采用的可能就是一个基于更成熟、开放的协议（比如TCP/IP）的标准。那样的话，OLE/COM的局限性与不足就不会对OPC标准产生负面影响。实际上，OPC基金会这两年力推的OPC UA架构，可以被认为是对之前标准的一个反思。至于这期间推出的DX、CPX等，感觉是为了定标准而定标准，已脱离了实际。
所以说，OPC还是一个发展中的技术，远谈不上成熟，将来走向何处，也应冷静看待。前面有几位精通OPC的朋友，对OPC有看法，个人认为并不矛盾，正因为了解，所以知其不足。至于可能是出于商业目的的评价，无论是吹捧还是贬低，都是不可取的。
所以说，OPC还是一个发展中的技术，远谈不上成熟，将来走向何处，也应冷静看待。前面有几位精通OPC的朋友，对OPC有看法，个人认为并不矛盾，正因为了解，所以知其不足。至于可能是出于商业目的的评价，无论是吹捧还是贬低，都是不可取的。
发表于：2007-11-09 14:38:00
23楼
回归主题，讨论OPC的通信速度。DCOM底层基于TCP/IP协议，经过proxy/stub的列集/散集，与纯粹建立在TCP/IP协议上的通讯程序比起来，时间消耗肯定是有的。当然了，通常情况下，这点滞后我们是感觉不到的，对于时间精度一般为秒级，至多百毫秒级的应用来说，性能方面OPC完全能够胜任。（OPC基金会早在98年就弄了一个whitepaper出来阐述OPC的效率、吞吐量等，感兴趣的朋友可以看看）
至于楼主所说的OPC速度，我想确切地说是HMI/SCADA等应用软件对OPC服务器的访问效率问题。GEN32这个软件完全基于OPC，在OPC的连接效率优化处理方面，肯定有独到之处，至少从表面看，它并没有一个独立的实时数据服务器，OPC数据采集后直接在HMI软件进程内处理。但这并不能确定GEN32内部有没有建立一个“内存”数据库，其实从软件设计角度看，应该有。但关键是，这不是影响效率的决定性因素。就像OPC在COM那里的消耗不影响OPC的通信速度一样。
对于GENESIS32, 我从6.1版本就接触过，从纯粹的软件角度看，是个很不错的产品。软件技术方面甚至强于Intouch、IFIX等。（DCS系统软件技术里我推崇DeltaV）
至于楼主所说的OPC速度，我想确切地说是HMI/SCADA等应用软件对OPC服务器的访问效率问题。GEN32这个软件完全基于OPC，在OPC的连接效率优化处理方面，肯定有独到之处，至少从表面看，它并没有一个独立的实时数据服务器，OPC数据采集后直接在HMI软件进程内处理。但这并不能确定GEN32内部有没有建立一个“内存”数据库，其实从软件设计角度看，应该有。但关键是，这不是影响效率的决定性因素。就像OPC在COM那里的消耗不影响OPC的通信速度一样。
对于GENESIS32, 我从6.1版本就接触过，从纯粹的软件角度看，是个很不错的产品。软件技术方面甚至强于Intouch、IFIX等。（DCS系统软件技术里我推崇DeltaV）
发表于：2007-12-27 12:33:00
38楼
To: 通讯网
你说的是对的，
但是我们的话题是说“同一个OPC Server”连接到组态王、力控、InTouch、
iFix、Citect、WinCC等等非OPC核心的软件是比GENESIS32基于OPC为核心
(OPC-To-The-Core)的软件是慢的，理由是这些软件都必须把OPC Server的标签，一个一个连接到自己的标签库中，所以这些软件如果连接OPC Server的时候，肯定是慢。
热门招聘
相关主题
- 求助：OPC客户端对服务器自己...
[2201] - VC Help[1633]
- 那位有OPC .NET API 1.30 SD...[1381]
- OPCServer的注册问题[2505]
- 急求OPC开发的一些文件[1487]
- VC6开发OPC客户端需要哪些文...[1951]
- GE的opc server源码[2339]
- OPC Server XXX CoCreateIn...[1429]
- 那里有opc server 的源程序？...[1375]
- vb.net的OPC通讯[2148]
官方公众号
智造工程师
-
客服
-
小程序
-
公众号
工控网智造工程师好文精选
