DQMH Consortium Toolkits Feature Requests

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.

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

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:

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

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 mentioned in DQMH Forum: VI Reentrance issue VIs which are required to be non-reentrant are not reported from the DQMH validation tool if they were changed (e.g. to shared clone)

Some of the important VIs which should be reported:

• Obtain Broadcast Events.vi
• Obtain Request Events.vi
• Clone Registration AE.vi
• Start Module (is already reported)
• Basically all used FGV's

Steps to reproduce:

1. Create Project with a new clonable module
2. Change all non-reentrant VIs to shared clone
   

    

3. Run module validation and execute fix
   1. Start Module.vi will be updated and changed
4. Rerun module validation
   1. No issues reported

This is more of a question or request for comments than an actual feature request:

In the dialogue window for creating a new DQMH module, should we rename the caption "Module Type" to "Module Template"? For a vanilla installation of DQMH, there are only two templates to choose from (Singleton and Cloneable), so the caption makes sense. Once you start adding your own templates, not so much anymore. Also, for documentation purposes, it would make things clearer if we separated the term "type" from the term "template".

In addition, it would be nice to see the actual type of the module (singleton or cloneable) added to the name in the dropdown list (see screenshot).

Opinions?

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)

Reviewing somebody's DQMH code I noticed an error generated in the exit case where they had cleanup code (1) was not captured by the Tester. This is purely because the exit case causes the MHL to terminate (2), so the normal error handling strategy (3) doesn't work (enqueuing another job called Error). Can I propose, unless there's a better technique, that adding the "Error Report" broadcast at the end of the Exit case (4) is a simple way to ensure any errors generated here get reported.

Add Error Broadcast in MHL Exit Case

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)

Hi, I would suggest adding a boolean called 'Include Dependencies' to the function on the scripting API to search for DQMH modules on the project, sometimes we have projects and we call DQMH Modules not listed on the project itself, but the developer should be aware we are calling those DQMH modules under dependencies, the Panther Dashboard for DQMH already is searching for DQMH modules under dependencies but it would be great if the native function does this functionality, also, I suggest adding a boolean array output to know if the resulting modules are located under dependencies or they are in the project.

This is how I visualize the connector pane of the 'Get DQMH Modules in Project.vi'

Thank you!.

The below image comes from the Error Reported broadcast event case in the API Tester (as found in the default Singleton or Cloneable DQMH module templates):

This produces strings that look like this:

This could be improved by adding the "message" component of the error, by using the Simple Error Handler.vi.  Using the message makes the error report more descriptive, and doesn't rely on the user having to use "Explain Error" to review what the error code's could possibly be related to.

This produces strings that look like this:

Observe that the error message is now present in the text.

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 🙂

I feel like a DQMH module isn't "valid" if its Main VI or its Tester are broken. Right now a module with either of these VIs being broken can pass all validation tests. If something goes wrong after I've run some module "fixers" (or perhaps an external factor has caused my module to become broken without my knowledge), the DQMH Validate Module tool seems like a good place to let me know about it.

Original idea from @FabiolaDelaCueva 

Sometimes you could need to unregister broadcast events. To do this you want to use the Broadcast Events--cluster.ctl, but it's set to private scope (it's totally fine).

Having a public wrapper to this control just giving access to the type and not the current event like you can get with Obtain Broadcast Events For Registration function would be great.

Considering providing a fixer to add this wrapper to all other existing modules.