Main.vi Connector Pane

[FlatCat]

I'm new to DQMH, and while exploring of the various vi's in the module libraries, I just came across a blue #DQMH_CodeNeeded comment in Start Module.vi that explains how to change the connector pane of Main.vi. Does that mean that it is ok to add a control to the connector pane of Start Module.vi, and then pass that into Main.vi via its Start Asynchronous Call? 

I haven't found examples or mentions of this practice in my searches. And the fact this is not scripted into DQMH (with an Module Arguments Window similar to Events Arguments Window), makes me think it might not be a good idea. If not, what is the best way to pass initialization data into a module as it start up? I am currently using a request event. 

David Ferster

Lafayette Instruments

[Dhakkan]

---

@FlatCat wrote:

Does that mean that it is ok to add a control to the connector pane of Start Module.vi, and then pass that into Main.vi via its Start Asynchronous Call? 

To me, yes. I've created a custom Module template that expects two parameters as required inputs into the Start Module VI, and thus the Main VI.

---

@FlatCat wrote:

... makes me think it might not be a good idea. If not, what is the best way to pass initialization data into a module as it start up? I am currently using a request event.

---

That's a deliberate design choice you and your team would make that works best for you. Some teams would rather have a guarantee of the module being started without any worries about the additional input parameters being 'invalid'. Others would rather 'fail fast', with the rationale that the Module can exist ONLY when the bare minimum initialization parameters are provided.

[ervanhorn]

I have added controls to the connector pane of the main and start VIs for various reasons. If I understand you correctly, you are talking about passing initialization parameters directly to the start VI, which I have not done. I use initialization and/or configuration files so the configuration can vary by installation simply by modifying the files for each installation.

Instead, I define the path to a configuration editor folder, then have the module use files in that location during startup to initialize the project. I do it this way so I can reuse the module in multiple projects without having to change a hardcoded path.

If you don't want to pass a path, you can place ini configuration files in a folder relative to the project directory, then have your module read them in during initialization. If the initialization order relative to other modules is important, you could trigger the initialization in response to a request. 

Finally, I wouldn't say something is a bad idea in DQMH just because it isn't scripted. The fact that there is a bookmark indicating how to add controls to the Start Module.vi is, in my opinion, an indication that the DQMH Consortium believes this is a useful option.

[joerg.hampel]

---

@FlatCat wrote:

I just came across a blue #DQMH_CodeNeeded comment in Start Module.vi that explains how to change the connector pane of Main.vi. Does that mean that it is ok to add a control to the connector pane of Start Module.vi, and then pass that into Main.vi via its Start Asynchronous Call? 

---

Coincidentally(*), I just added content to our Dokuwiki about this topic:

https://dokuwiki.hampel-soft.com/kb/labview-frameworks/dqmh/starting-modules#startup_parameters 

Spoiler

(*) The coincidence being that David is a DQMH Enthusiast and has access to our collaboration platform, where he can ask questions directly to other Enthusiasts, Trusted Advisors and the Consortium

[joerg.hampel]

---

@ervanhorn wrote:

I have added controls to the connector pane of the main and start VIs for various reasons. If I understand you correctly, you are talking about passing initialization parameters directly to the start VI, which I have not done. 

[...]

Finally, I wouldn't say something is a bad idea in DQMH just because it isn't scripted. The fact that there is a bookmark indicating how to add controls to the Start Module.vi is, in my opinion, an indication that the DQMH Consortium believes this is a useful option.

---

In my opinion, deviating from the standard ways of doing things always comes at a cost. Other developers might have a hard time understanding what is happening if the code does not behave like usual implementations.

This obviously depends on your situation - there's an abundance of better practices that differ a lot between working by yourself, working in a small team, creating open-source code, or working in a huge regulated company.

Personally:
- I would never assume that a Start Module.vi which does not have terminals wired to the connector pane actually passes values to the Main.vi, or has any kind of logic added to it. This needs to be documented very well for me to understand what's happening, and where. 

- Furthermore, reading configuration data from a file etc. could be implemented in the "Initialise" case of the MHL. Or (as we do it at HSE) via a dedicated "Configure" request.

I will repeat: My comments might or might not be applicable to your situation, but they surely make sense in our context.

[ervanhorn]

---

@joerg.hampel wrote:

[...]

In my opinion, deviating from the standard ways of doing things always comes at a cost. Other developers might have a hard time understanding what is happening if the code does not behave like usual implementations.

[...]

Personally:
- I would never assume that a Start Module.vi which does not have terminals wired to the connector pane actually passes values to the Main.vi, or has any kind of logic added to it. This needs to be documented very well for me to understand what's happening, and where. 

[...]

I don't think I quite understand this; could you clarify? Are you stating that adding terminals to the Start Module.vi connector pane is not standard, and therefore you don't trust values on these terminals to be passed to Main.vi? You certainly have more experience with DQMH — and LabVIEW in general — than I do, so I would like to understand what you are stating.

---

- Furthermore, reading configuration data from a file etc. could be implemented in the "Initialise" case of the MHL. Or (as we do it at HSE) via a dedicated "Configure" request.

To be clear, most of my initialization has been accomplished by reading configuration data in the "Initialize" frame of the MHL and I have rarely added a control to the connector pane of the Start Module.vi. The most notable exception is when I use DCFG, which requires a Config Path for its Start Module.vi.

Incidentally, the HSE approach of using the "Configure" request is what I had in mind when I mentioned starting the initialization using a request. I have not needed to do this yet, which is probably a statement of the level of complexity (or lack thereof) of my projects… however, I can see how this approach would be important in certain situations.

My last point was that scripting shouldn't be interpreted as a litmus test of whether something should be done in DQMH, particularly if there are bookmarks in the code explaining how to do something. Until recently, Helper Loops weren't scripted, and I doubt many would have said at the time that they shouldn't be used because they aren't scripted.

[Darren]

Like many things, I think we can reduce this question to the preferences of a developer or team. I have no problem passing values into a module via Start Module and the Main VI's connector pane (the use case documented with the #CodeNeeded bookmark). Other developers are much more comfortable having a plain Start Module, and always passing necessary parameters via requests. Choose what makes sense for you and your team.

[FabiolaDelaCueva · Accepted solution]

As Joerg mentioned, we had this discussion in the private DQMH Enthusiasts and DQMH Trusted Advisors discussion forum... but we think others may benefit from the answer I gave there:

We tend to automate the things that are more likely to be done. Passing arguments to the Start Module is considered an advanced feature that requires a deeper understanding of how DQMH works.

There needs to be a lot of thought into whether you really need to pass the value before the module initializes. The preferred approach and the one we encourage everyone to do is to pass it via requests. We also, especially @joerg.hampel, encourage people not to execute much code before the Synchronization happens in the Init case of the module, because it could lead to timeouts.

Automating the addition of arguments when you create the DQMH module would encourage more developers to go this route, and could result in issues that are harder to debug down the road.

Just like in LabVIEW, we say that the preferred methods to pass data are:

1. pass data through a wire, if that is not possible, then
2. try using a local variable, if that is not possible, then
3. look into using a reference; if that is not possible, then
4. use global variables, and even then, check if:
5. A DVR would work better

In DQMH, we would say, to pass data to a module in initialization:

1. Try creating a request that configures your module when you get the "Module Did Init" broadcast, or when the developer sends it right after starting the Module.
2. Pass the data through the Start Module and change how the reference to the Main VI for the Start Asynchronous call

As you continue to explore, you will find more of these places where we let experienced LabVIEW developers modify the DQMH framework to work more to what they are used to or in a way that would work better for them. Feel free to ask questions here if you are not sure how to change certain things in the modules.

Happy wiring, 

Fab

[joerg.hampel]

---

@ervanhorn wrote:
I don't think I quite understand this; could you clarify? Are you stating that adding terminals to the Start Module.vi connector pane is not standard, and therefore you don't trust values on these terminals to be passed to Main.vi? You certainly have more experience with DQMH — and LabVIEW in general — than I do, so I would like to understand what you are stating.

---

---

I apologise for being unclear - let me reiterate my personal (HSE's) point of view and opinion.

(A) To me, passing any parameters the module needs via requests is the default way of working with DQMH. Out of the box, the "Start Module.vi" does not have any additional input parameters added, and the "Main.vi" does not have any additional controls added to its connector pane.

(B) The #CodeNeeded bookmark on the "Start Module.vi" block diagram describes how to pass parameters to the "Main.vi" via its connector pane. Again, technically sound and perfectly valid but not the standard, rather the exception to the rule (ie not there out of the box).

When working with DQMH and using existing modules, you're usually only exposed to the Pubic API - at least as long as things are working as expected. In that scenario, it doesn't really matter how parameters are passed to the module - via request, via Start Module, under the hood... Once you need to start debugging other people's code, the more those other developers deviated from the standard way of doing things, the more difficult your job will be.

Now, coming back to this discussion:

• Less experienced developers will not even know that it's possible to add controls to the Main.vi's connector pane. That makes it more difficult for them to understand code that uses this feature.
• If the "Start Module.vi" does not have any additional connector terminals added, I have no reason to believe that there's anything inside for me to look at, because it's a default scripted (templated) VI. In other words, I do not expect any program logic being added to that VI (like code that finds and reads configuration files and passes those to the Main.vi)

For those reasons, my recommendation still stands:

• If a request is good enough, don't add parameters to "Main.vi".
• If you add parameters to "Main.vi", make it so the same parameters are simply routed through from the "Start Module.vi" connector pane. That way, it will be more obvious what is going on.
• Do not add logic and module-specific code inside the "Start Module.vi" 

 

 

[joerg.hampel]

---

@ervanhorn wrote:
My last point was that scripting shouldn't be interpreted as a litmus test of whether something should be done in DQMH, particularly if there are bookmarks in the code explaining how to do something. Until recently, Helper Loops weren't scripted, and I doubt many would have said at the time that they shouldn't be used because they aren't scripted.

---

I don't necessarily disagree with this statement, but I think it's not a blanket truth either (what ever was??).

What I've learned over the years: Anything that makes the code harder to read (usually, the things that make me feel very clever) will sooner or later come back to bite me.