Why Module ID numbering starts with 1 instead of a 0?

[1984]

I'm wondering whats the reason behind that the Module ID of the first cloneable instance is 1 instead of zero?

Its probably by design, but for me it seems it just makes it difficult to use enums to address the clones. 

[Cloedu72]

I always use zero/0 - enums with the default value "unknown".

=> This is also better if you have typecasting problems.

[Olivier-JOURDAN]

0 is used for cloneable module running as singleton 🙂

[1984]

How could I miss that? Thanks man!

May I ask what is the mechanism you use for addressing your modules? I wouldn't use rings as the instances wont follow the typedef. Sure an enum can be used with the 0 = dont use, but this seems well... not the best.

[Enrique.Noe]

I have been using maps lately, the key is the name or identification of the instance and the value is the ModuleID.

[Olivier-JOURDAN]

---

@1984  a écrit :

May I ask what is the mechanism you use for addressing your modules? I wouldn't use rings as the instances wont follow the typedef. Sure an enum can be used with the 0 = dont use, but this seems well... not the best.

---

As @Enrique.Noe said, the map is an excellent tool for that.

[joerg.hampel]

---

@1984 wrote:

May I ask what is the mechanism you use for addressing your modules? I wouldn't use rings as the instances wont follow the typedef. Sure an enum can be used with the 0 = dont use, but this seems well... not the best.

---

DQMH handles the dispatch of clone IDs internally: The framework decides which ID a new clone instance is assigned. Depending on the order of starting clones, or stopping and starting them while your program is running, the clone ID might or might not match its "identity" (what you want the clone to represent). 

So instead of relying on static clone IDs (which means you always have to start them in the exact order, and never stop and restart them), it makes more sense to have a clone registry where you map the name or descriptor of each instance to its clone ID.

Depending on the requirements, we usually create a clone manager which takes care of starting clones, telling them what to do (i.e. handing over some sort of configuration), and keeping the "name to ID" relationship in the clone registry.

We have a little bit of documentation on this topic collected in our dokuwiki: https://dokuwiki.hampel-soft.com/code/dqmh/hse-application-template/clone-manager

[1984]

---

Depending on the requirements, we usually create a clone manager which takes care of starting clones, telling them what to do (i.e. handing over some sort of configuration), and keeping the "name to ID" relationship in the clone registry.

I dont have too much experience with DQMH (getting there though I believe) but already figured that using numbers as a clone ID could be inconvenient some cases. At this point I dont have the time to develop such a clone registry and I try to keep the complexity on a level of my experience with DQMH, so for now I guess I must go with the start the dqmh modules in order and dont stop them. Having a clone manager makes sense although I'm not sure how that should be implemented. Is that simply a key-value pair of module "names" and module IDs?

I assume this is the concept of what @Oliver and @Enrique explained with a map. Alright, so I have a key-value pair. But the module still identifies itself with a number. A VI can be created which outputs the ID from the name (so maybe the name really could be an ENUM and it will get translated to the proper module ID), but what is the exact implementation. What I can imagine is that I always need to put such a VI in front of all my requests. Could you guys send me a screenshot of how do you use maps?

[1984]

Another option would be to replace the Module ID input of all requests to something else (maybe an enum, or a string or something which identifies the module) and place a VI which translates this input to a Module ID. But wouldn't it broke the DQMH fundamental strucutre? I dont know. Enough guessing, I'm really wondering how did you guys solve this.

[joerg.hampel]

---

@1984 wrote:

Enough guessing, I'm really wondering how did you guys solve this.

---

I don't want to sound condescending or arrogant or stupid-in-any-other-way at all, but it seems to me you're overthinking this. All you need is a simple lookup table. Whether that is a map, two array, a variant... doesn't really matter that much.

1. when you start a clone, you assign it a name and store that match ("name" -> id) in your lookup table

2. if you need to interact with that specific clone, you look up the name and then use the linked id 

3. when you stop the clone, you remove that entry from your lookup table

The most basic implementation (I think) is a set of two arrays: Whenever you start a new clone, you add the ID to one array and the name to another, so that those two matching values live at the same index within each array. I just threw this together from scratch to illustrate the idea of a clone manager: