Differences

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

--- kb:labview-frameworks:dqmh:starting-modules [2025/11/10 11:06] – [Startup Parameters] joerg.hampel
+++ kb:labview-frameworks:dqmh:starting-modules [2026/07/13 16:15] (current) – [When to start] joerg.hampel
@@ 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 225: / Line 238: @@
 ===== Startup Parameters =====
-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 ''#code_needed'' comment on the block diagram explains the implementation:
+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:
 {{:kb:labview-frameworks:dqmh:start-module-params.png}}
@@ Line 236: / Line 249: @@
 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.
-HSE's rule of thumb is to always pass parameters via requests unless there is a strong argument for hard-wiring them like this.
+<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>
@@ Line 246: / Line 261: @@
 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.
-  * HSE modules with the need for automated sequential steps usually feature a [[code:dqmh:state-machine|State Machine]].
+<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.
-  * 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)
+</WRAP>
 ----