DQMH Consortium Toolkits Feature Requests

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.

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

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

When creating a new Event, it would be empowering to be able to automatically call a VI immediately after the scripting completes. The idea is based on the behavior of the Pre- and Post-Build VI calling ability of the application build process. The implementation should provide an option to specify a VI to call and an option to generate a VI with the proper controls already on the connector pane. A proposed set of such controls would be VI references or paths to the Event VI or VIs (Broadcast or Request... or both for Round Trip) and VI references or paths to the Tester VI and RT Tester VI (if there is one).

Adding the feature would allow developers using DQMH to create their own extensions to the built-in scripting. For example, if the other feature request here is not accepted, this one would allow a developer to implement it on our own.

I would like a right-click plugin where I could right-click a DQMH broadcast subVI and "Find Event Frames". This would search all VIs in my current project for event structures that are registered for the broadcast event fired by the subVI I clicked on, and show me a list of results that I could double-click and be shown the event frames one at a time. Or I guess it could just open all the diagrams for me, since I probably want to walk through all of them anyway.

The operation could take a while, but would be worth it. I often find myself wondering where all the places are in my code that are registered for a particular broadcast.

(idea originally posted here)

When I create a new Broadcast, here's what the new frame in the API Tester looks like:

I almost always end up adding the following code by hand (usually by copying it from another frame):

It seems to me that most of this code could be scripted. Maybe everything except the value of the first format string?

(idea originally posted here)

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.

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

When creating new module, I'd like a way to add a text explaining its responsibility. It will reinforce good conception practices and allow Antidoc to retrieve information to generate a valuable documentation.

Note: IMO, this content should be added to the module lvlib description.

If this field could optionally mandatory to create the module, I would find this great 🙂

Original idea from Matthias Baudot in https://anchor.fm/wired-in-software/episodes/Episode-6---Matthias-Baudot-from-Studio-Bods-emtpti

When you have lots of modules (20+), initializing module selector control tends to take seconds that can be annoying when you need to use the scripting tools.

Finding a way to remove this init time would greatly improve the user experience in large application development.

When I need one of the reply payload values of a Request and Wait for Reply VI, I need to unbundle 100% of the time. What if the Request and Wait for Reply VI output the reply payload elements individually on the VI conpane so I don't need to unbundle? I often make this change manually to my Request and Wait for Reply VIs. And I never unbundle the error from the payload, since it's already merged into the error stream inside the VI. So I wouldn't expect that output to be on the conpane. But all the other payload parameters, you betcha!

(idea originally posted here)

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.

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"

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.

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.

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 😉