There are two ways of launching a module:

• By clicking the Run arrow of the module's Main.vi.

• The module is the top level of the execution and needs to take care of any resources, errors etc by itself.

• 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. 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.

The following sections discuss aspects and ways of launching modules externally.

The DQMH Framework helps developers write reliable and robust code by taking care of various aspects like reference lifetime and synchronization of actions. When starting a module, the module itself creates all required resources like event references to own them and dictate their lifetime.

To ensure that the code starting the module receives any resources only after they've been created, and to make sure that the code only continues execution once the module is ready to receive requests, the DQMH Framework provides the process described in this section.

• The calling VI executes Start Module.vi

• Start Module.vi…

  • uses Start Asynchronous Call to run the module's Main.vi
  • continues to Wait on Module Sync.vi, which waits until a second task arrives at the “Module Sync” rendezvous [A]

[A] Start Module.vi needs to wait until the broadcast event references have been created by the module.

• Main.vi

  • executes Init Module.vi, which creates both the module's broadcast event references and the request event references

• Main.vi continues to start Event Handling Loop (EHL), Message Handling Loop (MHL), and any Helper Loops (HL; optional)

• Main.vi enters the “Initialize” case of the MHL

  • executes Synchronize Caller Events.vi

    • Wait on Module Sync.vi adds the second task to the “Module Sync” rendezvous

      • Start Module.vi now continues execution
    • Wait on Event Sync.vi waits until a second task arrives at the “Event Sync” rendezvous [B]

[B] The module needs to wait until the calling code has registered for the broadcast events.

• Start Module.vi returns the Broadcast event references

• The calling VI registers for the broadcast events

  • The caller will receive any broadcast sent from this point (creation of the registration) in time onwards

• The calling VI executes Synchronize Module Events.vi

  • Wait on Event Sync.vi adds the second task to the “Event Sync” rendezvous

    • In the Main.vi's “Initialize” MHL case, Synchronize Caller Events.vi now continues execution
  • Both rendezvous references are now closed.

The caller is now finished with starting the child module

• In the “Initialize” MHL case of the Main.vi, Synchronize Caller Events.vi now returns and the rest of the code in that case is executed.

• Once the code in the “Initialize” MHL case has finished executing, the Module Did Init.vi broadcast is sent.

The child module is now finished with starting

• The Caller can choose to register to this broadcast for added synchronization.

Any rendezvous functions mentioned above will wait for the module timeout defined in Module Timeout–constant.vi (default = 5s) before returning an error.

It becomes apparent that 2. Continue to MHL in the schema shown above is the critical path. If any code is placed before the MHL starts (i.e. before Synchronize Caller Events.vi inside the “Initialize” case) which takes longer to execute than the module timeout, the startup process of the module will fail.

Make sure to also browse our HSE Coding Conventions on Parent/Child Modules.

• Ie not from another DQMH Module. One example is the API Tester.

• Child module is started automatically when starting the parent module
• Adding code outside of EHL/MHL (see Caveat above)
• Risk of timeouts → not recommended by HSE

• Child module is started via a request [1] by adding code to the EHL
• EHL (producer) now contains code that should ideally be placed in MHL (consumer)
• Code potentially blocking the EHL → not recommended by HSE

• Child module is started inside MHL, can be triggered via request or simple Queue message [1]
• Forking the registration reference wire so we can update the event registration of the EHL in the MHL
• Potential confusion about forked registration wire - not recommended by HSE

• Child module is started inside MHL, can be triggered via request or simple Queue message [1]
• Using a private request and wait for reply to let the EHL register while executing the MHL case
• More implementation work but little technical debt → recommended by HSE

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 State Machine.

• Our 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)