DQMH Consortium Toolkits Feature Requests

I’d like to suggest making the DQMH scripting tools API public. This would allow new events or modules to be generated programmatically.

My use case: I’d like to take any non-DQMH library and generate a DQMH layer for the library’s public API. With some clever coding and discipline, this could automate the creation of a TestStand API based on DQMH, which would be incredibly useful.

Moreover, public APIs often encourage the development of supporting tools and promote the technology, especially within creative communities.

Many DQMH developers (including myself!) encounter the stumbling block of firing requests before a module is "ready". We assume that the following code is sufficient for starting and synchronizing a module:



The 'Synchronize Module Events' VI ensures that request event references are valid, but it doesn't do anything about ensuring that the module is actually ready. One very common scenario is a module Main VI that includes code in the 'Initialize' frame of the MHL that fires private events to initialize Helper Loops. If the VI that called Start Module isn't waiting on the Module Did Init broadcast, then it could immediately fire a request after calling Synchronize Module Events, and if a helper loop is registered for that event, then helper loop could run the event frame for that fired event before the MHL has had a chance to fire the private event to initialize the helper loop. There are many other possible pitfalls, but this is one of the more common ones I've seen.

To solve this issue, I think DQMH should ship with a Public API VI that is a wrapper for Start Module + Synchronize Module Events, but includes the extra step of waiting for 'Module Did Init'. The module author needs to ensure that the Module Did Init broadcast is called after all necessary initialization code... if they do so, then it is "safe" to begin calling events externally.

Here's my proposed interface for the Start Module and Wait for Initialization VI:

And my proposed implementation:

If this VI shipped with the DQMH singleton and cloneable module templates, it would help us avoid module synchronization + initialization issues like what I describe above.

When creating a new DQMH event, I'd like this

When the DQMH Consortium introduced the support for private requests with DQMH 7.0, a conscious decision was made not to support synchronous requests with reply, to avoid dead-lock scenarios.

With the way we at HSE start additional DQMH modules from any given DQMH module (by sending a request from the MHL to the EHL to start and register for modules, then reply back to the calling MHL case, so the whole process becomes synchronous), it would be super helpful if we could script those private "start submodule" requests the exact same way as all other private requests.

TL;DR: Add support for private Request and Wait for Reply.

Edit: After internal discussion, let me add that I know how to make a regular request a private one by setting the access scope. I don’t want to do that - I want the private Request with Reply to be the same as all other private events, and not a modified public request.

Edit2: If you scroll down, you'll see that Manu added a vital piece of information. We usually communicate with one of the EHLs/Helper Loops, not the MHL. So scripting should not create another case in the MHL but keep the reply in the targeted EHL/Helper Loop.

When creating a new Event, it would be empowering to be able to automatically call a VI immediately after the scripting completes. The idea is based on the behavior of the Pre- and Post-Build VI calling ability of the application build process. The implementation should provide an option to specify a VI to call and an option to generate a VI with the proper controls already on the connector pane. A proposed set of such controls would be VI references or paths to the Event VI or VIs (Broadcast or Request... or both for Round Trip) and VI references or paths to the Tester VI and RT Tester VI (if there is one).

Adding the feature would allow developers using DQMH to create their own extensions to the built-in scripting. For example, if the other feature request here is not accepted, this one would allow a developer to implement it on our own.

Today DQMH scripters add comments with specific hashtags. But some of these hashtags names are very generic (for example #CodeNeeded or #CodeRecommended).

Adding a 'DQMH_' prefix would allow a better isolation of DQMH related hashtags in the bookmark manager (ie. #DQMH_CodeNeeded).

Actually some DQMH tags already have this prefix (#DQMH_HowTo).

For some reason I need to know the module name of the module that I start.

Module name constant is a private VI and therefore cannot be called in a cller VI diagram.

Having the Start Module VI returning this information could be useful (instead of specifically creating a R&R just for this purpose).

Today when creating adding a module template it is not possible to set a 'human readable' name for template.

The template name is the module's library name. Having a field to specify a more friendly name could be useful (could be set by default withe the module's library name though).

For DQMH modules written prior to DQMH 7, helper loops will unlikely have the "DQMH_HELPER_LOOP_NAME" string constant wired to the error helper VI as shown below.

This idea is to propose a new test be added to DQMH Validate Module to check that all helper loops have this string constant present.

When preparing a project for Lumos tracking...

Lumos adds "Trace VIs", when migrating this code to another PC without Lumos installed
When opening DQMH module it asks for all the "Trace VIs" and breaks the code...

It be great to have another option to Remove or Un-prepare project for Lumos Tracking and be able

to distribute this code without Lumos installed

Thanks! Great tool!

I am aware of the note that is being shown on the "Remove DQMH Event" that states: 

" NOTE 2: You cannot remove the last private event from a DQMH module. Once a private request has been created, the module requires at least one private event to be present." 

The request i believe would come in handy, is that instead of "hiding" or "not showing" the one and only private request, to instead show it as available for deletion, and when pressing OK, populate the information on a popup that shows what NOTE 2 said. 

This with the objective of not giving the user the notion that DQMH scripting tools are broken, especially the ones just beginning to use DQMH.

When you create a new cloneable module from the default Cloneable, it creates the new module which includes the following automatically created libraries:

 1) VI Reference Management

 2) Clone Registration

However these libraries do not have a description.  Could we please add a description to these for the next DQMH release?

Main reason for this request: We have an inhouse tool that finds all libraries/classes/VIs/ctls that do not have a description and then allows the user to edit these in one place. These two libraries keep showing up in the list for each DQMH module.

In DQMH 7.0 you can create private requests now. This is a feature that I really like and the more you use something, the more ideas come to you.

In my current project I created a private request and shortly after I realized, that I need to call this request from another module. I tried to convert the private request into a public request, but this wasn't easy.

So here comes my idea: why is the conversation (public requests → private requests and privat requests → public requests) not included in the Convert DQMH Events dialogue? That would be the place where I would intuitively look for it.

Everytime I create a new request to a DQMH cloneable module I always end up connecting the Module ID terminal to the new request added to API Tester, please add an additional scripting step to connect this terminal automatically

Hi,

This might be a special use case, but maybe there are more applications for a cluster of event registration refnums for helper loops.

My use case involves DAQmx or IMAQdx events. These events get registered through a DAQmx or IMAQdx reference, like this:

The register for events for the helper loop is happening before the loop and the task is started, which means that registering to the "Done" event of the task doesn't work if done like this:

Because there is no valid task reference yet, so the event registration gives an error.

What works instead is the bundling of the "Module Request Events"-event registration refnum with a static event registration refnum of the task "Done" event. 

Inside the helper loop, at a point where the task has been created, the event registration for "Done" event can be updated.

This works very well and simplified my code, which before had another async VI which registered to the daqmx event and sent a broadcast to the helper loop. This is much nicer. 

The drawback is that the DQMH event scripting tool does not support the extra namespace ("Module Events") of the clustered event registration refnums. This results in that every time the Module Request Events get updated the assignment of events to in helper loops event handler gets broken and they need to assigned again manually.

This happens when any kind of request is created. If the request is created for the helper loop this error appears:

This is how my helper looks like after assigning the events again:
(using just a bundle instead of bundle by name for space reasons)

Proposal:

Addition of check to request (and broadcast) creation, that when a helper loop exists and  the event registration refnum for the request events (and probably also the broadcast events) is bundled in a cluster with some other event registration refnum, the extra namespace (eg "Module Events") gets handled and the events can be created and assigned.