LabVIEW在面向对象编程中利用硬件抽象层(HAL)设计2
这部分是< LabVIEW在面向对象编程中利用硬件抽象层(HAL)设计1>的下半部分。
一体化项目
因此，部署为打包库，实际上有多种方法来开发代码:首先，将查看all-in-one项目方法。父类和子类存在于同一个LabVIEW库中。即使使用调色板和构建打包库，开发人员仍然可能不小心选择了错误的类-从打包库中“隐藏”它，将子类设置为private。在一些初始化方法中硬编码子类，命名为Create.vi。
Packed library doesn’t include child classbecause it was private in the development environment
Colors denote difference between parentclass and child class
Development Methods: Separate
Description:
All models within individual libraries
Parent library defines interface
Children inherit from deployed abstract parent
Build new child without parent rebuild
Use a configuration file to select child
Downsides:
Can’t hide child classes
More projects and libraries to maintain
打包库不包括子类，因为它在开发环境中是私有的。颜色表示父类和子类之间的区别。开发方式:单独开发
描述:
单个库中的所有模型
父库定义接口
子节点继承自部署的抽象父节点
构建新的子节点而不需要父节点重建
使用配置文件选择子节点
缺点:
无法隐藏子类
更多的项目和库需要维护
对于这个方法，子类和父类在不同的项目中
• 每个仪器(电源，VNA, DMM等)都有自己的项目/库
• 父类只定义了函数的接口，没有实际的代码
• 子类继承父类的部署版本
• 可以构建子进程，而无需重建父进程
• 某种类型的配置文件将选择适当的子类
• 不能隐藏子类——当开发人员看到正在使用的特定模型时，可能会选择错误的函数
• 在这种情况下，会有更多的项目和库需要维护
独立的项目
这种结构读取仪器配置文件，该文件定义了VISA资源名和子类名，假定子类打包库在父类打包库的旁边，还假定打包库和类名相同。那么，这种方法导致了软件开发中的依赖倒置——子类依赖于父类，而主应用程序只依赖于父类。尽管主应用程序在运行时使用了子类的函数，但在编辑时它只依赖于父类。
在用HAL开发时，会遇到一些问题。比如，如何部署HAL?开发人员如何知道使用哪个函数?为哪些功能创建驱动程序?使用什么输入?以下是使用这么多仪器所面临的一些挑战:
1. 如何部署HAL供开发人员使用?
2. 软件开发人员如何知道使用哪个函数?
3. 需要为哪些功能创建驱动程序?
4. 需要使用什么输入?特别是当它是环形输入时，不同的驱动器有不同的解决方案
矢量网络分析仪(vna)非常复杂，但是，一旦你学会了设置，测量类型就相当容易了。
VNA: Measurement
Channel ≠ Trace
Do all VNAs act this way?
Why make developer track names and pass into all VIs?
Keep the minor details behind the scenes
Software steps for creating a measurement:
• Create trace (after making sureit doesn’t exist)
• Create measurement parameter(after making sure it doesn’t exist)
• Select type of measurement forthe measurement parameter
• Create a measurement channel(does not match channel on screen)
• Assign channel a parameter
• Apply channel to trace
• To make measurement, refer totrace, parameter name, and channel name (tracked by developer)
VNA: Electronic Calibration Module Characterization
ECal Module: precision calibration module for VNA
Characterization requires descriptive inputs
Our (original) approach:
Create a function for each descriptive value
Use all functions to perform a characterization
Copy the code over and over again
Better approach:
Pull low-level functions up (encapsulation)
Path calibration requires a lot of descriptive terms – connector types, ancillary equipment, user name, description, etc.
We created a parent driver for each of the functions to set those values
The extra functions were only used for a calibration
Once we got into multiple-UUT development, we repeatedly copied the code over and over again – seemed crazy to keep doing this
We moved up a level and made the function “Ecal Characterize” input of a cluster of all the relevant information – made much more sense, unfortunately required us to update already completed UUTs
This is the principle of encapsulation – we are hiding low-level details of the specific instrument inner workings so that the developer doesn’t actually screw them up
What about making a change with a bigeffect?
Deprecate
Remove from Palette
Document the removal of support
Have to make an update that affects a lot of already-developed code? Deprecate the function (mark the documentation so user knows not to use for future development)
Remove from palette
Cross out icon – new development shouldn’t use, but not deleted for those already developed
If it doesn’t work, though, that is a different story, you have to make the change for a bug
How generic/specific?
• What is high-level enough thata replacement would work the same way?
• Have I looked at multiplepotential instruments to see commonality?
Am I designing around our measurementneeds? OR am I completely connected tothe current OEM driver?
Are the inputs common for different models?
Do we need all the inputs the driverfunction has?
• Consult programming manual
• OEM driver may contain extracalls that you don’t need, break out what you do (never update the driverdirectly, but copy contents into your VI and edit)
Changing an instrument is probably notcommon and comes with its own set of challenges, therefore:
Is a completely plugin-enabled solutionwith separate projects necessary?
• One bench configuration: oneall-in-one project may be okay
• Multiple configurations:separate projects
• Choose one approach, don’t mix
Is the way this measurement is implementedcommon or specific to this model only?
• Does only my VNA treatchannels, parameters, traces this way or just mine?
Know the impact of changes!
Now a lot of these questions cannot beanswered without experience or without going down the wrong road for a while(or a few years), however it is important to adapt as you go to make theproduct more bullet proof. Who wants toupdate the API for instrumentation in 50 UUT’s test software when an instrumentis changed?
VNA:测量
要进行测量，请参考跟踪、参数名称和通道名称(由开发人员跟踪)。VNA:电子校准模块描述
·ecal模块:VNA精密校准模块，描述需要描述性输入，
(原始)方法:
为每个描述性值创建一个函数
使用所有函数进行描述
一遍又一遍地复制代码
更好的方法:
提升底层功能(封装)
路径校准需要很多描述性术语——连接器类型、辅助设备、用户名、描述等。
为每个函数创建了一个父驱动程序来设置这些值
额外的功能仅用于校准
一旦我们进入多UUT开发，我们就会一遍又一遍地复制代码——继续这样做似乎很疯狂，现在，并使“Ecal Characterize”功能输入所有相关cluster-更有意义。这就是封装的原理——我们隐藏了特定仪器内部工作的底层细节，这样开发人员就不会把它们搞砸了。
现在，如果没有经验或没有走上错误的道路一段时间(或几年)，许多问题都无法回答，但重要的是，你要适应，使产品更加有弹性。当仪器发生变化时，谁想更新50 UUT测试软件中的仪器API ?
需要说明的是，上述的例程和文档，都是可以下载的，双击即可打开，其中压缩文件是可以采用粘贴复制的方式，拷贝到硬盘上。这不是图片，各位小伙伴看到后尝试一下，这个问题就不用加微信咨询了。有关LabVIEW编程、LabVIEW开发等相关项目，可联系们。
