DQMH Consortium Toolkits Feature Requests

When adding an helper loop from the scripter, add a checkbox that would allow creating a subVI that contains the helper loop.

This checkbox should be unchecked by default.

If checked, a (private) VI is create and contains the helper loop.

The subVI is then dropped inside the Main.vi where the helper loop would have been created.

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!

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.

As shown by Olivier Jourdan at GLA Summit 2024, the current implementation für the Helper Loop timeout case does not "guarantee" a consistent periode between timeout case executions. Since there is already a very sleek solution with the Wovalab Utilities, I would suggest integrating it into the DQMH Helper Loops. Especially now that we have private requests and helper loops in the scripting tools, DQMH users are more encouraged to use them.

Screenshot taken from the Wovalab Utilities example to show the difference bettwen the current implementation and the more consistent one.

All DQMH modules come with a Module Timeout--constant.vi:

This value defaults to 5 seconds, but I've worked with many modules over the years (usually having to do with serial devices) where this value is modified. I find it tedious to have to dig into the timeout VI any time I want to find out what the timeout actually is. Especially when I'm working with multiple modules at the same time that may have different (legitimate) timeout values. So I propose the following:

1) The default modules that ship with DQMH should include the timeout value in their icons:

2) There should be a Validate test that ensures the Timeout VI icon displays the correct value, and provide a fixer that will update the icon if it does not.

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.

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

Currently on the block diagram of VIs that implement Request events, the Bundle By Name node and associated typedef cluster constant are located outside of the case structure, even though their output is used only by the False case of the case structure (and not by the True case). The screenshot below shows the unmodified "Do Somthing.vi" VI.

The code would be slightly cleaner if the BBN and typedef constant were moved inside the False case of the event structure. This follows the clean code rule that if an action is relevant only to one case of a case structure, then it should be located inside that case. The code would then look like below.

Thanks!

Hi,

The idea is to add a converter that would allow a 'plain' (standard) module to match a template.

Let's say I've got a Singleton module that contains logic a defined Public API and a template named MyVeryOwnSingleton.

I'd like the public API + MHL cases + helper loop of the Singleton module to be 'copied' into a new (?) module based on MyVeryOwnSingleton template.

A the end, I'd have a 'MyVeryOwnSingleton' module that exposes the same API as defined in the origin module + helper loop + MHL cases prepared.