Does it make sense to write a DQMH instr. driver for this case?

[1984]

That is one great presentation, thanks for sharing. Any chance that you can share the source code of the project you used for demonstration? (entirely or partially)

[ChrisFarmerWIS]

Some of that code is owned by a customer.  Which bits specifically were you after?

[1984]

Pretty much everything which is not confidental, but mainly about the classes and their implementations in the DQMH module.

[ChrisFarmerWIS]

I would check out this blog article: HAL in your (D)QMH - DQMH®.  It breaks down how to create the class hierarchy and use it in DQMH really well.

[1984]

I have checked out the videos and articles about making a HAL in DQMH.  (https://wiredinsoftware.com.au/8-reasons-for-encapsulating-your-next-labview-device-driver-inside-a-...) (https://dqmh.org/hal-in-your-dqmh-2/)

Based on these I have created a basic HAL for DMM pretty much by copying the things I've seen in the video. The idea looks promising I'm wondering it's limitations though. Note that this is the first time I create something like this and also I'm not an expert in OOP.

So after the PSU HAL module I've created one for HIPOT. Currently I need to implement only one equipment so the "HAL" will work for sure, but I've already noticed that this equipment has so many commands to make the actual HIPOT test to happen that I found its very unlikely that I could reuse my DQMH module for other testers which makes my HAL completely unreasonable. (cause it not a hal, just an overcomplicated DQMH driver)

Eg: the device I use need to go thru 8-7 atomic configuration steps before I can launch a DCW test. I have started to implement these config steps one by one, each one of them has a DQMH request. By now I assume that its not reasonable cause other testers might need to go thru different configuration steps. (This problem was not as prevalent for the PSU module as PSUs generally have lot less config options)

At this point I assume that my DQMH module (therefore my driver classes) should have a high level "Setup DCW", "Setup ACW" (etc) and a "Start testing" requests with the appropriate parameters instead creating tons of atomic requests.

Could you confirm that this is the right way (or confirm that its the wrong)?

EDIT: to be more precise (hopefully)... what I'm trying to say is that the classes should implement the configuration methods for the given instrument but these atomic config options should not appear as DQMH requests. I assume that the DQMH module should only have high level functionality such as "Set up DCW test". This request should have lots of parameters (eg: ramp up time, test voltage, limits, ground mode etc) and the "Set up DCW test" method for each class should implement the configuration based on these parameters and their atomic configuration methods. (maybe the methods themselves should be private?)

[ChrisFarmerWIS]

Where the OOP HAL works well is when you have a number of similar devices and the class hierarchy makes it easy to switch from one brand of device to another.  The beauty also is that you can create a simulated device (as per my video) so that you can easily run the software offline.

You could go a step further and create a HAL/MAL using LabVIEW 2020+ OOP interfaces feature, but I haven't gone there.

If you're DQMH driver is merely wrapping around every function of your HAL and that's it, then it's hard to argue why you need a DQMH module and instead just use the class directly.  But, again, see my video as to why a DQMH module is a good choice.

I would agree with your last statement of creating DQMH requests like "Setup DCW". This one Setup DCW should only need one MHL case where you then call the one or more class VIs to carry out this setup.

I think at some point you need to make your code specific to your application and try not to be overly generic.  My preference - and some people might do it differently - is to make the DQMH module specific (and keep the class(es) generic). 

Not sure I've answered your question having said all that.

[DavidWilt_J]

From a HAL point of view, yes you need to make the specific atomic methods in your device specific class because as you stated the configuration of the device may be completely different.

[1984]

Ok, so its been a while... I checked those links and they look awesome and based on those I already started to implement HALs for couple devices.

I'm not sure if my next question is HAL or OOP related but here we go: I created a camera HAL which is - at this point - handles only laptop webcams and industrial cameras. I can take images with both, open and close sessions etc. The main difference for now between the webcams and the industrial cams that the latter have tons of settings can be set via IMAQdx property nodes.

In which class should I implement this and generally speaking in which class should I implement features which are existing on certain devices but not on others. Logically I'd say these should be implemented on the instrument specific classes, but if I do that then my DQMH module will be broken. If I implement this on the base class then the base class will be flooded by methods. For now I believe can only implement these on the base class cause otherwise I can't run my DQMH module. 

[ChrisFarmerWIS]

---

In which class should I implement this and generally speaking in which class should I implement features which are existing on certain devices but not on others. Logically I'd say these should be implemented on the instrument specific classes,

In the specific class as you say.

---

but if I do that then my DQMH module will be broken. 

---

Why is it broken? Can you elaborate?

---

For now I believe can only implement these on the base class cause otherwise I can't run my DQMH module. 

---

Typically the base class doesn't actually do anything, it just provides the template to be overridden by the child classes.  Unless the function is always going to be the same no matter which child class is in use.

[drjdpowell]

---

@1984 wrote:

Logically I'd say these should be implemented on the instrument specific classes, but if I do that then my DQMH module will be broken. If I implement this on the base class then the base class will be flooded by methods. For now I believe can only implement these on the base class cause otherwise I can't run my DQMH module. 

---

Common base-class methods I use include "Get Configuration as JSON", "Set Configuration from JSON", and "Show Configuration Dialog".  With these I can initialize with any child class (even a dynamically loaded one), allow the User to adjust child-specific parameters, and save the altered configuration to disk, all with no child-parameter methods in the base class at all.