DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Module registrations / start up sequence

Solved!
Go to solution

Excellent reply Joerg!

 

One word of caution for everyone: Understand that anything that happens on the left of the main case structure that houses the MHL and EHL has the potential to delay the module's start. Most of the time, your modules get to the init case fast enough to execute the synchronization. 

 

The HSE team got bitten once by an error a customer had where they (they = the customer) didn't understand why they were getting an error due to things taking too long before the Init case synchronization. The HSE team found out the issue withing a second of looking at the code.

 

I have worked with plenty of teams that have no problem executing code on the left of the main case structure.

 

That said, error wiring to the Start Modules is important, especially from the Start Module to the Register for events and from the Register for Events to the Synchronize Module Events is very important (as the OP already confirmed 😉 ).

 

Happy wiring!

Fab

 

EDITED-->> edited to clarify that the they in the comment above referred to the customer not to the HSE team 🙂

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 11 of 19
(203 Views)

@FabiolaDelaCueva wrote:

The HSE team got bitten once by an error a customer had where they didn't understand why they were getting an error due to things taking too long before the Init case synchronization. 


Our customer had spent a week or more, going in circles, even reinstalling systems, and slowly succumbing to insanity… but it only took me one glance to identify the issue in an instance. 

Because I’m so clever? No!!! Because I am aware of the mechanisms behind the scenes of starting a module. 

What I’m trying to create with my slightly dogmatic stance on how to start modules, and with my never-ending sermons on it,  is merely a better understanding in the community of what’s happening and where problems might arise in the future 🤷‍♂️😇




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 )


Message 12 of 19
(196 Views)

@joerg.hampel wrote:

Personally, I prefer a more "controlled" way of starting modules - meaning I like to place the Start/Sync VIs into a MHL or EHL (or Helper Loop) case.

 

Spoiler
Our HSE Way of Working goes one step further than many others and explicitly forbids any code from being executed outside MHL, EHL or Helper Loops - see https://dokuwiki.hampel-soft.com/kb/bestpractices/codingconventions/dqmh#starting_sub_modules

Ideally, you use the new VI Null Broadcast Events–constant.vi for preparing the event data type when creating the event registration reference. Then use either the Start Module.vi or the Obtain Broadcast References for Registration.vi for actually registering the real references at runtime:

 

dqmh-codconv-registerforbroadcast.png

Ok, so I created a private request and placed the code as you have it in the EHL.  Where should this request be called in the INITIALIZE case?  is there a certain timing it has to be done at?
I've put it after Synch Caller Events and before Module Did Init and appears to be working correctly.

 

shuttlefan_0-1737085614739.png

 

Message 13 of 19
(185 Views)

I think it makes no sense if you just move all registrations from outside into one event. I normally start each module with its own request inside the main DQML module and I do the same with stopping modules. At one hand you can order the modules startup this way and at the other hand debugging is easy.

0 Kudos
Message 14 of 19
(162 Views)

 


@Ludwig72 wrote:

I think it makes no sense if you just move all registrations from outside into one event. I normally start each module with its own request inside the main DQML module and I do the same with stopping modules. At one hand you can order the modules startup this way and at the other hand debugging is easy.


where are you starting the modules? inside the initialize MHL case?

0 Kudos
Message 15 of 19
(159 Views)