03-27-2020 01:26 PM
Hi DQMH-ers,
Firstly, thanks to Fabiola and her team for creating such a great toolkit, I have just delivered my first project using it and it was a dream to work with. As the only LabVIEW developer in my company it is great to have the support and peace of mind that comes with using a tried-and-tested framework. I have found it very hard in the past to improve my coding skills not having someone else to learn from but I can safely say that I have learned more in the last few months using the DQMH than I have in a long time!
That being said, I do have a small question - please excuse my ignorance I'm still a bit of a noob when it comes to DQMH.
The first iteration of my application uses the standard method of starting child modules from the UI after launch (Fig. 1)
Fig. 1
This is great and works perfectly for our current application with 8 child modules, four of which launch their own child modules after startup (so 12 modules total). I already have requests for a further 6 modules. This is where it's starting to get a bit unwieldy.
Before I go any further I should mention that not all modules will be required to run all of the time, we change hardware components frequently. The ideal application will scan the current hardware set at startup and only start acquisition and logging modules for the sensors that are present (reducing overhead etc.).
So I replaced the Start Module.vi/Synchronize Module Events.vi pair with Obtain Broadcast Events for Registration.vi (fig. 2), and then started adding the Start Module.vi/Synchronize Module Events.vi pair into individual event cases in the code, this is where I run into trouble.
Fig. 2
When I go to start the modules and register for their events dynamically from within the event structure it seems I have to register for all of them at once - the register for events function is not resizable (Fig. 3), it doesn't let me register for only one of the module's events at a time. What should I do in this case? Hold all of the broadcast events for registration in a shift register in the EHL? Is there a better (cleaner) way to dynamically start modules individually? Should I be using the 'Launcher' rather then the UI to launch these modules?
Any help/feedback greatly appreciated.
Thanks,
~AVD
Solved! Go to Solution.
03-29-2020 12:16 PM
Hey AVD,
you can update single event registrations from inside the event structure. Just leave those event registrations unwired that you don't want to update. Seeing as you need to define the events (or rather, the case of the event structure) during edit time, you need to prepare all the events beforehand, for example with constants or via the "Obtain broadcast" VIs.
If you don't know the number of events (i.e. modules) upfront, you can supply an array of events. See our HSE Windows Application Template (UI Manager:Set Modules) for details.
See the screenshot...
Cheers,
J.
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® (Developer Experience that makes you smile )
03-29-2020 02:09 PM
Thanks Joerg, looks like it was a misunderstanding on my part.
I assumed all of the user events had to be wired in each case, I didn't realize I could just leave them unwired (I did a quick test on this and some of the modules events weren't firing but it must have been for a different reason!). I'll certainly check out the template.
Thanks again,
~AVD
03-29-2020 03:37 PM
Hi AVD,
Glad you are liking DQMH and learning. Thanks for sharing your experience with us.
Regarding your question, as you found out:
@AudioVideoDisco wrote:
I assumed all of the user events had to be wired in each case, I didn't realize I could just leave them unwired (I did a quick test on this and some of the modules events weren't firing but it must have been for a different reason!). I'll certainly check out the template.
You can leave the inputs unwired. If you look for a similar behavior elsewhere in LabVIEW, check the bundle function. The bundle by name requires all its inputs to be wired but the bundle doesn't. It assumes that whatever is in the middle terminal is the value that remains.
From the Bundle function help: "You also can use this function to change the values of individual elements in an existing cluster without having to specify new values for all elements."
When I teach people about registration of events, I like to show them the bundle, the majority of LabVIEW developers are familiar with the bundle function and it is an easier transition to understand why you don't have to wire all the events in the Register for Events function.
I hope this helps clarify and doesn't make it more confusing.
Regarding launching multiple modules, do take a look at Joerg's architecture, it is a good alternative to when you want to launch multiple DQMH modules.
Thanks for your trust in DQMH and our team.
Happy wiring,
Fab
03-30-2020 12:46 PM
Hi Fabiola,
Thanks for the clarification, I'm embarrassed to say that the bundle functionality you mention is something I had never noticed after 8 years of working with (and teaching) LabVIEW. I always tend to shy away from using bundle in favour of bundle by name so had never given it a chance. You learn something new every day!
I will certainly check out Joerg's architecture.
Thanks again,
~AVD