0.引言
操作者框架适合于多并行任务的项目。在这样的项目中,多个并行任务之间往往需要相互通信,传统的解决办法是,每个任务一个队列,一个while循环,多任务项目需要在一个程序框图使用多个while,不好看。NI说使用Actor Framework能够避免锁死,竞争,增大代码重用度。NI官方论坛上有一个例子,写的很好。
![labview操作者框架_第1张图片](http://img.e-com-net.com/image/info8/1054985239e240dc9de5f02322c3cb1d.jpg)
如上图,这是一个反馈式蒸发器,通过不断向室内吹送水蒸气以达到降温目的。它主要由水位传感器,温度传感器,水箱,水阀,水泵,风扇,海绵组成。原理如下:读取水位,水位过低时,打开水阀向水箱中放水;水位过高时关闭水阀。同时,读取室内温度,温度过高时,打开水泵向海绵上抽水,等海绵吸满水后,打开风扇,向室内鼓风,干燥的风经过湿透的海绵,成为温度较低的湿润的风,以此来降低室内温度;温度过低时,关闭水泵。
项目需求:
- 控制水位。过低打开水阀,过高时关闭水阀。
- 控制温度。过高时,打开水泵,等一会,再打开风扇。过低时,关闭水泵。
- 在界面上显示温度,水泵,风扇状态。
- 允许在界面上改动温度限制。
- 系统中总共使用两个风扇,一个坏时另一个自动启用。
- 系统可以脱离界面运行。
有点小复杂。
解决方案:
系统需要4个模块:
UI(Cooler UI with Events.lvclass) ;
冷却模块(Cooler.lvclass));
水位控制模块(Water Level.lvclass);
风扇控制模块(Dual Fan.lvclass)。
其中冷却模块是主模块,与风扇控制模块和水位控制模块组合关系,和UI模块是关联关系。(PS:Cooler需要负责Dual Fan和Water Level的启动和释放,Cool通过动态事件和Cooler Panel交互),每个模块为一个Actor。
![labview操作者框架_第2张图片](http://img.e-com-net.com/image/info8/f92b397386fb410399977d4d07390e60.png)
冷却模块(Cooler.lvclass)),水位控制模块(Water Level.lvclass),风扇控制模块(Dual Fan.lvclass)都需要轮询,Dual Fan轮询有没有风扇坏掉了,Water Level轮询水位,Cooler轮询温度。所以写个Timed Loop Controller.lvclass,哪个操作者需轮询要直接从它继承就可以了。继承使代码复用度提高了。
同理,水位控制模块(Water Level.lvclass),风扇控制模块(Dual Fan.lvclass)还有相似的逻辑——超过限位就打开或关闭。写个Level Controller.lvclass作为这两个操作者的父类,因为labview中一个孩子只能有一个父亲,所以Level Controller.lvclass需要继承自Timed Loop Controller.lvclass。
![labview操作者框架_第3张图片](http://img.e-com-net.com/image/info8/04244430ccb041e99d5e85c39df29305.jpg)
1.创建Timed Loop Controller.class
这个类只需要一个属性:轮询频率。使此类继承Actor.class。
![labview操作者框架_第4张图片](http://img.e-com-net.com/image/info8/bbeafb87b61646fb8b8a7f250183965c.png)
![]()
1.1 Actor Core.vi
父类actor.class中的
Actor Core.vi被重写,父类actor.class中的Actor Core.vi中有一个状态机,
当它收到停止消息时,就会退出,之后局部变量stop?为真,不在发送update消息。
1.2 Update.vi
此vi是空的,留给子类重写。
2. 创建Level Controller.class
Cooler actors 和Water Level actors的逻辑是一样的,都是超过限位就打开或者关闭。所以创建此类作为这两个类的父类,以增大代码重用度。
这个类需要三个属性:高限位,低限位,这两个作为输入;另外还需要保存输出的值:高,低,不变。
State Logic.vi是要复用的逻辑,Level Controller肯定要先从硬件读取输入,然后在进行逻辑操作,最后输出结果,输入和输出是和硬件有关系的,但是硬件不同,故读取功能的代码和输出功能的代码肯定不一样,为了使软件可扩展性更好,所以将输入get new level.vi和输出set output state.vi作为虚函数(就是明知程序中必须有,但是又不能写在此类中),这样更换硬件时,我们只需从此类继承,并重写输入输出vi即可。另外,此类重写了Update.vi。
重写的update会以固定间隔运行。
3. 创建 Water Level.class
Water Level是一个具体类,继承自Level Controller。前面的Level Controller和Time Loop Controller是虚类,类似于c++中的虚类,不能够实例化对象,labview虽然没有这个规定,但这样做没什么意义。
labview中,虚类负责逻辑设计,具体类(子孙类)负责具体的输入输出,和具体的硬件相关,这样带来的好处是,硬件更换时,只需要从虚类继承那些已经被设计好的逻辑,重写那些输入输出等和硬件有关的vi即可。
输入输出,可以由全局变量来模拟。这样会使测试软件时会方便很多。有人把它叫做HAL,即
hardware abstraction layer
虚拟硬件层,瞬间高大上(⊙o⊙)…。HAL是继承父类的具体类,运行时就能够检验软件逻辑有没有错误。在设计是,最好设计个HAL,以方便调试。
这里面的Water Level就是HAL。
其中输入输出都是用的全局变量来模拟的。
Get New Level.vi:
Set Output State.vi:
写好后就可以测试了。
4. 创建Dual Fan.class
Dual Fan 是继承自Timed Loop Controller的具体类。
属性为两个风扇的状态:打开或关闭,正常或故障。
为了让其他操作者能够打开或关闭风扇,需要为Power Off.vi和Power On.vi创建消息。当一个风扇故障时需要打开另一个,所以需要轮询风扇是否故障,这个功能通过重写父类Update.vi实现。
完成后可对本类进行测试:
5. 创建Cooler.class
Cooler继承自Level Controller的具体类。Water Level和Dual Fan组合成了Cooler,所以要负责这两个操作者的启动和关闭。
Get New Level.vi不用说,还是从全局变量中读取模拟的温度值。之后是逻辑处理,父类已经写好,不用操心这部分,之后就是输出Set Output State.vi:
这里的代码解释了为什么要将Dual Fan队列的引用类型和Run Fan Delivery Notifier放到本类的私有数据中——因为他要根据温度值,控制风扇的打开和关闭,有Dual Fan队列的引用,直接向这个队列发送消息即可。由于pump打开后,需要等一段时间来让水充满海绵,所以需要使用Run-Delayed Send Message.vi,因为风扇关闭后此通知器就不用了,所以需要释放。
Dual Fan队列和Water Level放到本类的私有队列中还有一个原因,那就是我们想Cooler关闭时,Dual Fan和Water Level也必须关闭(也有其他办法,在Cool的Actor Core中启动Dual Fan和Water Level时,获取他们的消息队列,然后创建一个和调用父方法并行的while,停止Cooler时,在这个while中向Dual Fan和Water Level发送停止信号,这个需要添加一个while循环),简单的办法是:
6. 操作者框架的优点
1.轮询代码(Timed Loop Controller)重用了3次,限位代码(Level Controller)重用了3次。
2.不用自己往消息队列添加消息了。而是使用的封装好的Send XXX msg.vi。
3.程序面板中while没那么多了。
7. 创建User Interface.class
到此,还有两个功能没有实现:
1.显示内部温度,水泵状态,风扇状态;
2.允许用户改变温度限制。允许Cooler脱离界面运行。
最健壮的解决方案是,将UI和消息传递部分分开,这样就减弱了Cooler和Cooler Panel的耦合,可以更灵活的更改界面。类似于MVC(model,view,control)——这里是将V和C分开了。
为了使软件有最大的灵活度,还要创建一个abstract user interface layer,AUIL,虚的用户界面。AUIL包括了UI类支持的所有消息和应该包含的公共代码。Cooler将能够向AUIL的任何子类发送状态消息。
8. 创建Cooler UI with Events.class
这个Actor操作者就是AUIL,虚类
Cooler UI with Events。
当然首先Cooler UI with Events要继承自Actor。
Cooler UI with Events将会从Cooler操作者中接收消息,然后这些消息会被此类转化为用户事件user events,最后由本类的事件结构处理。此类的所有子类都会注册这些事件,当子类接收到消息时,会更新前面板——UI。
先看它的私有数据:
下面是这个库是这部分的所有功能。这里面Cooler UI with Events包括了所有功能,除了显示。为了使系统整容更方便,这里使用Cooler Panel这个子类来负责颜值部分。当审美疲劳时,随时可以通过继承Cooler UI with Events获得新的面目。
1.重写
Pre Launch Init.vi。
创建三个用户事件,分别用来更新风扇状态,温度和水泵。这里的Events就是本类私有数据的Events。私有数据中还有一个
,主要是为了向Cooler发消息,如果只是为了显示,就不用添加Cooler这个队列了,直接执行动态事件就可以了。添加Cooler这个队列,就是为了向Cooler发送命令。
Send Write Deadband的错误接线没有输出,
因为
如果想单独测试UI或UI启动但Cooler没启动时,Send Write Deadband有可能会输出错误,这个不太好。什么时候要连错误输出什么时候不要连错误输出,要按照情况来定。上面已经说了UI怎么向Cooler发命令,下面再讲Cooler怎么向UI发命令。
2.
Update Fan.vi。
3.创建消息:
a. Change Desired Temperature
b. Update Fan
c. Update Pump
d. Update Temperature
e. Write Cooler
这些消息就是为了让其他Actor操作本Actor。
9. 修改Cooler.class
原来设计的Cooler,是自己运行,他并不会将自己状态告诉UI,你不告诉人家,人家怎么知道。
修改办法:Cooler中所有涉及风扇状态,水泵状态,温度改变的vi都要向UI通知。
1.
Cooler.lvclass:Get New Level.vi。读取温度后通知UI。这里不将Send Update Temperature的错误输出连接到error out,是为了程序在没有UI的时候也能正常运行。
2.
Set Output State.vi。设置读取后温度,经逻辑处理,输出为水泵的状态。也要通知给UI。Send Update Pump的错误输出端也没有连,原因你懂的。
3.
Update Fan Status.vi。更新风扇状态。这个有点小曲折。因为UI和Cooler平起平坐(关联),Dual Fan是由Cooler启动的,Dual Fan和UI之间没法交流。所以只好在Cooler中写个public的Update Fan Status.vi,并为他创建消息,这样Dual Fan的状态就会通过Cooler传给UI。也就是Dual Fan状态改变时,要先给Cooler发消息,由于Cooler知道UI的队列,Cooler收到消息后会向UI发消息。
4.前面都是修改Cooler类,现在轮到
Dual Fan类了。
a.
Dual Fan.lvclass:Post Update.vi。这里使用了Read Caller Enqueer.vi,读取调用者Cooler的消息队列,Cooler收到消息后会调用Update Fan.vi,这个vi将向Cooler Pannel发送用户事件来更新UI。这样,就可以通过多次调用Post Update.vi来更新UI。
b.在
Power On.vi, Power Off.vi和Update.vi更新UI。
Power On.vi:
Power Off.vi:
Update.vi:
10. 创建颜值担当Cooler Panel.class
Cooler Panel只负责UI交互。
直接来:
创建要和Actor状态机并行运行的的while时,一般会采用这种伎俩。为了在适当的时候,停止和Actor状态机并行运行的的while,这里使用了再次使用了用户事件。Timed Loop Controller中停止和Actor状态机并行运行的的while的方法,是Actor状态机执行完毕后,局部变量布尔开关变为false,导致while停止。上图这种是需要在界面上人为控制系统停止才使用的
,当然也可以使用其他办法,如队列,信号值什么的,但NI建议只使用一种
,所以UI部分已经使用了用户事件,这里也使用用户事件来做
。至此UI和Cooler全部完成,只需将他们启动了。
11. 创建Application Launcher.class
这个启动者的名字叫
Feedback Evaporative Cooler Demo.vi。
12. 软件测试
如果风扇A打开或风扇B打开或室外温度小于室内温度时,室内温度减小。
如果风扇A关闭并且风扇B关闭并且室外温度大于室内温度时,室内温度增加。