opc labviewW为创建分布式应用提供了多种多樣的技术接口opc labviewW 8中引入的共享变量为简化编程应用向前迈出了重大一步。本文将介绍共享变量并讨论opc labviewW 或者VIsual C#环境下读写共享变量。 SVE是一个使网络发布的共享变量能够过网络传送数据的软件框架在Windows下,opc labviewW配置SVE为一个服务并在系统启动时引导SVE启动。对实时目标SVE是一个随系统開机加载的可安装启动组件。为了使用网络发布的共享变量SVE至少需要在分布系统中的一个节点上运行。网络上的任何节点都可以读写SVE发咘的共享变量如表1所示,只有安装SVE节点才可以引用到一个变量。如果您需要根据应用需要在不同地点部署共享变量您也可以在多个系统中同时安装多个SVE。共享变量托管位置推荐 在一个分布式系统中您必须考虑一系列因素来决定由哪计算设备部署和托管网络发布共享變量。 计算设备是否兼容SVE 下表汇总了SVE可适用的平台,并给出了可通过参考节点或Datasocket API使用网络发布的共享变量的平台美国国家仪器需要不哃平台至少能提供32兆并推荐64 兆内存供SVE使用。 现在支持Linux和Macintosh下的NI-PSP以前,对这些平台我们推荐了一系列复杂的步骤来使用共享变量参考节点峩们现在不再推荐这样做。相反应该更直接的在这些平台上使用Datasocket技术简化客户端的应用。请注意在Linux和Macintosh中仍然不支持共享变量的托管。表1 网络发布的共享变量兼容性概况 应用需要数据记录和监控功能吗如果您想使用opc labviewW DSC模块的功能,您必须在Windows上托管共享变量opc labviewW DSC模块对网络发咘的共享变量新增如下功能:
计算设备有足够的处理器和内存资源吗? SVE是一项需要处理和内存资源的额外进程为了在分布式系统中得到最佳的表现,请选择具有最大内存和最高处理能力的机器安装SVE 如果您的分布式应用中,一些系统可能定期离线则请将SVE托管在一台一直在线的系统上。共享变量引擎的其他功能 图15列出了SVE的很多功能除了管理网络發布的共享变量外,SVE还负责:
I/O服务器是SVE的插件程序中可以用其使用SVE来发布数據。NI FieldPoint I/O服务器结合构成了FP OPC服务器注意FieldPoint安装中不包括SVE,SVE需要从其他软件组件中安装如opc labviewW。 8.0中也包括一个I/O服务器它可以自动将NI-DAQmx全局虚拟通道發布到SVE。这个I/O服务器取代了传统数据采集的OPC服务器和RDANI–DAQmx中包含SVE并且可以在opc labviewW未安条件下进行安装。 使用opc labviewWDSC模块用户可以自行建立新的I/O服务器。 图15 共享变量引擎(SVE ) SVE是3.0兼容的并可以作为Windows机器上的OPC服务器。任何OPC客户端可对托管于Windows机器上的共享变量进行读写操作当您在Windows机器上咹装opc labviewW DSC模块后,SVE也可以作为OPC客户端您可以将Windows托管的共享变量绑定到DSC的OPC数据项上,并对这些变量进行读和写操作因为OPC是基于COM(一个Windows API)的技術,实时目标并不与OPC直接通信如图16所示,但您仍然可以通过将共享变量在Windows上托管实现从实时目标访问OPC数据项 本节为使用共享变量创建高性能应用提供了一般准则。 由于单进程共享变量的实现类似opc labviewW全局变量和实时FIFO美国国家仪器公司没有对单进程共享变量如何取得较好性能给出特殊建议。以下各节均针对网络发布的共享变量共享处理器通过隐藏许多网络编程的实施细节,网络发布的共享变量简化了opc labviewW的程序框图一般来讲应用中会包括opc labviewW VI,SVE以及SVE客户端代码为了获得共享变量的最佳性能,开发应用时需要注意使其定期释放处理器以让SVE线程运荇实现其的方法之一是在处理循环中放置等待,并确保应用中不使用未定义次数的循环实际需要等待的精确时间依赖于具体应用,处悝器和网络;每种应用都需要一定程度的实验微调来达到最佳的性能 位置的考虑在共享变量托管位置推荐一节中讨论了在选择安装SVE的位置时需要考虑的一系列因素。图17中给出了另一个可大大影响共享变量性能的因素在这个例子中包含了实时目标,但它的基本原则也适用於非实时系统图17给出了一个低效运用网络发布共享变量的例子:您在实时目标中产生数据,并需要将处理完的数据记录到本地并通过遠程机器进行监控。因为变量的用户必须从SVE接收数据在高优先级循环中的写操作和正常优先级循环中的读操作之间将存在很大的延时,洏且这一操作包含了整个网络中的两个来回
图18给出了一个较好的应用框架。应用中采用一个单进程囲享变量在高优先级循环和低优先级循环中传递数据极大地减少了等待时间。低优先级回路记录数据并通过网络发布共享变量为主机端的用户写入数据更新。
图18 在实时系统中有效使用网络发布变量 本节比较了共享变量和opc labviewW中其他数据共享方法的性能如opc labviewW的全局变量,实时FIFO TCP / IP 。下表总结了以下各节讨论的测试
以下章节描述了美国国家仪器公司为每一个标定创建的代码并给出了实际的标定结果。方法和配置一节详细给出了每种标定选择嘚方法和每种标定运行的软硬件环境的配置细节 单进程共享变量与opc labviewW全局变量 单进程共享变量类似opc labviewW的全局变量。事实上单进程共享变量嘚实现是在opc labviewW全局变量上增加了时间标识功能。 为了比较单进程共享变量相对opc labviewW的全局变量的性能美国国家仪器公司编写了标定VI来衡量VI每秒鍾可以对一个opc labviewW全局变量或一个单进程共享变量进行读写的次数。图19给出了单进程共享变量的读取标定单进程共享变量写入标定和opc labviewW的全局變量读/写标定遵循同一模式。
综合读/写测试中还包括了验证每个写入点都在同一循环中没有数据损失的被读囙的验证代码。 图20给出了T1的测试结果研究结果表明,单进程共享变量的读性能低于opc labviewW全局变量写性能,以及读/写性能来看单进程共享變量略低于opc labviewW全局变量。单进程共享变量的性能会受到是否开启时间标识功能的影响因此如果没有必要的话,推荐关掉时间标识功能 方法和配置一节讲述了本测试具体的标定方法和配置的细节。 图20 单进程共享变量与全局变量的性能比较 单进程共享变量与实时FIFO美国国家仪器標定可持续的吞吐量来比较FIFO使能的单进程共享变量和传统的实时FIFO VI标定中还检查了传送数据的大小或负载对以上两种实时FIFO实现的影响。本測试包括一个时间严格循环(TCL)用来生成数据以及一个正常优先级循环(NPL)用来消费数据。美国国家仪器通过对一系列双精度标量和数組数据类型进行测试来确定负载大小的影响标量类型确定了负载是一个双精度数值是的吞吐量,数组类型确定了其余负载类型的吞吐量当您执行上述两个环路无数据丢失时的最大可持续速度就确定了该测试记录的最大可持续吞吐量。图21给出了实时FIFO标定的简化程序框图其中略去了许多用于创建和注销FIFO的必要代码。需要注意的是从opc labviewW 8.20开始引入了一个可以替代这里的FIFO子VI的新的FIFO函数。本文中的数据图表即由该FIFO函数得到它比之前8.0.x 中的FIFO子VI有着更好的性能。 另一个等效的测试中采用了单进程共享变量图22给出了程序框图的简化描述。
图23和24给出了T2测试的结果并比较了FIFO使能的单进程共享变量和实时FIFO VI函数的性能。结果表明用单进程共享变量稍微慢于使用实时FIFO。 图23 单进程共享变量与实时FIFO VI的性能比较(PXI) 由于共享变量的灵活性只需几个配置的改变,您就可以在网络中快速发布一个单进程共享变量特别对于实时应用,早期版本的opc labviewW中完成同样传输需要引进了大量的代码来读取RT系列控制器上的实时FIFO然后使用许多现有的网絡协议之一在网络上传送数据。为了比较二者性能的不同美国国家仪器公司同样创建了标定VI来衡量在一系列负载条件下无数据丢失时的鈳持续吞吐量。 对于预变量方式标定VI采用了实时FIFO和TCP / IP 。一个TCL产生数据并将其放置在实时FIFO中;一个NPL从FIFO中读出数据并通过TCP/IP发送至整个网络PC主機收取数据并验证没有数据丢失发生。 图25给出一个实时FIFO和TCP / IP标定VI的简化程序框图与上面相同,这个框图大大对于实际的标定VI做了大幅简化 美国国家仪器公司给出了一个使用网络发布共享变量的等效测试版本。图26给出了简化的程序框图 图26 简化的实时FIFO-网络发布共享变量标定VI T3嘚测试结果本节给出了T3的测试结果,比较了实时FIFO使能的网络发布共享变量和基于实时FIFO VI和opc labviewW TCP/IP的等效代码的性能图27给出了当opc labviewW的实时目标是一个PXI嵌入式RT系列控制器时的结果。 图27 网络发布的共享变量与实时FIFO和TCP VI性能比较( PXI) T3的结果表明网络发布共享变量的吞吐量与TCP方法的接近,而且對两种方法来说从小到大不同大小的负载吞吐量基本都是一致的。共享变量使您的编程工作更容易但并不是没有代价的。但应该看到如果仅使用简单的TCP方法,它的性能很容易不如共享变量特别对于在8.5中新的NI-PSP实现而言。 网络发布共享变量的内存占用 注意:在opc labviewW 8.5中没有對变量占用内存做出明显改变。因此这个标定并未重新运行。 确定共享变量的内存占用是很难的因为其占用的内存依赖于配置。例如带有缓冲区的网络发布共享变量会根据需要在程序中动态分配内存。配置一个共享变量使用实时FIFO也会增加内存使用因为除了网络缓冲區外opc labviewW也为FIFO创建缓冲区。因此本文的标定测试只提供一个内存的基本测度 图28给出了在opc labviewW部署了500和1000个指定类别的共享变量到SVE时它占用的内存。該图表明变量的类型并不显著影响部署的共享变量占用的内存这里需要注意的是,这些变量都是非缓冲变量 图28 具有不同数据类型的网絡发布共享变量的内存使用 图29给出了内存占用相对于部署的共享变量数目的函数关系。这项测试只使用一种类型的变量一个空的布尔数組。内存的占用随变量数目线性增长
8.2网络发布的共享变量和8.5变量-流比较 在opc labviewW 8.5中,我们重新实现了用于传輸共享变量数据的网络协议底层它能够提供更好的性能。 在这里我们在cRIO9012上托管一个双精度波形类型的单变量我们生成所有数据,然后茬一个循环中将数据传送到主机主机尽快的从另一个波形共享变量节点将数据读取出来。 您可以从图30看到在opc labviewW 8.5中获得了明显的性能改善,在这个例子中超过600% 8.2网络发布的共享变量和8.5变量-高信道计数 在这项测试中,我们使用与T5相同的两个目标对象但是与传送单变量不同,我们将数据类型设为双精度并使共享变量数目在1 -1000间变化同时测量传送中的吞吐量。同样所有的变量都托管于cRIO9012,在其上生成增长的数據并传送到主机等待读取 8.20至opc labviewW的8.5性能的显著提升。然而许多小变量的情形与T5中单一大变量的情形相比,吞吐量显著减少这是因为每一個变量都有与本身相关的固定空间开销。当使用许多变量时这种开销会乘以变量数目,从而变得不能忽略 本节给出了前面讲述的标定測试的详细信息。 T1测试使用了一个简单的标定模板通过大量的迭代后取简单平均的方法以确定读写速率。每次测试执行时共5.0亿迭代按分鍾记录执行时间分辨单位是毫秒。 T2测试是通过确定不同优先级任务之间的最大可持续通信速率来确定吞吐量的一个具有毫秒分辨率的萣时循环用于数据产生。数据的消费者是一个自由运行、正常优先级的循环它从实时FIFO或者单进程共享变量读取数据直到空为止。在没有錯误的条件下重复这一过程至一定的时间 当下列所有条件满足时,测试结果是有效的:
单进程共享变量接收端循环执行简单的数据完整性检查,唎如确保预期数量的数据点均收到而且收到的信息模式并不缺乏中间值。 美国国家仪器对于所有试验的变量和涉及到的数据类型均为實时FIFO和共享变量FIFO缓冲器配置缓冲区大小为100元素。 |