Find out more details at the Release Notes for DQMH 5.0

Release notes for previous DQMH versions

We will cover the major features here:

Upgrading your existing code created with previous versions of DQMH to DQMH 5.0

  • The best way to identify how the new features in DQMH 5.0 affect your existing projects is to validate them. The Validating an Existing DQMH Module section includes a video demonstrating upgrading a DQMH project created with DQMH 4.2 to DQMH 5.0.
  • DQMH 5.0 prompts the developer to run the validate module tool right after upgrading DQMH via VIPM
  • Added the ability to validate all modules in the project. We also added a VI (Validate DQMH Module (Headless).vi that you can pass in a project path and it will programmatically validate all modules in the project and return a result. This VI could be used as part of CI/CD process to validate DQMH modules.
  • Added a button to the Validation Results UI that allows you to analyze another module after you are done viewing the results for the current module. We also added a button to the "all tests passed" dialog to allow you to validate another module

Changes to the way we start DQMH modules

  • 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 an action engine that manages the lifetime of the VI reference. Open VI Reference requires root loop access. By keeping VI reference open, subsequent calls to start module for that cloneable module do not require root loop access.
  • 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.
  • DQMH 5.0 now supports both Singleton and Cloneable modules in Real Time

API Testers

  • Improved API Tester developer experience: The API Tester does not stop the module on exit if it was already running when the API Tester started running. This is useful when using the API Tester as a sniffer

Request and Wait for Reply

  • Request and Wait for Reply now returns an error if the reply times out

DQMH Templates

  • If your custom DQMH template requires a different enqueue (for example for a DQMH Queue child or if the DQMH libraries were built into a PPL), we added the ability to specify a custom enqueue message VI to be scripted into the MHL when creating request events