Single or Multiple Clone managers?

[SolPS]

Hi All,

I'm working on an application that runs multiple clones that are launched and configured using a Device manager module. These clones in turn call hardware drivers that are wrapped in another DQMH cloneable module. My question therefore is how best to manage the DQMH cloneable wrapper module. Is it ok to use a single Device Manager for all the different clones in the application or create a separate manager module for the DQMH wrapper? Also can you use the same module manager for both cloneables and singletons?

Thanks in advance! 

[Ozfarmboy]

Hi SoIPS.

Based on your description, it feels like you have a layer too many.  Why do you need a module to manage modules that wrap around further modules.  Do you really need the middle layer?  It seems like you're trying to build up a hierarchy as if they are classes, and I don't think DQMH is suited to that.

I suggest drawing out a diagram of your architecture and get clear on what the purpose of each module is.  Think through the practicalities of having all of these layers, and the event overheads that might ensue.

Try not to make it overly fancy or generic.  Keep it simple.

[SolPS]

Hi Chris,

Thanks for your reply.  I have a manager that launches the cloneable modules which will actually interface with multiple instruments. However, it was basically a situation where I had to choose between calling the HAL instrument driver classes directly or wrapping the drivers inside another DQMH cloneable module and just call the methods using the DQMH module API. I was wondering if I could use that same Device manager for the cloneable driver module. I was also concerned about having too many layers and that was why I posted the question on the forum.  Perhaps, this explains my issue better. I will take your recommendation if you think this is one layer too many.

Thanks

[Ozfarmboy]

At Wired-in Software, we use the HAL classes a lot underneath our DQMH modules (see this link for a great description of how to do this: HAL in your (D)QMH - DQMH®).  

This works really well for us.

[FabiolaDelaCueva]

Chris already set you on the right path, may I also suggest to take a look at https://dqmh.org/simplifying-your-hardware-abstraction-layer-hal-with-lvoop-and-dqmh-part-1/

Once you have your diagram, feel free to share it with us and we could give you further feedback.

Thanks for your trust in us and in DQMH

Happy wiring,

Fab

[SolPS]

Hi Chris,

The steps outlined in that link you posted is what I was trying to follow. I wanted to wrap the HAL inside a cloneable DQMH module and call it from another clone one level above. However, I wanted to know if I could still use the clone manager to launch and manage the HAL clones or launch them from the calling module. I've attached a quick layout of the application and would like to get your recommendations with regard to best practice.

Thanks 

[SolPS]

HI Fab,

Thanks for your reply. I've looked at the links that you and Chris have provided and they were very helpful. I've also provided a quick layout of my application.  The clone manager launches and configures the clones while the HAL clones will be called through the module API. I just wanted to make sure that I'm using the framework correctly. Again, I appreciate the responses and await your feedback on this.

Thanks

[Ozfarmboy · Accepted solution]

Application Architecture:

Without knowing the requirements of your application, I still feel that you don't need either the Clone layer OR the HAL Clone layer, assuming both these layers are DQMH. 

If the HAL Clone layer is actually just a class hierarchy, then this sounds ok.

There would have to be some very compelling reasons to have that many DQMH layers.

Clone Manager: 

I have written code where we didn't have a clone manager and it worked fine, but it made the code in Main a little messy having to handle the clones.  I would recommend as a minimum that you have a VI (or set of VIs) to handle the clones to abstract away the messiness.

But I would consider what is the purpose of the clone manager as to whether it validates making another DQMH module.  It might be that it needs to do some fancy sychronisation of all the data coming up from all of the clones, and hence a DQMH module will be able to "manage" this better than a sub-VI running in Main. Or maybe it needs to collect all the data, filter it or decimate it in some way, or even may have some smarts where it self-tunes the other clones depending on how each clone is performing.  These would be some good reasons to have a Clone Manager module.

I 

[SolPS]

Hi Chris,

I wanted to be able to easily address specific clones, start and stop specific clones and also remove the messiness. That was why I implemented a clone manager and I will rather go with a class hierarchy in the HAL clone layer. Also, there was no other compelling reason for an additional DQMH layer other than trying to choose the best implementation option.  Again, your response is much appreciated. 

Thank you.