labview生产者消费者.docx

labview生产者消费者.docx

《labview生产者消费者.docx》由会员分享，可在线阅读，更多相关《labview生产者消费者.docx（17页珍藏版）》请在冰豆网上搜索。

labview生产者消费者

生产者/消费者模式

（1）_前言 

statemice的LabVIEW程序设计模式（五）—生产者/消费者模式

（1）_前言

再次回顾“基本状态机模式”的6个缺点，只剩下第6个缺点无法在上述的“状态机和事件结构的结合模式”中被解决。

（1）    任何时刻只能有一个状态在运行

这个问题也许有些多余，但是在实际的应用中往往又是最常见的。

大多数比较复杂的应用至少应该有“菜单”和“采集”两个状态，如果数据采集程序在运行时仍然希望系统能够处理菜单的事件，这是在传统的状态机或者事件结构中无法实现的。

因为无论是状态机结构还是事件结构，都是由一个循环组成的，不同的状态是无法同时被响应和处理的。

解决这个问题的方式也比较简单，LabVIEW本身就是一种多线程的程序设计语言，可以再加一个循环或者另外开一个程序独立运行。

但是这样也会带来一些新的问题，比如：

（1）    两个循环（程序）之间如何交换和共享数据。

（2）    两个循环（程序）都有着独立的错误处理系统，它们之间是如何协调的。

（3）    两个循环如何分工呢？

应该以哪种方式对状态进行分类以将不同的状态放置在不同的循环（程序）中？

（4）    一个程序如何控制另一个程序的运行和停止。

在上面提出的4个问题中，对循环和程序这两个解决方案而言，第

（1）~（3）个问题的解决方式是一样的。

只有第（4）个问题是专门针对两个程序而言的，在LabVIEW中这种不同程序之间的相互调用称为“程序的动态调用”。

生产者/消费者模式

（2）_VI的可重入性（ReentrantExecution）

statemice的LabVIEW程序设计模式（五）—生产者/消费者模式

（2）_VI的可重入性（ReentrantExecution）

在介绍VI的动态调用之前有必要对LabVIEW在执行VI过程中的规则有个大致的了解。

众所周知，LabVIEW是通过VI的文件名（VIName）来表示独立的VI的，并不是VI的路径。

因此，LabVIEW不允许具有相同名字的VI同时载入内存中，即使这些VI存储在不同的路径中。

在前面曾经提到，LabVIEW本身就是一种多线程设计的语言。

那么当同一背面板中放置两个VI的实例时代码应该如何执行呢？

在图29中，右侧是测试VI运行的时间，左侧是Wait.vi的具体实现代码，仅仅是等待一定的秒数。

那么在右侧的VI中，输出的Time是多少呢？

是3秒还是2秒？

图29ReentrantExecution

打开VI的Highlight调试工具，可以看出两个Wait.vi实例的调用并不是同时执行的，而是依次按顺序执行的，至于哪一个实例先执行是不确定的。

这是由于LabVIEW本身是并行设计的，从理论上而言，两个VI的实例是同步执行的，但是如果两个Wait.vi实例同时执行必定会产生参数赋值紊乱，因为LabVIEW只允许内存中存在一个名称的VI。

因此，此时Time的输出结果是3秒。

如果在实际使用中需要这样的应用该如何解决呢？

LabVIEW提供了VI的可重入技术，打开Wait.vi，单击按键，选择图30所示的Reentrantexecution选项。

此时再次运行Time的输出结果是2秒。

从Highlight的运行过程来看，两个Wait.vi实例是同时执行的，因此总的运行时间就是1秒。

图30VIProperties

事实上，LabVIEW的可重入技术相当于在原有VI的基础上产生了一个相同的副本，打开Wait.vi从标题栏可以看出VI的名称为Wait.vi:

1（clone）。

同理这是由于LabVIEW中不允许内存中的VI存在同名，VI的可重入技术相当于产生了与原VI具有同样功能的新VI并且修改了该VI的命名。

在实际应用中，需要根据情况决定是否设置VI的可重入属性，灵活使用。

并不是需要将所有的VI都设置为可重入，那将占据大量的内存资源。

生产者/消费者模式（3）_LabVIEW程序的动态调用

statemice的LabVIEW程序设计模式（五）—生产者/消费者模式（3）_LabVIEW程序的动态调用

简单而言，动态调用指的是通过程序控制另外一个程序的运行、停止、赋值和获取值等。

LabVIEW提供了多种动态调用的方式，从底层而言是通过VIServer技术实现的。

图31所示为LabVIEW中的ApplicationControl选板，动态调用所使用的节点都位于这个选板。

当调用一个在硬盘、内存甚至是网

络路径上的vi时，首先要使用OpenVIReference以将该VI载入内存并获取VI的“句柄（Reference）”；然后再使用该句柄进行其它的控制操作；最后再关闭该VI的句柄避免内存泄漏，这就完成了一次对VI的调用。

图31ApplicationControl选板

图32是一个动态调用的具体实现代码，首先使用OpenVIReference获取被动态调用VI的Reference（例子中是C:

\average.vi）；再使用CallByReferenceNode节电动态运行该VI；最后关闭VI的Reference。

在使用CallByReferenceNode时需要事先指定被调用VI的输入输出接口，也就是说这种动态调用的前提是必须知道被调用VI的输入输出接口，否则无法进行动态调用。

图32VI的动态调用

OpenVIReference的路径输入是一个多态的输入口，也可以使用String输入，如图33所示。

此时被调用的VI必须在内存中，且输入的是被调用VI的文件名。

值得一提的是这种“文件名”调用方式在可执行程序中是无法被调用的，因此建议最好采用路径的调用方式。

图33OpenVIReference的多态性

【应用5】

本例将使用LabVIEW的动态调用方式实现斐波那契数列（Fibonacci数列）。

斐波那契数列指的是这样一个数列：

1，1，2，3，5，8，13，21……这个数列从第三项开始，每一项都等于前两项之和。

在数学上表述为：

f（n）=f（n-1）+f（n-2），其中n>=3，f

（1）=f

（2）=1。

显然这是一个比较熟悉的递归调用，但是在LabVIEW中似乎很难实现。

由于LabVIEW不允许同名的VI同时在内存中，因此一个

VI是无法VI调用本身的。

但是，通过VI的可重入技术和动态调用技术却可以实现VI的递归调用。

图34所示为Fibonacci数列在LabVIEW中递归的实现方式。

case结构有两个分支，当n<=2时直接输出f（n）=1；当n>=3时，输出f（n）=f（n-1）+f（n-2）。

此时需要把VI设置为可重入状态。

图34Fibonacci数列

同理我们也可以使用这种递归的方式实现f（n）=n!

的算法，从数学上可以写作f（n）=n*f（n-1），其中n>=1，f（0）=1。

具体的实例将不再详述。

此外，递归算法的效率比较低，在实际应用中应谨慎使用。

打开Highlight工具，在CallByReferenceNode运行时，程序是处于等待状态的，只有被调用的VI运行完毕，主程序才会继续执行。

这似乎无法解决在本节开头提到的问题，那么是否存在一种动态调用方式使被调用的VI与主VI之间分别独立运行呢？

答案是肯定的。

VI本身是有很多的属性和方法的，如图35所示。

使用这些方法就可以动态控制VI的运行、停止和赋值，各个属性节点和方法的具体含义见

LabVIEW的帮助文档。

使用这种方式动态调用VI时，并不需要知道VI的输入输出接口。

图35VIMethod

图36是该使用“属性节点和方法”实现动态调用的一个实例。

在大多数应用程序启动时会显示一个启动画面用来显示版权、开发单位、软件版本等信息，等待2秒之后关闭启动界面并启动应用程序主界面。

图中使用了动态调用的方式启动主程序（Main.vi）并使主程序独立运行，首先运行程序后设置2秒钟的延时；其次，将启动画面的界面设置为“隐藏”（并没有退出内存，只是隐藏了前面板），并且使用OpenVIReference获取VI的句柄；然后使用FP.Open属性打开主程序的前面板（只是打开了前面板并没有运行）；使用RunVI方法运行主程序，将WaitUntilDone设置为false，这样就可以保证被调用VI的独立运行；最后，关闭当前VI的前面板。

图36VI的动态调用

通过Highlight工具看出该VI的运行是独立的，并没有等待Main.vi运行结束才继续执行。

生产者/消费者模式（4）_生产者/消费者循环

statemice的LabVIEW程序设计模式（五）—生产者/消费者模式（4）_生产者/消费者循环

本节将使用“多循环”来解决程序并行运行的问题，那么程序中的两个循环如何进行数据交互和共享呢？

最普通的方式是采用全局变量或局域变量，但是当两个循环执行的速率不相等时，必然会造成数据的丢失或重复。

如前所述，LabVIEW提供了队列操作函数，允许数据的发送者和接受者之间建立一条缓冲通道，这样就避免了循环不同步带来的影响。

如图37所示，将整个过程与供水系统进行类比，在数据产生/采集端（供水局）产生数据后，并不直接向终端用户供水，因为前者产生水的速率与后者消耗水的速率并不相同。

此时需要建造蓄水池将供水局产生的水放入到蓄水池中，同理获取的数据也放入该缓冲区中。

当终端用户需要用水时，直接从蓄水池中获取就可以了，同理在进行数据显示和分析时直接从数据缓冲区中获取就可以了。

图37生产者/消费者模型

当然，上面的模型也会存在一个问题：

数据缓冲区/蓄水池的容量？

假定供水局不停地产生自来水，而终端用户却不消耗水，这样便会导致蓄水池装满而溢出。

反之当终端用户耗水量太大时，导致没有水可用。

LabVIEW中的队列函数提供了一种很好的方式规避了这个问题，由于队列中的元素是“先进先出”的，因此确保了接收到的数据是有序的。

在LabVIEW的队列操作中（入列和出列函数），提供了timeout选项以处理数据缓冲区的溢出或不足。

当数据溢出时，入列函数（数据进入队列）将停止发送数据（处于等待状态），直到缓冲区存在数据空间或者达到了timeout设置的时间；而当数据不足时，出列函数（数据流出队列）将停止接收数据（处于等到状态），直到缓冲区进入了新的数据或者达到了timeout设置的时间。

【应用6】

本例将演示生产者/消费者循环的一些基本特性和队列操作的特点。

如图38所示，生产者与消费者之间传递的数据是一个连续的sine波形，二者靠大小为20个点的缓冲区连接。

右下角是“停止”按钮，用户控制程序的停止执行。

例程提供了操作方式控件控制生产者和消费者的数据传递速率，包含五种状态：

不生产，只消费、生成快于消费、生成速率等于消费速率、生成慢于消费、只生产，不消费。

图38生产者/消费者例程的前面板

图39所示为生产者/消费者例程的背面板，代码由3个循环组成，依上而下分别是生产者循环（产生sine数据）、消费者循环（获取sine数据）和状态循环（获得缓存区中数据的数据量）。

例程假定正常的数据发送和接收的速率是延时50ms，当需要某一段的速率减慢时需要将循环的延时设置为100ms。

例程将入列和出列函数的timeout设置为-1，表示如果没有满足条件进行入列和出列操作，循环将处于持续等待状态。

在新建队列时，设置了缓冲区的大小是20个元素（图中的红色圆圈内）。

最下面的循环是为了实时查看队列缓冲区中存储的元素数量。

图39生产者/消费者例程的背面板

运行该VI，默认的操作方式是“生产速率等于消费速率”，从图40中可以看出生产者循环和消费者循环的数据是同步的，此时缓冲区内没有数据，也就是说产生的数据都被实时地消耗了。

图40生产速率等于消费速率

如果再将操作方式设置为“生成快于消费”，可以看出数据缓冲区内将逐渐变满并保持为20个元素。

此时生产者的波形将会比消费者多20个数据点（这些点保存在数据缓冲区中），如图41所示。

图41生产速率高于消费速率

当将操作方式变为“不生产，只消费”时，生产者循环将停止生产，而消费者循环将组件消耗掉缓冲区中的数据直至数据全部消耗完（此时接收到的波形与发送的波形点一致），如图42所示。

图42不生产，只消费

再将操作方式变为“只生产，不消费”，消费者循环将停止消费，而生产者循环将产生数据直至数据缓冲区填满，如图43所示。

图43只生产，不消费

从运行过程来看，借助于timeout的设置，消费者接收的数据始终与生产者发送的数据是一致的，避免点数据点溢出的问题。

当然，在实际使用中需要避免由于

timeout设置为-1而导致的无限等待和死循环。

生产者/消费者模式（5）_生产者/消费者模式扩展

引用

statemice的LabVIEW程序设计模式（五）—生产者/消费者模式（5）_生产者/消费者模式扩展

结合状态机模式、事件结构和动态调用技术，能够归纳出针对较复杂应用程序的通用设计模式。

对常见的测试测量程序而言，主要由数据采集、数据分析、外围菜单项响应、报表生成、数据显示这五个部分组成。

其中数据采集是相对独立和长时间运行的一个模块，可以与其它的模块同时运行。

因此，在大多数持续采集的程序设计中需要将它单独作为一个模块运行。

与此同时，子程序也需要一条数据通道发送一些反馈命令给主程序。

于是可以构成如图44所示的一个通讯回路。

图44通讯回路

LabVIEW提供了多种主程序与子程序之间的通讯方式，如队列、Reference、事件等。

为了介绍这些方式的具体使用方法，将结合最常用的数据采集实例进行阐述。

【应用7】

本例以“计算机组件测试”为应用介绍消费者和生产者循环的具体使用方法和数据交互过程。

例子并不是为了说明计算机组件测试的过程和方法，而是重在强调对该应用而言应该采用什么样的程序设计模式。

因此，例子中使用了多种数据交互方式，这些交互方式的选择并不是唯一的，可以根据实际情况选择合适的数据交互方法。

假设计算机的整个测试过程由CPU、RAM、CDROM、Power….等等数项子测试项组成，程序需要充分考虑可扩展性要求，使得后期增加新的待测组件时对主程序的影响不大或者没有影响。

测试过程应能够实现暂停和提前停止的功能，并且测试过程不受其它界面操作的影响。

根据以上的测试要求，可以把整个测试程序分为两个部分：

控制部分和执行部分。

其中前者是用户主界面，用来响应用户界面事件以及控制测试流程的执行；后者是执行程序，用来根据控制命令运行测试流程并且产生测试结果。

系统的结构如图

45所示。

图45“计算机组件测试系统”结构

从上图可以看出，该应用与消费者和生产者模式是相符的，不同的是还涉及到消费者（执行部分）向生产者（控制部分）的数据传输。

本例使用的是队列型的生产者和消费者模式，而反向的数据传输使用了“用户自定义事件”和“Reference”方法。

当然，也可以使用队列等其它的方式。

程序的主界面如图46所示，包括菜单栏，测试控制按钮和测试项列表3大部分。

背面板如图47所示，生产者部分采用状态机和事件结构相结合的设计模式，共包含5大类的状态。

图46PCTest前面板

图47PCTest背面板

在PInitialize状态中，主要实现前面板控件的初始化以及调用待测组件，如图48所示。

为了满足测试系统的可扩展性要求，将目前的测试组件统一集中放置到TestItems目录中。

如果后续需要增加测试组件项，只需要编写相应的测试组件代码并且放置到TestItems目录中即可。

图48PInitialize状态

在DInitialize、Run、Pause和Stop状态中都使用到了PCTest_Execute_Controller.vi程序，该VI用来启动和控制消费者循环，如图49所示。

图中使用了新建队列函数，并且将该队列和主程序有关控件的Reference通过VIServer方法传递给了消费者循环。

图49PCTest_Execute_Controller.vi

消费者循环采用典型的状态机模式，如图50所示。

使用TestItems字符串记录需要执行的vi的名字（与测试组件相对应），TestIndex表示当前运行的测试项的Index值，该值可以用于记录当前的运行状态以暂停程序的运行。

图50消费者循环

消费者共有3种运行状态：

运行（Run）、暂停（Pause）和停止（Stop），在每一种状态下主程序前面板控件的显示均会有所不同，因此消费者会根据不同的运行状态修改生产者程序前面板上控件的属性（通过Reference）。

图51所示为Run状态的执行代码，程序首先选择当前的测试组件并且调用相应的测试代码；然后将TestIndex加1，不断地调用Run状态直至收到其它的控制指令（如Stop或Pause）或者测试项执行完毕。

图51消费者Run状态

整个程序的退出与其它的设计模式略有不同，其退出流程如图52所示。

关键在于确保消费者循环能够顺利退出，然后再退出生产者循环。

因为消费者的Reference均是来源于生产者，一旦生产者先于消费者退出，则会导致消费者循环报错。

这里重点强调退出的顺序主要是为了避免程序报错和系统资源没有释放。

图52退出流程

在实际应用过程中，可能会遇到更加复杂的情况，如出现多个子程序。

那么主程序与各个子程序之间如何通讯呢？

各个子程序之间又是如何通讯呢？

事实上，只要掌握了队列的用法，这些问题就迎刃而解了。

..