DQMH Consortium Toolkits Feature Requests

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.

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 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).

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.

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.

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.

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

This is more of a question or request for comments than an actual feature request:

In the dialogue window for creating a new DQMH module, should we rename the caption "Module Type" to "Module Template"? For a vanilla installation of DQMH, there are only two templates to choose from (Singleton and Cloneable), so the caption makes sense. Once you start adding your own templates, not so much anymore. Also, for documentation purposes, it would make things clearer if we separated the term "type" from the term "template".

In addition, it would be nice to see the actual type of the module (singleton or cloneable) added to the name in the dropdown list (see screenshot).

Opinions?

In many cases I launch the cloneable instance(s) and launch the API tester on demand. In this case the API tester doesnt show if any instances are already running, I need to press the refresh button which I forgot in most of the cases. Other developer not that familiar with DQMH forgot it all the time causing confusion.

I have fixed this in the template module we use for cloneables:

When creating a new event for a module and my project contains numerous modules, finding the correct module in the list can be somehow painfull.

Listing the DQMH modules in alphabetic order would help finding the correct module faster.

There is an option to convert Requests to Request and wait for reply but requests can not be converted to Roundtrip, so a broadcast has to be created manually with payload identical to the Request. Creating a Broadcast is not much of a deal but having two identical payloads is not ideal especially if the payload bundles multiple typedefs.

As mentioned in DQMH Forum: VI Reentrance issue VIs which are required to be non-reentrant are not reported from the DQMH validation tool if they were changed (e.g. to shared clone)

Some of the important VIs which should be reported:

• Obtain Broadcast Events.vi
• Obtain Request Events.vi
• Clone Registration AE.vi
• Start Module (is already reported)
• Basically all used FGV's

Steps to reproduce:

1. Create Project with a new clonable module
2. Change all non-reentrant VIs to shared clone
   

    

3. Run module validation and execute fix
   1. Start Module.vi will be updated and changed
4. Rerun module validation
   1. No issues reported

We are constantly having deployment errors on RT targets, mentioning the Simple Error Handler. Since on RT Targets that function is useless anyway, we've put a conditional disable structure around. This solved the error.

It would be nice, if that CDS would be added to a standard DQMH module.

Today most of our screens support a 1920x1080 resolution.

And the actual space that I can basically use in the MHL is 530x315 pixels (roughly, surface of the MHL minus subdiagram comment).

Which means that my useful coding surface is only 30% of my screen resolution.

I guess the EHL and MHL can be designed wider so that we have more space for our custom code.

When validating a number of modules and going through the list of fixes, it's sometimes hard to keep track of what has already been fixed.

It would be nice to have some information on which failures were already fixed, and whether the fix was applied successfully or if there were errors or if there's a need for manual work.

I just put some icons into the screenshot to illustrate my idea - my feature request asks for a prettier implementation 😉

When adding a new event, I think it would be really nice if the scripting code that adds the new case structure case to the main VI also scans the event description for formatting tags, and then applies them to the new case's subdiagram label. That way the subdiagram label will be formatted exactly the same way as it appears in the VI documentation. For those of us who adhere to the convention of bold facing control names as we mention them when writing VI documentation.