Differences

This shows you the differences between two versions of the page.

--- kb:labview-frameworks:dqmh:starting-modules [2025/01/21 17:48] – [When to start] joerg.hampel
+++ kb:labview-frameworks:dqmh:starting-modules [2026/07/13 16:15] (current) – [When to start] joerg.hampel
@@ Line 16: / Line 16: @@
   * By using the module's ''Start Module.vi'' and ''Synchronize Module Events.vi'' API functions.
-  * The module is not at the top level of the execution as it is being started by another VI (which might or might not be a DQMH module itself). Usually, the module being started is referred to as a **child module**. If the VI starting the child module is a DQMH module, itself, we refer to it as the **parent module**.
+  * The module is not at the top level of the execution as it is being started by another VI which might or might not be a DQMH module itself. If the VI starting the module is a DQMH module itself, we refer to the module being started as a **child module** and the module starting it as the **parent module**.
-//This page discusses aspects and ways of launching modules externally//.
+//The following sections discuss aspects and ways of launching modules externally//.
 ----
@@ Line 50: / Line 50: @@
 == 2. Continue to MHL ==
-  * ''Main.vi'' continues to start EHL, MHL, and any HLs (optional)
+  * ''Main.vi'' continues to start Event Handling Loop (EHL), Message Handling Loop (MHL), and any Helper Loops (HL; optional)
 == 3. Sync with Caller ==
@@ Line 163: / Line 163: @@
 ===== Starting Child Modules =====
-Make sure to also browse our [[kb:bestpractices:codingconventions:dqmh#parentchild_modules|HSE Coding Conventions on Parent/Child Modules]].
+This section describes ways of starting child modules. It lists different options and explains shortcomings/challenges. Make sure to also browse our [[kb:bestpractices:codingconventions:dqmh#parentchild_modules|HSE Coding Conventions on Parent/Child Modules]].
+  - From a Simple VI
+  - At Module Start
+  - In the EHL
+  - In the MHL, forking the event reference wire
+  - In the MHL, using a private request
+<WRAP center round alert 100%>
+At HSE, //the only allowed way// is **[[#in_the_mhl_-_variant_2|4.2 In the MHL - Variant 2]]**.
+</WRAP>
 ==== 1. From a Simple VI =====
@@ Line 204: / Line 216: @@
   * Forking the registration reference wire so we can update the event registration of the EHL in the MHL
   * <color /#FFCCCC>Potential confusion about forked registration wire - not recommended by HSE</color>
+    * See the [[kb:bestpractices:codingconventions:architecture#event_registration|HSE Coding Conventions]]
 <WRAP center round box 100%>
@@ Line 223: / Line 236: @@
 ----
-===== When to start =====
+===== Startup Parameters =====
-The concept of placing the code for starting modules inside EHL/MHL and having a request or Queue message trigger the starting of child modules gives control and flexibility over when and from where modules are actually (re)started.
+You can pass in parameters directly when starting a DQMH module. This is done by adding controls to the connector pane of ''Main.vi'' and then wiring those in ''Start Module.vi''. A ''#CodeNeeded'' comment on the block diagram explains the implementation:
-  * HSE projects usually feature a [[code:dqmh:state-machine|State Machine]] that automates sequential actions inside our modules.
+{{:kb:labview-frameworks:dqmh:start-module-params.png}}
-  * Our [[code:dqmh:hse-application-template|HSE Application Template]] calls the "Configure" request automatically for any module it starts, which is another potential place for sending such a request (usually in combination with a state machine, though)
+There are two distinct results this approach allows for that cannot be reached otherwise:
+  - Have that input parameter available as soon as the ''Main.vi'' starts executing (ie even before the "Initialize" case etc.)
+  - Force the user of the module to provide a value at start time (whereas you cannot force a user to send requests in a certain order)
+The second argument is not a strong one, as a user can still provide a "wrong" value so there will always be the need for proper error handling, regardless of how parameters are provided.
+<WRAP center round help 100%>
+HSE's rule of thumb is to always pass parameters via requests unless there is a strong argument for hard-wiring them like this. We feel it's safer to go with the standard way of doing things (ie requests) as this will make it easier for others to read the code. Also, passing parameters via request gives control over when to send or resend that data.
+</WRAP>
+----
+===== When to start =====
+The concept of placing the code for starting modules inside EHL/MHL and having a request or Queue message trigger the starting of child modules gives control and flexibility over when and from where modules are actually (re)started. It does beg the question, though, of where and when to actually send the request or message triggering the start.
+<WRAP left round help 100%>
+See **[[kb:bestpractices:codingconventions:apptemplate#startup|Application Template Startup]]** for how to design module coordination in the HSE Application Template.
+</WRAP>
 ----