clonable module IDs from enum?

[carlod80]

Dear DQMH community,

    I would like to control a number of identical instruments (power supplies) with the same (clonable?) DQMH module.

In a "normal" programming scenario, I would surely write an instrument class and each instrument would be an instance of this class, and here I'm thinking something along the lines of: "my class is the clonable module and each clone is an instance of the class". I might sound confused (and I probably am!), but what I'm missing here is a way to uniquely associate a physical instrument instance with a specific clone ID. I mean, the user spawns  a module clone by providing the address or the reference to a specific instrument (call it "Bob"), but then I would like a way for the module user to send a request to Bob to set the voltage to 4.5V (not to "module ID 4210004"). The module user can obviously keep track of this by himself in the calling code, but I find this should somehow be a module's responsibility.

To this end, I was wondering if there was a way to modify the DQMH clonable template to deal with a finite number of clone IDs through an enum, that would be passed to the Start Module VI, where each enum item uniquely identifies an instrument. Obviously, a new clone with the given name (i.e. module ID) would be spawned only if there isn't a clone with the same name already running, otherwise the start module would simply report "Module "Bob" (ID: 4120004) is already running".

If this approach is feasible, do you have any comments/suggestions/warnings on how to implement it?

Please be kind on me since I've just started exploring the world of clonable modules...!

Thank you!

Carlo

[FabiolaDelaCueva]

Hi Carlo,

Your cloneable module can still call a class for your power supply. You can either change the local cluster into a power supply object or just store the power supply object in that cluster.

One idea that comes to mind:

Regrading managing your clones, each cloneable DQMH module comes with a Clone Registration.lvlib. That library is yours to modify, you could modify the Clone Registration.lvlib to host both the module ID and whatever name you want to give to it. You could create two VIs, one that converts from instrument name to module ID and one that converts from module ID to name.

There are multiple ways to address this issue. I am curious to see what you come up with and what others suggest.

Thanks for your trust in DQMH,

Regards,

Fab

[Gregory]

Hi Carlo, I would keep track of your module names as you launch the DQMH modules. You can create a cluster full of the module names, and then just unbundle the one you need, which will make the code easy to read.

[carlod80]

Thanks @Gregory! Yes that is one option that I thought of, but I would like to try to delegate this functionality to the module itself.

[Gregory]

Well, you could set the name as part of the module data. Then when you want to send a command, you first ask all clones to send out a broadcast if their name is "XYZ". Assuming all the names are unique, only one broadcast will be sent out, and when the calling code receives it, it can send a message to just that module ID. But that seems like a lot of back and forth for little benefit.

[carlod80]

Thanks @Fab for your suggestions. You say:

Your cloneable module can still call a class for your power supply. You can either change the local cluster into a power supply object or just store the power supply object in that cluster.

Ok, but I'm missing what would be the advantage of this: am I not simply moving the functionality from the module to the class, adding another (unnecessary) layer to the code? Probably a class can be re-used in more contexts with respect to a DQMH module?

One idea that comes to mind:

Regrading managing your clones, each cloneable DQMH module comes with a Clone Registration.lvlib. That library is yours to modify, you could modify the Clone Registration.lvlib to host both the module ID and whatever name you want to give to it. You could create two VIs, one that converts from instrument name to module ID and one that converts from module ID to name.

This looks promising to me! To make the API "module ID-agnostic" I could also modify each request VI to internally convert the "human name" of the instrument to the module ID by using the conversion VI that you mention. What do you think about this? What I don't like is the idea of relying on hand-crafted modifications of the DQMH-generated VIs...

This could also be a DQMH feature proposal, albeit maybe a little far fetched: the Start Module VI for clonables could have an optional input (a string or an enum or a ring) that uniquely identifies the clone to be spawned, and replaces the module ID. If the input is not provided, the framework internally generates a module ID. I understand that it might be tricky to handle "mixed" cases where one clone is started with the input and another one without...

Thank you for all your work in making DQMH an invaluable tool!

Carlo

[Taggart]

---

@carlod80 wrote:

Ok, but I'm missing what would be the advantage of this: am I not simply moving the functionality from the module to the class, adding another (unnecessary) layer to the code? Probably a class can be re-used in more contexts with respect to a DQMH module?

I think you answered your own question.

[carlod80]

Well, actually, on second thought, there is a quick way out of this issue in my specific case. Since I'm using an HTTP REST API to control these instruments, I can use a non-clonable module and pass the relevant part of the resource URI (which is known and meaningful for the user) to each of the module's requests. HTTP makes this easy since on the client side I don't  need to maintain information on the connection state.

[FabiolaDelaCueva]

---

@carlod80 wrote:

Thanks @Fab for your suggestions. You say:

Your cloneable module can still call a class for your power supply. You can either change the local cluster into a power supply object or just store the power supply object in that cluster.

Ok, but I'm missing what would be the advantage of this: am I not simply moving the functionality from the module to the class, adding another (unnecessary) layer to the code? Probably a class can be re-used in more contexts with respect to a DQMH module?

Some people use the DQMH module as a way to test their classes APIs via the API tester. Also, if you are like me, and you like to not change every single case structure in your code with dynamic dispatch, this allows you to keep the class "pure" and add any external code like UI stuff to the DQMH module and not the class. This is also useful in some measurement abstraction layers, the class implements the hardware abstraction layer and the DQMH module implements the measurement abstraction layer. Finally, there are teams that have different levels of proficiency, the people who feel comfortable working with classes create the classes and the DQMH wrapper allows those who are not comfortable with classes or who are casual LabVIEW developers to have a simple API and an API Tester to go with it. I am sure there are other advantages or reasons out there.

---

@carlod80 wrote:

One idea that comes to mind:

Regrading managing your clones, each cloneable DQMH module comes with a Clone Registration.lvlib. That library is yours to modify, you could modify the Clone Registration.lvlib to host both the module ID and whatever name you want to give to it. You could create two VIs, one that converts from instrument name to module ID and one that converts from module ID to name.

This looks promising to me! To make the API "module ID-agnostic" I could also modify each request VI to internally convert the "human name" of the instrument to the module ID by using the conversion VI that you mention. What do you think about this? What I don't like is the idea of relying on hand-crafted modifications of the DQMH-generated VIs...

You would have to do a quick proof of concept and see if the extra modifications are worth it for you. You could also create a child of the Module Admin and add the name there. There are different ways to do this but to be honest, I have never modified the clone ID manager, we made it a copy in each of your modules so you could modify it if you wanted to 😉

---

@carlod80 wrote:

This could also be a DQMH feature proposal, albeit maybe a little far fetched: the Start Module VI for clonables could have an optional input (a string or an enum or a ring) that uniquely identifies the clone to be spawned, and replaces the module ID. If the input is not provided, the framework internally generates a module ID. I understand that it might be tricky to handle "mixed" cases where one clone is started with the input and another one without...

There is already a feature request like this:

https://forums.ni.com/t5/Delacor-Toolkits-Documents/DQMH-Feature-Requests/tac-p/3537854/highlight/tr...

Still on the wishlist 😉

---

@carlod80 wrote:

Thank you for all your work in making DQMH an invaluable tool!

Thanks to you for your trust in DQMH and us,

Fab

[FabiolaDelaCueva]

---

@carlod80 wrote:

Well, actually, on second thought, there is a quick way out of this issue in my specific case. Since I'm using an HTTP REST API to control these instruments, I can use a non-clonable module and pass the relevant part of the resource URI (which is known and meaningful for the user) to each of the module's requests. HTTP makes this easy since on the client side I don't  need to maintain information on the connection state.

---

That looks like a good approach to me