DQMH Project Structure Overview


The Delacor QMH project template (available in the Create Project dialog launched from the Getting Started window) has the following components:

  1. Testers that exercise the public API of the DQMH modules in the project. The Testers register for the broadcast events fired by the DQMH Module Main.vi and fire request events that will be acted upon in the DQMH Module Main.vi.

  2. Each DQMH module has its own project library (lvlib). This facilitates having the same icon header for all the members of the library and specifies which VIs are public and which VIs are only used by the library itself.

  3. Each DQMH module has a Public API virtual folder that lists the VIs that can be called by VIs outside the library.

  4. Within the Public API folder there is a Requests virtual folder that lists all the VIs wrapping the firing of the requests that can be sent to the DQMH Module Main.vi

  5. In order to start a DQMH Module, two VIs need to be called: Start Module.vi and Synchronize Module Events.vi. These two VIs take care of launching the DQMH Module Main.vi as well as making sure the DQMH Module Main.vi has created its own request and broadcast events before the calling VI can fire or register to listening to broadcast events.

  6. The Obtain Broadcast Events for Registration.vi can be used when the calling VI is not ready to start the DQMH Module Main.vi or it expects the DQMH Module Main.vi to have been started by another module. The Obtain Broadcast Events for Registration.vi will have the broadcast events if the DQMH Module Main.vi has already started or it will have empty references and it can be used to declare the event reference type for registration.

  7. Null Broadcast Events–constant.vi. This constant vi Returns the broadcast events cluster with null references for defining the event types in a Register For Events function.

  8. The DQMH Module Main.vi is a private VI. This encourages developers to use the public API to interact with the DQMH module.

  9. The calling code can be another library or simple VIs. In the DQMH project template a Simple State Machine application is used to call the singleton and cloneable DQMH modules.

  10. The Build Specification for an executable that uses Application.lvlib:Main.vi as the startup VI.

The DQMH Module Main.vi creates its request and broadcast events to ensure that even if the calling VI leaves memory the references are still valid. This feature of the DQMH module facilitates calling the DQMH modules via TestStand as well as easily defining the lifetime of a given module’s event references. The combination of Start Module.vi and Synchronize Module Events.vi ensures that the DQMH Module Main.vi is ready to receive requests and the calling VI is ready to receive broadcasts.

  • The code that calls the DQMH module can be very simple, not even needing an event structure (especially if the calling VI does not care about broadcast events or is only calling request and wait for reply events). Refer to the Thermal Chamber Control example available from the Help>Find Examples…>Directory Structure>Delacor>Delacor QMH>DQMH Fundamentals – Thermal ChamberDQMH Fundamentals – Thermal Chamber.lvproj >> Thermal Chamber Controller.vi for an illustration of this approach.

Thermal Chamber Control example shows that calling code can be simple.

If the DQMH Module libraries are locked (right click the module .lvlib and choose Properties>Protection), only the public VIs appear in the Project Explorer window. This can be useful when sharing code with other members of the team to highlight the VIs that they will be using in calling code.