clonable module IDs from enum?

[Ozfarmboy]

Hi Carlo,

One approach that we've tried in our current project, is that we have a new module called "Device Manager", that sits in between the main Application module (at the top), and all of the devices (at the bottom).

There are several reasons we decided on having this Device Manager:

1) The first one is that the UI of the Device Manager has a number of Sub-panels on it, so that we can display the front panels of all of the devices on the one screen.  It's a busy screen, but its really only used for diagnostic purposes and it works for our client.

2) The second one, is that it effectively manages all of the devices - especially cloneables.  For this particular project, we have 5 barcode scanners, 2 dehumidifiers, 1 weighing device, and 1 motion control device.  The singletons are easy to manage, but with regard to the cloneables, by having a Device Manager we can handle the module ID problem you're describing, by abstracting the module IDs from the upper Application module.  So when the Application module wants to know what the barcode scanner 3's current barcode is, it simply requests the Device Manager for Barcode 3's barcode.  It doesn't need to know what the Module ID is.  Then the device manager keeps track of each barcode scanner's module id, and then consequently requests the correct barcode cloneable for the required barcode and sends it back up to the Application module.  Am I making sense? The device manager can also keep an eye on the status of each device, and share this with the Application module.  

So in summary, the Device manager allows us to abstract the messy handling of module ids away from the Main Application module, which keeps it simpler and cleaner and easier to read.  A little bit more message handling than going direct, but a neater Application module is the result.

[joerg.hampel]

Quick reply (tl;dr): I agree with Chris regarding a "manager" module.

FYI, here's a little write-up in our Dokuwiki as we've had the same question before:

https://dokuwiki.hampel-soft.com/code/dqmh/hse-application-template/clone-manager 

[carlod80]

Thank you everyone for your suggestions, they opened up a lot of possibilities! I will keep them as a reference if I have to deal with more complex scenarios.

[SolPS]

Hello,

I'm new to DQMH framework and I've followed this discussion as well as other threads related to this topic. However, my question is how do you restart a specific module after launching multiple modules? Say for example, you stopped module A out of modules A,B,C launched at initialization.  I know the use of a clone manager which stores the names and the IDs in a registry has been the recommendation but it is not clear to me how upon stoppage and removing the module name and ID from the registry, how the module ID can remain the same particularly where it is the framework that generates the IDs. Am I correct in assuming that module A when restarted, will have the same name and configuration as before(config file assumed) but possibly different module ID value which is then stored again in the clone manager registry under the same key.  Please clarifications will be greatly appreciated. 

Thanks

[joerg.hampel]

---

@SolPS wrote:

Am I correct in assuming that module A when restarted, will have the same name and configuration as before(config file assumed) but possibly different module ID value which is then stored again in the clone manager registry under the same key. 

---

Hey SoIPS, thanks for putting your trust in DQMH!

TL;DR: Your assumption is correct.

As always when replying to posts here in the forums or also when giving training or workshops, I'm very conscious about wording. When talking about cloneable modules, we usually do not talk about "modules" (this term usually refers to separate singleton or cloneable modules as they are stored on disk) but "instances" or "clones" (what you have in memory while running your application).

With that being said, I think what you're meaning to say is that you start three instances of a cloneable module, right?

The slightly longer answer to your question is: The Module ID is, just as you said, generated by the framework, and you have no way of deciding or controlling what the module ID of the next instance will be. This means that you cannot assume that the module ID for any clone will be a certain value. Especially when starting and stopping clones from within your application.

For example, if you had three power supplies and a corresponding "PowerSupply" cloneable module, and you then started a new clone instance for handling the first out of the three devices, do not use the constant value "1" in your code. Always use the module ID returned from the Start Module.vi instead.

Btw, seeing as a clone instance is ephemeral, I'm not sure that "restarting" is the best way to describe that you're starting another, new instance of your cloneable module and then tell it to load some configuration that was previously used by another clone instance which you stopped again.

Hope that helps!

[SolPS]

Hello Joerg,

You clearly answered my question. Your correction about the wording is duly noted. What I meant was instances of cloneable modules and I can see how such incorrect wording could be misleading. Your clarification is much appreciated. Thank you!