LabVIEW在面向对象编程中利用硬件抽象层(HAL)设计1

LabVIEW面向对象编程(OOP)采用仪器为中心的硬件抽象层(HAL)，使用面向对象的设计模式，可以部署一个仪器重用库，该库可以随着需求和仪器趋势的变化而增长，同时在不可避免的硬件过时中，可以继续使用，避免软件维护成本。

硬件抽象层(HAL)允许测试开发人员在与用户沟通时使用高级功能。通常，OEM开发或定制的仪器驱动程序是特定于某个型号或仪器系列的。对于HAL，底层实现对于顶层的开发人员来说并不重要。该设备可以使用IVI或SCPI，它可以是GPIB，以太网，串口等。HAL不会改变仪器的接口。比如对于电源，希望设置电压并打开输出，作为测试开发人员，并不必关心它是如何发生的。

使用HAL的优点：

不需要依赖于特定的仪器型号

可以轻松地在模拟硬件和实际硬件之间切换

无需重新编译EXE即可更改仪器和软件

使用它的缺点包括：

需要更多的前期设计

需要更多的软件开发来设计好它

对于简单的程序开发来说，似乎就不适用了，但如果想持续提升自身水平，或者项目需要持续升级和维护，那这些缺点不值一提。

DMM是常用的设备，很多厂家都有DMM产品，每一家的功能类似，但程序却不尽相同。

传统方法是使选择结构。这个例子是一个完整的配置、读取、关闭循环，但是如果这些函数分布在代码中，或者当需要添加新设备时该怎么办?开发人员必须找到所有的仪器驱动程序，并添加一个新的案例或替换为新的驱动程序集。

在开发中还会有不同的问题—两个设备之间的配置测量输入不相同。是否需要强制转换以匹配不同的驱动程序集。但是，无需如此操作。

著名的程序员比尔·盖茨，曾经说过，“我选择一个懒惰的人去做艰苦的工作。因为懒人总能找到简单的方法”

回到定义——抽象的工具没有具体的存在。它只是想要执行的实际功能的接口。使用LabVIEW面向对象编程的概念来实现。

父类是抽象的实现——没有真正的功能，只是定义了接口

子类是具体的实现——实现接口的功能并匹配连接器窗格

现在所讨论的大多数仪器都相当简单:电源、DMM等。那复杂的仪器呢?频谱分析仪，矢量网络分析仪?该如何部署HAL使用?如何选择正确的子类?

如LabVIEW开发的射频试验台需要控制众多仪器，包括：

10台电源

2块电表

1台矢量网络分析仪(VNA)

1台频谱分析仪

1 台示波器

1台信号发生器

2台交换机

3 张开关卡

2 台万用表

2台形发生器

涉及众多公司比NI， Keysight，Rohde& Schwarz，Tektronix，Gigatronics等。要实现包括所有这些仪器的自动化测试台架的跨功能、跨公司的开发工作。建立3个测试试验台，使用期限在20年。

那么如何部署HAL?开发人员如何知道使用哪个函数?为哪些功能创建驱动程序?使用什么输入?以下是使用这么多仪器所面临的问题。

1.     如何部署HAL供开发人员使用?

2.     软件开发人员如何知道使用哪个函数?

3.     需要为哪些功能创建驱动程序?

4.     使用什么输入?特别是当它是环形输入时，不同的驱动器有不同的解决方案

通过讨论，发现最好的方法是使用打包的项目库(*.lvlibp)来部署代码——不能意外编辑，并且可以设置为可调试。这就要求做到：

•在项目中创建父工具类并编译

•所有仪器类型继承自父仪器

开发人员不应该使用子对象，那样会破坏整个目的

•创建调色板以确保开发人员使用的是顶级函数

•手动创建调色板文件

•添加到库(不是类)

•构建打包的库

•创建一个部署的调色板，将调色板文件从打包的库中拉出来

•顶级工具使用相同的颜色(蓝色)，所有子类使用相同的颜色(红色)，这样就很容易在代码审查中判断是否使用了不正确的函数

需要说明的是，上述的例程和文档，都是可以下载的，双击即可打开，其中压缩文件是可以采用粘贴复制的方式，拷贝到硬盘上。这不是图片，各位小伙伴看到后尝试一下，这个问题就不用加微信咨询了。有关LabVIEW编程、LabVIEW开发等相关项目，可联系们。

设备有通讯协议，根据协议开发了LabVIEW程序，如下附件所示。

相关资料说明，如下所示。