labview操作者框架

0.引言

操作者框架适合于多并行任务的项目。在这样的项目中，多个并行任务之间往往需要相互通信，传统的解决办法是，每个任务一个队列，一个while循环，多任务项目需要在一个程序框图使用多个while，不好看。NI说使用Actor Framework能够避免锁死，竞争，增大代码重用度。NI官方论坛上有一个例子，写的很好。

     如上图，这是一个反馈式蒸发器，通过不断向室内吹送水蒸气以达到降温目的。它主要由水位传感器，温度传感器，水箱，水阀，水泵，风扇，海绵组成。原理如下：读取水位，水位过低时，打开水阀向水箱中放水；水位过高时关闭水阀。同时，读取室内温度，温度过高时，打开水泵向海绵上抽水，等海绵吸满水后，打开风扇，向室内鼓风，干燥的风经过湿透的海绵，成为温度较低的湿润的风，以此来降低室内温度；温度过低时，关闭水泵。

    项目需求：

1. 控制水位。过低打开水阀，过高时关闭水阀。
2. 控制温度。过高时，打开水泵，等一会，再打开风扇。过低时，关闭水泵。
3. 在界面上显示温度，水泵，风扇状态。
4. 允许在界面上改动温度限制。
5. 系统中总共使用两个风扇，一个坏时另一个自动启用。
6. 系统可以脱离界面运行。

    有点小复杂。

    解决方案：

    系统需要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。

冷却模块（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。

1.创建Timed Loop Controller.class

这个类只需要一个属性：轮询频率。使此类继承Actor.class。

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关闭并且室外温度大于室内温度时，室内温度增加。