DQMH Consortium Toolkits Feature Requests

This is a blatant copy of an idea from 2021, but it came up in a recent customer meeting.

While I agree that modifying event arguments is possible to do manually, can we take another look at automating that?

Right now if an argument is added to / removed from the typedef, it requires the developer to manually perform a series of (scriptable) actions:

1. Open the public event VI
2. Create a new control or indicator OR remove existing
3. Expand the bundle/unbundle, and wire it in OR collapse the bundle/unbundle to get rid of the deleted argument(s)
4. Wire the new item to the conpane and set it to Required (in the case of a control)
5. Update the EHL case to make sure the cluster is properly bundled (can be checked by the validator)
6. Take care of updating the Tester

So here we have a multi-step process where things could be easily forgotten. Order of operations matters. The steps are well defined. The activity is dull. It feels like a good candidate for automation.

Using DQMH 7.0.1.1316 (currently the latest version), the error message generated inside the Default case of the Message Handling Loop is "The invalid message string "%s" was received in the Message Handling Loop for module "%s"."

"The invalid message string "%s" was received in the Message Handling Loop of module "%s"." might be a small improvement.

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

I would like a new option in the DQMH-> Event menu and two options within that sub-menu for changing the scope of request events.

A new Change Request Event Scope sub-menu with the following options:

And the following options within that action:

1. Change Request event from Public to Private
2. Change Request event from Private to Public

This would be helpful for properly scoping events in projects that are inherited and all events are set to public.

Thanks,

Scott

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

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!

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.

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.

When I first saw the auto-generated VIs in the DQMH framework, I was surprised at how chaotic they looked, despite being automatically generated. I thought, "Alright, it’s auto-generated anyway, so there's no point in worrying about it." However, it kept bothering me. Eventually, I decided, "I’ll replace the template with one where the elements are better organized, and I can also add a few small modifications of my own."

However, when I tried to do this, I realized that the templates didn’t include stubs for everything, and what was generated from scratch covered much more than I had expected. This completely disrupted my plans.

Therefore, I would like to request a modification of the generation process so that the templates include more stubs, which the generator replaces in a more predictable manner. Additionally, I’d appreciate clear documentation that would allow me to customize the template without risking breaking anything. Perhaps I’m mistaken, but I don’t think there are that many possible combinations in these templates?

I’m most interested in the request templates, but I believe the idea could be generalized to other cases as well.

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.

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.

Greetings from France

be able to upgrade the module type, for example singleton type to cloneable type, would be a great feature.

menu -> DQMH -> Module -> updgrade

A+

Luc