Module registrations / start up sequence

[shuttlefan]

Trying to to implement a logger module to assist in debugging an issue, I broke my code by merely reordering the module registration order.
No compile time nor run time error.  Just that no data is being received but I'm not sure why.  

My application has:

DisplayUI module, this is the main one that kicks everything off and presents the UI.

ADSSClient module, responsible for configuring and setting up the dataserver.

Policy module, once setup, polls the dataserver on fixed cycle and broadcasts the data to the DisplayUI to be displayed.

so what's confusing is when I step into the the DISPLAYUI module, the very first step (even before the DisplayUI INIT)  is POLMOD and the bottom one.  Then it goes to the DisplayUI INIT.  

This is different than waht I assumed the start sequence is as shown in the DisplayUI module and in depth first order.

So how do I know which is the order being processed?

The policy is started once server communications has finished and is initiated by ADSSClient module

Once it starts, I update the other modules by calling.

[ChrisFarmerWIS]

I would try running an error wire between each start module and broadcast reg vi to control the order of execution.

[shuttlefan]

---

@ChrisFarmerWIS wrote:

I would try running an error wire between each start module and broadcast reg vi to control the order of execution.

---

OK, I can try that.  So should all the registration happen before the module's INIT call? or should the first reg be AFTER the INIT call as well?

[ChrisFarmerWIS]

In the top level module, I typically register for broadcasts for all modules to the left of the block diagram as the first thing done.

Then I create a "Launch children modules" internal event that is called by the Initialize case.  In here it goes and starts all modules.

If there are other modules launched separately by the children modules, then I wait for them to be ready and then call another internal event "Refresh registrations" to then register for any other modules that the top level module didn't launch itself.

[shuttlefan]

Hmm....doing error lines I end up with only DisplayUI module running. 
Without it, I could get DisplayUI and ADSSClient modules. 

[ChrisFarmerWIS]

I recommend that you actually track what's coming out of those errors - maybe you've got an actual error and hence the flow on VIs are not executing.

[shuttlefan]

yeah, that's just the issue.... All the errors output show none.
I tried stepping through but that in itself introduced errors that I don't see when I just run it.  

I've isolated to that from my top level DisplayUI module, if I connect the StatLog to ADSSClient by error line, then ADSSClient does not fully initialize.  If I don't connect that error line, then both ADSS and StatLog both run.

[ChrisFarmerWIS]

I want to add that in our "launch children modules" case, we have a for loop where we launch each module one at a time in turn.  That way we dictate the order in which they're launched.  For instance we have a configuration module in our applications, and we launch that first so that we can get access to the config data and pass that on to the subsequent modules.

[shuttlefan · Accepted solution]

Found the issue.  It wasn't the order but the fact that I forgot that actual module start needed the error wire to go back in the registration.  The broadcast for reg does not.

[joerg.hampel]

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:

As for the error wires... I'm quite confident that wiring them actually influences the order and timing of things happening (technically, the VI Start Module.vi  does not know about the error being wired or not). Ideally, all error terminals are wired at all times:

 

Spoiler

Again, the HSE Way of Working for error handling is a bit stricter, really frowning on unwired error terminals.