DQMH Consortium Toolkits Feature Requests

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.

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

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.

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.

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.

This feature request is adding to the already existing "Private Request" and "Helper Loop Creation" requests (or not?):

When working with helper loops in cloneable modules, it would be nice to have a way for sending messages from the MHL to the helper loop which doesn't need the module ID, and which doesn't interfere with other clones' helper loop timings. I'd still like this new mechanism to look and feel like the regular events, with all the scripting and other goodness.

Maybe instead of calling them private events, a better name would be "local" events (which would, of course, be set to private scope).

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.

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 😉

Please add a test to the Validate Module tool:

Find all while loops in the Main.vi of the specified module(s), and check if the DQMH Error Handler - Helper loop.vi is used to handle errors in each of the while loops, and flag it if not.  Ignore the default EHL and MHL in this check.

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:

By default, in the MHL Error case, the "error out" local variable is written to.  But the error that is written is NOT the error that came into the MHL Error case!

I propose the above be changed to this:

By doing this, the actual error that was raised by the module will be copied to "error out"

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.

Let developer create own DQMH validation test which allows them to test company specific style and scripting.

At that point, it would although be great to store a test configuration. E.g. which tests should be executed and which severity a failing test hast. 

When you update the DQMH version, you can have hundreds of failures to fix in your projects (not because everything is broken but just because, for example, a new feature requires updating a VI).

A fixer is available most of the time, and you just have to click the button to make the code change.

For me, the UX issue is that after you hit the fix button, you need to select the next failure with your mouse and then click on the fix button. I'm not too fond of this kind of mouse gymnastics.

My proposition: If the fix is successful, the next failure could be selected automatically.

The fixing process would be significantly improved.