DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Syncing cloneable modules? (eg. Identifying "oldest" RUNNING clone module ID)

Solved!
Go to solution

I come here after exhausting my own abilities at fully understanding what's going on under the hood of DQMH cloneable modules.

 

I have had the need, a few times now, for a cloneable module, that when run, needs to determine whether it is the first/original clone, and if it is not the oldest/longest running clone, to identify the clone that is and request data from it in order to synchronize data that occurred before its existence.

 

I'm aware of those sync vis but my understanding is there may be a caveat there. Could I run the vi that outputs the module id of the "is first?" clone? Possibly. But my understanding is that the first clone, should it receive a stop module request, will NOT actually be fully shutdown, it will in fact go into a state where it polls the list of clones until it is the last one "alive" and then shutdown. During this state, it no longer replies to requests/etc.. So if the first clone shuts down, it is still technically the first/oldest according to DQMH but for my purposes I really want the oldest clone that is actually still fully operational and responsive to requests.

 

Is my understanding incorrect in how all this works? Please explain if it is, I fully appreciate the benefit of having a total mastery of how a framework works, and strive to achieve this with DQMH. Also, what would the best way be to determine the oldest still running clone? I'm afraid to rely on something like the index of a module id in an array or the module id number itself for this purpose because I'm not sure exactly how they are managed in all situations (eg. lots of modules starting and stopping over the course of a long session).

 

Thanks!

0 Kudos
Message 1 of 3
(887 Views)
Solution
Accepted by joerg.hampel

I suggest writing a separate manager module that holds onto the information that you're currently relying on different clone instances to keep. Seems like an easier approach than trying to keep track of that responsibility as it flies around between different cloneable instances.

0 Kudos
Message 2 of 3
(879 Views)

I agree with Darren. Here's a tiny bit of information on how we usually design DQMH Clone Managers.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 3 of 3
(825 Views)