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，是直接读写，是很快的，这是我做工程的经验。
发表于：2008-02-04 14:53:00
46楼
tcs，你的结论有一定道理，所谓“非OPC核心”组态软件的滞后在理论上是肯定存在的。
但在实际应用中，如果那些“非OPC核心”的组态软件的实现机制是在接收到OPC数据变化消息后，更新它们的实时数据库，然后立即转发给GUI部分的话，那么这个滞后几乎可以忽略不计了。但如果只是更新实时数据库缓冲区，而GUI部分是靠另一套机制定期读取缓冲区并更新的话，那么就可能会出现较明显的滞后。至于目前流行的组态软件在这方面具体的表现到底如何，我没有实际测试比较过，但印象中我接触过的并没有这方面的问题。
不过，关键的问题是，这种滞后是否严重？个人认为对于大多数的过程控制来说，1秒以内都是可以接受的。
但在实际应用中，如果那些“非OPC核心”的组态软件的实现机制是在接收到OPC数据变化消息后，更新它们的实时数据库，然后立即转发给GUI部分的话，那么这个滞后几乎可以忽略不计了。但如果只是更新实时数据库缓冲区，而GUI部分是靠另一套机制定期读取缓冲区并更新的话，那么就可能会出现较明显的滞后。至于目前流行的组态软件在这方面具体的表现到底如何，我没有实际测试比较过，但印象中我接触过的并没有这方面的问题。
不过，关键的问题是，这种滞后是否严重？个人认为对于大多数的过程控制来说，1秒以内都是可以接受的。
热门招聘
相关主题
- 求助：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]
官方公众号
智造工程师
-
客服
-
小程序
-
公众号
工控网智造工程师好文精选
