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

[1984]

---

---

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. 

---

You dont sound condescending or arrogant or stuid-in-any-other way, and you could be right saying that I'm overthinking. From my perspective I dont. I rather say that I'm just very careful about making decisions about how to handle situations like this as our future architecture relies on my decisions today. I dont try to reinvent the wheel before I understand what others who faced the same problem tried already. Not sure if that matters, but I definitely appreciate your comments in this and all the other DQMH related topics.

If I understand your approach correctly then you use a clone manager DQMH module to start / stop clones as well as assigning them an instance name. If a new instance is created then its instance name + ID is written to the manager's module data. I assume your manager has a request "Return ID from instance name", so if you'd like to talk to the "DUT Power supply"  named instance then you send then name to your manager which returns the ID of that instance and from that point you just use this ID to address the instance of the Power Supply clones.

With an approach like this you can have one clone manager for several different DQMH modules, you just need to have different requests starting different modules: "start a new <module name>". (except if all done with VI referencing)

Did I get it right?

[joerg.hampel]

---

@1984 wrote:
Did I get it right?

---

Yes and no 🙂

---

@1984 wrote:
I assume your manager has a request "Return ID from instance name", so if you'd like to talk to the "DUT Power supply"  named instance then you send then name to your manager which returns the ID of that instance and from that point you just use this ID to address the instance of the Power Supply clones.

---

We haven't done that in the past (which doesn't necessarily mean it couldn't be helpful for you). If we have a clone manager module in a project, chances are we don't need to talk to the clones it starts from the outside. It is more of a "clone is a private resource of clone manager" situation, now that I think of it. 

For use cases where we want to access clones by name "all over the place", I'd rather go with an FGV containing said registry, instead of a full DQMH module. And I don't say that light-heartedly, because I usually argue in favour of creating rather one too many modules  than one too few 😉

[1984]

Got it. I had a hard time figuring that the clones in your case were the property of the clone manager. Thanks for explaining.

---

Last question, I promise*: would the method described below raise any red flags in your mind?

Method:

Add an input to the start module VI which sets the module instance name (wired to both the EHL and MHL).

Change the Module ID input of the requests from I32 to a variant. Programmer can connect an ID number to this input (as usual) but also a string or an enum. Modify the "addressed to this module" VI to accept a variant. Extract the text value if a string or an enum is coming in the variant input and compare it with the instance name also wired to the address to this module VI, output true if its a match. If numeric is connected then output true if it matches module ID.

Advantages:

- no lookup table needed, modules can decide if they are addressed

- modules like this can be used with a module ID input as usual, but also by a string or an enum

- Fully compatible with the traditional DQMH method, anybody who just a user can use as any other modules, except that he may notice that the module ID is not an I32 anymore

- (addressed to this module VI is only modified in a template)

Disadvantages:

- extra input at the start module VI, the instance must be named

- little overhead by converting the variant (~negligible)

- the same variant to module ID routine is need to be executed in the MHL if the MHL would like to use the module ID (increasing the complexity a bit, but so far I found very few cases when the MHL had to have the module ID)

- Instance name must be connected to the addressed to this module VI everytime a new request is created.

- some deviation from the stock DQMH

---

*I dont really mean it

[1984]

Attached a quick draft of the VI

[joerg.hampel]

---

@1984 wrote:

Add an input to the start module VI which sets the module instance name (wired to both the EHL and MHL).

---

We do that in a few cases. Usually for use cases where the module needs the information right away when starting execution (which is rarely the case, I have to say).

Our HSE Application Template has a showcase for this. See our DB Module instantiating the DB_CONNECTOR module:

 

---

@1984 wrote:

Change the Module ID input of the requests from I32 to a variant.

---

Personally, I would not go down that route. Deviating from the usual designs and the usual architecture makes it more difficult for your team and others to read the code. I am very conservative in that regard.

It's a very unusual use case to modify the standard framework inputs of the request VIs, especially moving away from the strict datatype (that's not how 99% of all clonable DQMH modules work). This requires good documentation so users of your module are aware of how they are supposed to use your code.

With all that being said, if it works for you, go for it!

[1984]

Alright, I guess got real good input about this topic.

Thanks a lot for the valuable insights.

[1984]

By using a map (key: instance alias, value: module ID) its easy to refer an instance by its name. But when you need to capture broadcast messages from the instances how do convert the ID back to the Instance name?

If the clone manager is a non-reentrant function of the DQMH module itself then the IDs are unique so simply converting the map to an array and searching for a module ID will work. This is how I do it now but wondering if there is a more elegant way.

(If the clone manager is something global - maybe a DQMH module itself - then this is not easy anymore as the clones of the different DQMH modules probably have the same IDs.)