Over the last few years, we not only used DQMH very heavily, we also started building additional features around the DQMH core.

This page describes the HSE-specific modifications and additions to the DQMH code, which include:
- our collection of (more or less useful) HSE Libraries (*)
- DQMH modules build for various specific needs
- a UI framework for applications with Graphical User Interface

(*) The hse-libraries are the most basic building block of our templates and reuse libraries: A collection of useful VIs and libraries, without a proper (stand-alone) use case on their own. Many of the features described here are built on VIs hosted in the hse-libraries repository.

These VIs are not part of the DQMH default features and have to be implemented manually in every HSE DQMH module.

Combines Start Module.vi and Synchronize Module Events.vi. Wrapping these allows to programmatically start any module (by use of call by reference) as the module-specific connector panes are hidden away.

Encapsulates the module-specific Obtain Broadcast Events for Registration.vi and only returns the default broadcast event references that any HSE DQMH module features. Wrapping the VI allows to programmatically obtain the default event references as the module-specific connector panes are hidden away.

Event references returned are:

• Status updated
• Error reported
• Module Did Stop
• Update Module Execution Status
• System Message (HSE-specific event)

These events are not part of the DQMH default features and have to be implemented manually in every HSE DQMH module.

Sends a HSE-generic broadcast message, consisting of an Identifier, a variant Payload and Source information.

• Provides a generic way of broadcasting information
• Allows for dynamic registering and triggering of broadcast events

• string Identifier
• variant Payload
• enum Source Type (module, application, network)

  • the typedef can be found in hse-libraries/hse-dqmh.lvlib/Templates and Controls/System Message Source.ctl
• string Source Name (Module Name)

  • for clones, the Clone ID is appended to the Module Name

These events are not part of the DQMH default features and have to be implemented manually in every HSE DQMH module.

Triggers the auto-configuration of the module.

• Lets the module configure itself
• The connector pane has to be generic (i.e. only error in / error out) so that this VI can be called dynamically
• The default behaviour of the 'configure' MHL case is to read the module's configuration data from the configuration directory (see Project Structure and hse-configuration for details).

Prepares the module for displaying its front panel.

• used by our Windows Application Template to automatically let a module know when its front panel is about to be displayed so the module can prepare (reset controls etc.)

These events are not part of the DQMH default features and have to be implemented manually in every HSE DQMH module.

Requests a module to display its UI as specified in the parameter Scenario. The module can either ignore or accept the request.

If the requested scenario is “stand-alone”, the module simply shows its front panel as a new floating window. If the requested scenario is “managed”, the FP is inserted into a subpanel of PROJECT_Layout-VI.vi (no new window pops up).

For the “managed” scenario, the module will send a System Message broadcast with the Ready for Display message, which will be processed by the UI Manager module. To easily create the correct broadcast, the VI hse-dqmh.lvlib:DQMH System Message - Ready for Display.vi is proposed to be used. More details can be found at the HSE Windows Application Template project.

• Main VI Reference: VI reference to the VI that wants to be displayed. Usually the “Main.vi”.
• Title: The title (e.g. module name) that should be displayed in the app header.
• Target SP Name: Name of the subpanel in which the front panel should be inserted. Default is “SP_Content”, the default subpanel from the HSE-App-Template.

Note: The connector pattern shown above is also necessary for DQMH 5.0, which introduces new connector patterns for Request and Wait for Reply events.

The API Tester of any given HSE DQMH module will come with the following additions to the default DQMH API tester:

In order to be able to launch the API tester programmatically from our UI Framework, it's necessary to make the VI show its front panel when called and close it afterwards.

• make good use of space

• start and cleanup hse-application class
• don't stop while loop in error case, but use a logger
• handle only errors after while loop has stopped
• have atomic cases for configure, prepare and display
• implement standard display for System Message Broadcast Event
• implement standard display for Logging Event
• implement case for global shutdown event

• do not rename the boolean constant in the “Panel Close?” case labeled “Discard?”

For the API tester to be able to start a module that depends on the various HSE Libraries helper functions (eg hse-application, hse-configuration or hse-logger), the API tester needs to initialise the HSE Libraries first.

hse-dqmh.lvlib:DQMH Tester Prepare hse-appl.vi

hse-dqmh.lvlib:DQMH Tester Cleanup hse-appl.vi

• Buttons for calling the “Configure” and “Prepare” events

• DQMH Module Path: Tbd.
• DQMH Disk Path: Tbd.
• …