• https://delacor.com/dqmh-documentation/dqmh-best-practices/

• Exclusive error range per module (see HSE Error List)

• Embrace the “Queued Message Handler” architecture

  • Implement functionality in Message Handling Loop (MHL), not Event Handling Loop (EHL)

• Don't add code to the Initialize case

• Embrace .lvlib best practices

  • Keep all VIs belonging to a module inside its .lvlib

    • this avoids naming conflicts etc.
    • makes it easier to reuse code
    • makes it easier to understand architecture
  • Scan for loose VIs in same folder as lvlib

    • Create a project and add the folder
    • Project structure should only show files inside lvlib and the tester(s)
    • Other VIs should be either added to library or deleted from disk.

• The Main.vi is the only element on the root level of the module .lvlib. All other VIs and files reside in subfolders (see next point)

• Put all self-created VIs into /SubVIs/ folder (both on disk and in .lvlib as virtual folder)

  • Helps separate scripted/generated VIs from self-created ones
  • Mark the /SubVIs/ virtual folder as private access scope

• If a VI is created to contain everything inside of a single MHL case, then add –MHL to the name

  • eg Start Test–MHL.vi for the “Start Test” MHL case

• Put private (VI-local) requests into a virtual folder called “Private API” and either “Request” or “Broadcast” virtual subfolder (similar to the “Public API” folder)

  • make the folder private
  • add a “private” key glyph to the request VI's icon

• Be careful when adding code outside the MHL and EHL, especially adding code that needs to be executed before entering the “Initialise” case of the MHL. If that code takes too long to execute, the module initialisation will time out and throw error 403683 (“Module was unable to synchronise events”).

• Make sure that if a module starts another module, it also takes care of stopping it again.

• Ensure that for any module that's started, there is a place collecting status and error information from that module. Usually, the module starting another module registers for that other module's broadcast events and handles (or forwards) at least the “Error Reported” broadcast accordingly.

• Start and stop your modules inside the MHL (or helper loop) instead of outside/before entering the EHL and MHL (see above for an explanation). Prepare the event registration for the datatypes of the modules you want to start and register for (see below), and then trigger the actual start and register process later on, after your module has finished initialisation.

  • prevents the module synchronisation from timing out if starting the modules should take too long
  • gives you control over when exactly to start modules
  • conveys intent through the code itself

• Version 6.1 and later: Use the new VI Null Broadcast Events–constant.vi for preparing the event data type when creating the event registration reference. Then use either the Start Module.vi or the Obtain Broadcast References for Registration.vi for actually registering the real references at runtime
  

• Pre version 6.1: When registering for other modules' broadcast events via a constant (as in, not via the “Obtain Broadcast Events for Registration.vi”), make sure to label the constants accordingly to end up with proper event names like “<MODULE NAME> Broadcast Events.<EVENT NAME>”. This will allow scripting tools to programmatically find and document those event cases
  

See 12 Helper Loops

• In MHL, leave “Variant to data” and optional “Send Notification” on block diagram of main.vi, outside subVIs

  • separate DQMH code from module-specific code

• DQMH modules have to have a colored Icon badge so VIs are better discernable

  • see colors section in Coding Conventions

• Broadcast VIs get a specific glyph on their icon to separate them from request VIs

  • see glyphs section in Coding Conventions

• Store data inside the MHL's data cluster on the shift registers, do not create FGVs for data internal to the module

• Remove the #DQMH Code Recommended comments once the code has been added (or if no code is to be added)

When generating a new request with reply, the arrangement of code is as follows:

We improve this code by:

• Shortening the error cluster in reply to just “error”
• Building reply message inside the “Send reply?” case structure
• (optional) merging errors only if we want this DQMH module to deal with errors, not its caller

After these changes the MHL should look like this: