DQMH Consortium Toolkits Feature Requests

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

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

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. 

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.

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?

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 😉

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.

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

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!

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.

I sometimes need to launch and stop a tester programmatically (mainly from TS).

I can launch the tester programmatically using VI server, but I need to do this wrapper for each tester.

To stop a tester, there is no way to actually do it programmatically.

The only action that stop a tester is manual one (closing the tester's window).

I would like a Tester API (basically 2 VIs) created by default in every module that would allow me to launch and stop a tester programmatically.

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

Problem: 

Currently the DQMH stock requests / broadcasts (eg: Stop module, Hide panel etc) are mixed with the user created requests / broadcasts so if one likes to check which requests, broadcasts etc are in the module he needs to open different subfolders and visually filter out the stock events. 

This is a readability issue which makes it significantly harder to quickly understand (or recall) what events are available for the given module.

Possible solution: 

Instead of mixing the stock DQMH events with the non-stock events create a virtual folder above all the virtual folders called "Module Specific" with subfolders like Requests, Broadcasts, Private and Controls and put everything the user create to there by default.

Big advantage of this of organizing the files this way would be that one could assume that whatever is module specific can be found in the these dedicated folders instead of spreaded somewhat randomly in the virtual folder structure of the module. I said somewhat randomly because the strucure as is currently is hard to read so developers try to make it more readable, everyone on his own way (eg: creating different folders, prefixing the user created events etc). So besides the increased readability of the module by applying this feature there is a very good chance that modules' structure will become more standardized across developers working at different companies.

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.

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

Greetings from France

be able to upgrade the module type, for example singleton type to cloneable type, would be a great feature.

menu -> DQMH -> Module -> updgrade

A+

Luc

JKI State machine has a great tool that comes with it, when you right clic on a BD element of a VI that contains a JKI State Machine, the option menu has the item "JKI State Machine explorer", fantastic tool to facilitate browsing the numerous frames of the case and of the event structure.

A similar tool for the DQMH module would be a great help!