关于LabVIEW用于仪器测控的自动测试程序的程序框架的选择问题!

有很长一段时间没有在公众号平台上输出、总结关于LabVIEW的知识文字内容了！

主要是这段时间自己本职工作任务甚为繁重，加上各种家庭事宜的牵绊，耗费了过多的时间和精力，也就无力及时更新了。

今天是端午节假期第二天，这里祝大家端午节安康和顺，并略有一点余暇时间，于是从知乎更新同步一个LabVIEW的问答过来。以此证明本公众号未死，成长更新尚在努力中……。

回到文章题目上：“关于LabVIEW用于仪器（示波器、频谱仪等）测控的自动测试程序的程序框架的选择问题！”

这是一个开放式的问答！

也就是说：从理论上讲，LabVIEW中主流的程序设计框架都可以用以对仪器设备（例如数字多用表、示波器等）的控制上，如何选择开发框架（Framework）主要取决于你的业务领域问题的技术需求，并没有固定的单一标准答案。

如果，只是给你这么一段话的回答，你肯定要骂娘！这TM说了跟没说一样呀！装什么假高深！

下面我结合一下LabVIEW维基百科上“框架设计模式”的范例页面内容，对咱们这个问题场景进行一下简单的范例演绎。

https://labviewwiki.org/wiki/Design_Pattern_Case_Study:_A_Simple_Counter

LabVIEW的设计框架从宜到难的技术发展路线图如下图所示：分别是入门级别的状态机（State Machine）、事件处理（Event Handler），初级级别的主从（Master/Slave）、生产者消费者（Producer/Counsumer）、动作机（Action Engine），中级级别的各种队列消息为主的设计框架（QMH、DQMH），以及高级的多异步通信线程的操作者框架（Actor Framework）。

入门级别的状态机（State Machine）、事件处理（Event Handler）设计框架模式，就是用LabVIEW开发一个小的快速应用程序，完成一些简单的业务功能测量，一般常规的测量功能又可以细分为测试配置，测试采集，数据呈现，结果保存的软件功能模块。

此类框架的特点就是以单一循环线程为主。LabVIEW为此提供一个简单状态机的模板起点，为初学者搭建好的起始点。

LabVIEW维基百科的状态机的设计范例程控框图代码示意。

当业务开发对数据测试采集的实时性有一定特殊要求时，就需要将采集、数据呈现和结果保存进一步细分分解到不同的线程循环当中，入门级别简单的生产者/消费者的两三循环就是更适合的设计模式。

同样的，LabVIEW的新建中也给出相关的空白模板的开发起始点。

但是，往往实际业务开发上，较为复杂的工程程序中，单靠两三个循环是不能覆盖住的！

因此，经典的队列消息处理器模板（QMH，Queued Message Handler）就是不得不上的设计框架。

LabVIEW维基百科的QMH的设计范例程控框图示意。

框架的复杂到了一定程序，面向对象编程的封装、多态可以更好的控制复杂变化，进一步演化出了DQMH和AF（Actor Framework 操作者框架）。关于这方面的相关资料可以看看我的知乎专栏。

综上，开发程序使用哪种设计程序框架，主要是看你的业务场景中的技术特点驱动的！而对仪器设备的程控并不是决定框架的因素。关于框架的选择主要要选择适合的，而不是选择最复杂、显示自己能力牛逼的！这个就是另外一个话题了。

最后，还特别需要注意的一点是，往往程序和硬件程控相关时，则会带来硬件耦合的问题，需要使用IVI可互换驱动，或者使用面向对象编程技术设计硬件抽象层（Headware Abstract Layer）,通过针对抽象层编程，以期获得更大的灵活性和扩展性。

关于数字表测量仪器的硬件抽象层简单入门可以参考下面这篇文章。

https://www.dmcinfo.com/latest-thinking/blog/id/10056/a-simple-hardware-abstraction-using-labview-oop