DQMH Singleton Module vs Cloneable Module Overview

A Singleton DQMH module can have only one instance of its Main.vi running at any given time. Every time theStart Module.vi is called, the same DQMH Main.vi instance is used.

A Cloneable DQMH module can have one or multiple instances of its Main.vi running in parallel. DQMH 3.0 added code for cloneable modules to be executed as singletons. If the cloneable is running as a singleton, the same instance will be returned every time Start Module.vi is called (Module ID = 0). If it is running as a cloneable, the cloneable module assigns a new Module ID number to each new instance that is started when calling the Start Module.vi.

The calling code needs to provide the Module ID as an input to every request and broadcast VI. The event structure inside the EHL in the cloneable DQMH Module Main.vi has to determine if a request event was sent specifically to that clone before enqueuing the message to the MHL. A Module ID value of -1 means that the event was intended for all instances of the cloneable module.

Image

A cloneable DQMH module library has a folder called Multiple Instances; this folder contains the Action Engine that manages the different instances of the module.

Image

  1. The cloneable DQMH module comes with a group of VIs to update a Module ID ring that can be used in the Tester or in the Application code to address the different instances of the module.

  2. Since the DQMH Module Main.vi owns the lifetime of the request and broadcast events, code is needed to determine if the first instance can close. Before stopping, the DQMH Module Main.vi checks to see if it was the first instance of the module that was launched (and hence, the owner of the event references). If it was the first instance launched, then the module will exit both EHL and MHL loops and hold in the Close.vi waiting for all the other instances to close. The VI continues to run (with its panel hidden) until it is the last instance running, at which point it destroys the event references and stops.

  3. The Clone Registration AE.vi is the action engine that manages all the DQMH cloneable module instances.

  4. These VIs are the public API for the Clone Registration Action Engine and are used for the following tasks:

    • Initialize the clone registry

    • Add a new clone to the registry

    • Remove a clone from the registry when it stops

    • List all the available clones

    • Check if a module was the first clone to be registered

The Clone Registration functionality resides in a library with a Public API, which allows the developer to implement the registry with a different underlying mechanism besides an action engine if she so desires.

  1. A simple tester is included to verify that the Clone Registration AE.vi works as expected.

  2. DQMH 5.0 modifies how the DQMH modules are launched. DQMH now uses Start Asynchronous call instead of the Run VI Method. This change adds a VI Reference Management which is another action engine that manages the lifetime of the VI reference. Open VI Reference requireshttps://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kGHeSAM&l=en-US[root loop access.]By keeping VI reference open, subsequent calls to start module for that cloneable module do not require root loop access.

  3. DQMH 5.0 replaces the code that used to wait for the last clone with a named notifier. This notifier fires when the last clone running stops. Clones share their DQMH event references. The first DQMH clone to start owns the event references, and when it stops, it waits until the last clone stops before destroying the shared references. See point 2 above.