Test equipment as objects using classes & inheritances

[WavePacket]

Hi all,

First post, hopefully this is in the right place.

I'm curious if someone worked out a generally accepted as good practice design for test equipment as general objects using LabVIEW classes & inheritances. I'm coming up on multiple projects which could benefit from object orientated design, and if such work has already been done I'd like to "inherit" (🙄) that.

The first project that I'll be doing involves an optical spectrum analyzer (OSA). I'll have a specific brand OSA, but I'd like to write a general OSA class which all OSAs inherit from. As a further example of what could be done, an OSA can function as an optical power meter by integrating its spectra. Potentially that could be an interface between a general power meter class and a general OSA class.

So my question is, has someone already worked out the general classes for common equipment? I'm aware of IVI which has done some conceptual similar drivers, but I'm not sure whether that is what I'm trying to do here.

Thanks

[santo_13]

I believe you are trying to create a Hardware Abstraction Layer using Classes. Yes, classes are the right way to implement HAL and many of us have implemented those as per the needs but I am not aware of something that is open and free to share.

And yes, IVI is in a way HAL enforced by the IVI foundation.

https://www.ni.com/en/shop/pxi/don-t-let-obsolescence-cause-your-test-system-to-flatline/addressing-...

https://www.ni.com/en/shop/labview/introduction-to-oop-and-hardware-abstraction-layers.html

https://www.ni.com/en/shop/pxi/don-t-let-obsolescence-cause-your-test-system-to-flatline/the-ni-inst...

[WavePacket]

Thanks, I believe that HAL is what I'm pursuing. A follow up question if you don't mind. Your first link led me the pdf titled mitigate_hw_obsolescence.pdf attached here: https://forums.ni.com/t5/Example-Code/How-to-Mitigate-Hardware-Obsolescence-in-Next-Generation-Test/...

That pdf goes through an example HAL, and on pg 10 they show the class hierchy. It seems that a main "DSSP" base class from which multiple instruments classes are derived. I'm confused as to why this main DSSP class needs to be present. Don't we achive interchangeable hardware with just the measurement-based classes?

Maybe I'm missing something.

[santo_13]

You can achieve HAL even without DSSP, it is just an idea proposed and it is up to you to decide whether your application requires such a structure.

You would need to weigh the advantages and complexity of HAL vs MAL

[WavePacket]

Huh, I haven't heard of a MAL before. Happen to have ay references for that?

[santo_13]

MAL is discussed in the third link I posted. Here is the guide from that link https://download.ni.com/evaluation/coretest/HAL_MAL_Web.pdf

[WavePacket]

Thanks, I've read it. I think I've mapped the concepts of HAL/MAL to my specific task at hand. If you wouldn't mind, have I applied these concepts right?

1. I download NI drivers for a specific OSA, these drivers are really just VIs wrapping VISA commands
2. I place these specific driver VIs as methods of a class created for the specific OSA
3. The specific OSA class then inherits from a general OSA class
4. In my main test code, I only call methods of the general OSA class, and which specific OSA is loaded comes either from a config file, or a drop-down menu at runtime.

So, if I'm understanding things correctly the HAL is 1., and the MAL is 2 through 4?

[santo_13 · Accepted solution]

All your points relate to only HAL.

MAL comes into the picture when you create measurement automation which is agnostic of the instrument type and focuses only on what to measure.

For example, you want to measure a voltage on a DUT, in this case, you would implement measurement automation using a DMM parent class and call it a day. Now your automation is abstracted from DMM model changes by HAL.

What if, you couldn't find a DMM, all that you've is a DAQ, now you would need to go into your automation and change all the code to use DAQ parent class. If you have implemented a MAL, your code will be directly compatible with DAQ too. If you think about it, DMM measures a voltage and so does a DAQ, both can do the voltage measurement (of course accuracy, range varies). This way, voltage measurement can be abstracted into MAL.

[crossrulz · Accepted solution]

---

@WavePacket wrote:

So, if I'm understanding things correctly the HAL is 1., and the MAL is 2 through 4?

---

Technically, 2 though 4 is the HAL.  1 is just a low lever driver.  A MAL would be a "Read Spectrum" class that uses whatever instrument is required to take that measurement, whether it is an OSA, oscilloscope, etc.  But this is all semantics.

Personally, I have not found a good way to actually do a MAL.  So I would not worry too much about that.

[WavePacket]

Ok, I'm understanding more. 1 through 4 are the HAL. 

Would an example of a MAL in LabVIEW then be an "interface" introduced in 2020 https://labviewwiki.org/wiki/LabVIEW_Interface#:~:text=LabVIEW%20Interface%20is%20a%20kind,methods%2....

Using the example mentioned above of measuring a voltage on a DUT with both a DMM and a DAQ, we could create a parent/general class for both DMM instruments and DAQ instruments for the HAL. Then, have both DMM and DAQ inherit from a "measure voltage" or similar "interface." In my ATE I would only call the interface. Since both DMM and DAQ parent/general class inherit the interface measure voltage, I wouldn't have to change the test code.

That the idea for a MAL in LabVIEW?