DQMH Consortium Toolkits Feature Requests

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.

Hi,

Most of the time we create multi-layer applications, and bottom modules need to share information that might have to cross several upper layers.

To avoid coupling and jumps between any non-adjacent layers, we have to create similar broadcast in the parent modules to repeat child broadcast one layer upper.

It would be interesting to have a utility that 'copies' an existing broadcast from one module into another.

And maybe have an option to code the forwarding :

1. automatically register for child broadcast in the parent if not done already
2. in the selected braodcast EHL case, map broadcast arguments onto parent broadcast VI inputs

I guess the same thing can be done when the communication needs to go down the layers, and therfore applied to requests.

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.

It would be awesome if the DQMH validation tool could go back more than one version.

eg.  If you open an old piece of code (that was written in say DQMH 4.2), the only way to upgrade it to 6.1 is to one version at a time, upgrade the code step by step.  This would mean the following:

 - Install DQMH 5.

 - Run Validation tool

 - Install DQMH 6

 - Run Validation tool

 - Install DQMH 6.1

 - Run Validation tool

This is a rather painful process, and when faced with this, I have decided to simply implement the module again starting from the latest version, and porting the code over rather than go through that.

Neither approach is obviously ideal.

We really need a tool that can convert an older module up to the latest standard.  This will become a more common problem now that we have DQMH-based code out there from 2018 onwards.  The more people use it, the more this problem will surface.

I have 'barebones' singleton and cloneable module templates that I always use when creating new DQMH modules for projects. I started with the shipping module templates and removed:

- 'Do Something' events

- All #Bookmarks

- Simulate EHL/MHL error buttons

I propose DQMH ship with these simple module templates. They help save several minutes when creating a new module. I'm not suggesting changing the project template, but rather simply adding two new options in the Add New DQMH Module drop-down:

I'm open to suggestions for different names. 🙂

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.

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.

Credit goes to doyles for initially coming up with this idea.

Go here for previous discussions:

https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Feature-request-Automate-the-Helper-Loop-creat...

1. Include a "checkbox" onto the Add New DQMH Module dialog panel that is labelled "Include a Helper Loop"
   
    

   

    

2. If the user checks this checkbox, a helper loop is automatically added to the Main.vi
3. The helper loop would not be a sub-VI, but simply a third loop on the main.vi block diagram.
4. A Wake up Helper Loop request is automatically created and included in a Private Requests virtual folder
5. Make the helper loop generic as per Sam's suggestion. My suggestion is to have three user events: 1) Timeout 2) <Stop Module> 3) <Wakeup Helper Loop>
6. Label the additional "Register for Events" node something different from the other "Register for Events" node, ie. DQMH_REG_EVENTS_HELPER_LOOP (so that the Validate tool does not raise it as an issue)
7. When generating a helper loop for new cloneable modules, ensure that in the "Wakeup Helper Loop" and "Stop Module" user events, that the Addressed to this Module.vi is used.

Today when an event is removed, no special actions are done in the testers and a 'manual search' has to be done in the module's main VI.

Here is what is suggested in DQMH help :

• In the case of a Request:
• In the Tester VI:
• Open the block diagram and find the event frame configured to test calling this request.
• ...
• In the DQMH Module Main.vi:
• Open the block diagram and find the event frame configured for this request (It might no longer be listed and instead say something like “Unknown Event (0x0)”).
• ...
• In the case of a Broadcast:
• In the Tester VI:
• Open the block diagram and find the event frame configured for this broadcast. (It might no longer be listed and instead say something like “Unknown Event (0x0)”.)
• ...
• In the Module Main VI:
• Open the block diagram and find the places where the broadcast VI is called and remove it.
• ...

It would be nice to attract dev eyes on the places where modifications need to be done post event-removing.

Maybe adding a comment like this would be enough ?

It is not much, but the comment color and hashtag would ease the 'finding' process.

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.

IMHO, it would make more sense to have the Stop Module request at the same level than Start and Sync functions.

The problem I want to fix:

I want to be able to try to fix or poke the code more when an error occurs in the API Tester. The opportunity of going to the block diagram or attempting to send a different request goes away because the API Tester, by default, closes when an error occurs.

How I propose fixing it:

The first thing that I change on an API Tester at the first error is to remove the OR connected to the stop terminal in the loop and add an error indicator at the end instead of the Simple Error Handler and connect a local variable for the error. Would you please vote to have DQMH do this by default and have a validator to modify existing API Testers?

Current API Tester:

Proposed change:

Thanks,

Fab (yes, being the DQMH Lead Architect does not guarantee that all my wishes are turned into reality 😉 )

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:

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.

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