Related modules

[Mads]

I'm using several DQMH singletons as "module managers" (or Controller, if we use the term from the Thermal chamber demo), where each manager has the responibility of creating, initializing, reinitializing and destroying module clones (much like the device module from the demo).The thing though is that it would make sense in some of my use cases to use one and the same controller to manage many different types of module clones, not just one. All of these would (could) have the same interface (events), but their internal code would differ. You could say that they would be related/subject to inheritance (parent module with children).

So my question is, is this something others do already, and if so how do you solve it nicely? I can see how I could merge the code needed to manage different modules into one controller, but that would make a very messy controller as far as I can see. The other solution is to make the clonable module have conditional code to handle the different varieties of itself(...)/ use LVOOP, but that partly defeats what is so nice and simple with Delacor modularization.

Is this something that might become part of the framework scope in the future (or, if I'v emisunderstood things - already is!?)?

[FabiolaDelaCueva]

Hi Mads,

First of all thank you for your review at the LabVIEW Tools Network, we all at Delacor appreciate it and are happy to find you find the DQMH fun to use.

I will answer your question with to possible approaches (apologies in advance for the long answer, hopefully it is worth your time):

1) Option 1: Using a class hierarchy for your devices in a single cloneable DQMH module: Useful approach when the communication with your devices does not include any continuous communication. For example, communicating with a power supply.

2) Option 2: Using a class hierarchy, where each device instance uses a DQMH module as its support code. Useful approach when the device you are communicating with is streaming. For example, we have worked with serial devices that once a "start streaming" command is sent, they start spitting out information via the serial port, in those cases our DQMH module is continuously polling the serial port and parsing/packaging the information received.

Option 1:

First option is going to be more detailed, because Chris Roebuck has already done all the heavy lifting via his blogpost "HAL in your DQMH".  I believe the parts that you would be interested on are step 5 and 6. There are videos on that blogpost as well to see how this is done as well as a link to obtain the source code.

step 5:

    Chris shows the cloneable DQMH module and the Power supply class hierarchy:

On step 6

    Chris shows the creation of the events and how the local data in the cloneable DQMH module holds the actual Power Supply instance based on the class path chosen via the "Set Power Supply Type" Request.

Option 2:

This is a reminder for me, that I need to find the time to do the blogpost that describes the second option (it is in my ever growing to-do list, I promise I will get there... eventually   ... and when  I do, I will comeback here and add a link).

In the second option, we have the class hierarchy call the DQMH module.

In the example above, the "Serial Device Manager.lvlib" is a DQMH module that starts, initializes, communicates and destroys different serial devices. Only the "Streaming Serial Manager.lvlib" needs to be called by the "Streaming Serial Device.class ". The "Streaming Serial Manager.lvlib" is a DQMH module.

The class public methods would then be wrappers for the DQMH Module public API. I am showing here how the method to Initialize the Streaming Device Serial Device calls the Public API from the DQMH Streaming Serial Manager.

Hope this helps and if anyone has other options, please do share.

Thanks,

Fab

[Mads]

The option 2 scenario is very close to my typical use case. I could go that route.

Thanks (looking forward to the blog post)

(When I thought about this as an integrated part of the framework I was thinking that you could allow any clonable module to have multiple "main.vis" that would share the API-part (everything in one module lvlib). The start module would then just need a module type input to know which clone it should make, and everything else would be transparent. That would almost eliminate the overhead of having submodules.)

[FabiolaDelaCueva · Accepted solution]

Mads wrote:

When I thought about this as an integrated part of the framework I was thinking that you could allow any clonable module to have multiple "main.vis" that would share the API-part (everything in one module lvlib). The start module would then just need a module type input to know which clone it should make, and everything else would be transparent. That would almost eliminate the overhead of having submodules.

I just tried and it works! out of the box. The thing that doesn't work is the creation of more events, we might be able to do that in the future, so feel free to add this as feature request in the feature post: https://decibel.ni.com/content/docs/DOC-47789

Now, to what steps I followed to quickly test what you suggested (see animated gif below detailing all the steps, or the YouTube video

https://youtu.be/GIMt1DVNKK8 that you can pause):

1. Created a new DQMH Project from template (with all the defaults)
2. Expanded the "My Cloneable Module.lvlib" and opened Main.vi
3. Save Main.vi as a copy that was included to the library as well as "Main 2.vi" and added a 2 to the front panel to make it easier to recognize.
4. Created a new typedef enum control called "Clone Main Option--enum" with two values: Main, Main 2
5. Modified Start Module.vi to have the new enum as a required input.
6. Enclosed the Main.vi reference in a case structure with its selector wired to the "Clone Main Option enum" and on the other case put the reference to Main 2.vi
7. Modified "Test My Cloneable Module API.vi" to have the Clone Main Option enum next to the "Run New Module Instance" button and wired it to the Start Module.vi
8. Executed the "Test My Cloneable Module API.vi" and marveled at how easy it was to add new modules and have the correct modules respond and everything else still worked.

the caveat is that if I want to add a new event, it will only be added to the original Main.vi, the copied Main would not be scripted. This is the part that can be requested as a new feature.

Message was edited by: FabiolaDelaCueva

[Mads]

Thats great! I'll throw in the request for this to be a part of the framework, but the quick fix is good too.

[FabiolaDelaCueva]

Mads wrote:

Thats great! I'll throw in the request for this to be a part of the framework, but the quick fix is good too.

I was very excited yesterday that adding multiple Main GUIs just worked out of the box. However I have been giving it some thought and I still like Option 1 better and use option 2 when the class requires a continuously running asynchronous process.

I am going to be playing with some code to see if I can get a more clear picture in my mind of why that approach feels better.

Thanks for adding to the features request post and adding extra information regarding DQMH caveats when used with LabVIEW RT.

Regards,

Fab

[Mads]

One of the reasons option 1 is not that interesting for me is that it limits the uniqueness of each related module to replacing the VIs used to handle the messages. If submodules are separated into different "main"-VIs within the same module then related modules can be as different as you want them internally.

- I might want one of them to have an additional loop for example. You could say that this falls outside the goal of a "message handler"...

Have you had the chance to work any more on the video/blog post about option 2?

[FabiolaDelaCueva]

Hi Mads,

We have the sample code in the works for option 2. We have been focusing on getting ready for NI week. Will you be at NI week? Would love to chat to in person with you.

I should be able to work on the post after NI week.

Thanks for your patience,

Fab

[Mads]

Thanks for the update, I thought you might be busy for NI Week yes.

I will not be there, hopefully sometime in the future though (we are in the process of releasing a application (not a development tool) on LVTN ourselves, so it might become even more relevant).

[Arvin618]

DQMH is very good to help me solve many project.

And I have watch the Videos many times. Every time I can some new tips.

Now I meet a porblem:

In the project I will use 5 different types power supply: 3 DC(COM, GPIB and TCP) and two different AC power. Everytime user will choose one power supply to work.

I don't know which method to choose:

1. Add condition in DQMH for different power.

2. Make 5 Class for every power which like "HAL in your DQMH", but I need make every device have the same API methods ,alse 5 power have different VISA port.