I've gone away and considered my comments Joerg! Here are my internal guidelines on this matter, some of which have been freshly influenced by this conversation. I've re-written this text 2 times! Apologies if we're going a bit off topic of the original post!
1) Consider a helper loop first before creating another DQMH module.
a) Good examples of this is when you need unblocked cyclic code (ie state machine, or continuous data acquisition) - In my opinion it's better to be in a helper loop rather than having another module doing this and the MHL being a self-enqueuer. Having said that, if you're needing more than one helper loop in a module, that's when I would start to look at whether another module is the right choice.
2) Create a DQMH module if the code needs to be dynamic, self-managed, asynchronous, dependent on classes and is likely to be called in multiple places, or has a UI element. If it's not any of these things, does it need to be a DQMH module, and can a set of one or more wrapper VIs suffice (ie. a single VI, a library or a class - as per what Sam suggested earlier)?
a) If you're showing a dialog that has no need to be asynchronous, does it need to be a DQMH module? Can't it just be a Sub-VI?
b) Working with a fellow DQMH Trusted Advisor recently, he had made a nice single VI that performed a complex zipping up of a bunch of setup files. In this instance, even I was leading towards making another DQMH module. He said "Nah, it's just one VI"!
3) Consider when one module might be better than two. ie. If two different instruments/devices need to be tightly coupled or synchronised for a very specific use case.
a) I had a vision project. The image acquisition and triggering (via an FPGA) needed to be tightly coupled. Initially I had created a module for both camera and FPGA. In the end, I succincted it down into one module so that the Camera/FPGA could be acted on with more immediacy. It just made far more sense to me to be working with the direct APIs side by side, rather than going through DQMH module APIs.
b) Similar to above, we needed to have an XNET device tightly coupled / synchronised with NI DAQmx. Rather than creating a module for each, we made one module to achieve the synchronisation required.
Note that the above examples are the exceptions, and not the normal WiS approach.
4) Ensure you put some time into designing your application up front. As per Sam's suggestion, pay attention to hierarchy, and working out which modules need to know about other modules. By applying the hierarchy approach, you can apply encapsulation, and hence removing the need to have one module at the top that registers for broadcasts of every module in the application. Use Antidoc to show the actual hierarchy, to confirm if the modules are not too tightly coupled.
Just a note on hierarchy. My belief here is that typically you shouldn't need too many layers. We rarely have more than 3. If you've got 5 layers or more, I'd like to know why. What sort of application requires that many layers?
Would love to hear where this is a practical choice.
Example situations of where a hierarchy is of value:
a) You have a module that depends on a number of sub-modules. For instance, you have a UI module, that depends on multiple UI sub-modules (ie these could be dialog modules, or customised graphs or tables where you want to abstract away the graph manipulation code - ie lots of property node usage - kind of like a DQMH version of an Xcontrol), and those sub-modules are very specific to that UI module, and are not required anywhere else in the application. In this case, these sub-modules should be launched by the UI module alone, and the UI module should be the only module that receives the broadcasts from those sub modules, and the UI module should be responsible for shutting down the sub modules. In this case, the parent or top level module of the application does not need to even know that those sub-modules exist, and does not need to register for those module broadcasts or launch them upon starting. This in line with Sam's earlier comments, and his Dos and Don'ts about structuring your application.
b) Another example of the above is if you have a number of instrument/device modules that needs to synchronise or be brought together, you might then have a device manager module to organise these. We have done this in the past, but then cheated and passed the errors/status broadcasts all the way up to the top directly, bypassing the device manager. Now that I've thought this through, it wouldn't be too much effort to have those device modules only report to the device manager module and have the device manager module pass up any broadcasts (ie. error/status) as required. And as above, the device manager module is the only module responsible for launching, registering for broadcasts, and shutting down modules. With this in mind, does the parent/top level module need to know about all of the instrument modules? Perhaps not.
Christopher Farmer
Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au
