DQMH Consortium Toolkits Feature Requests

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?

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:

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.

There is an option to convert Requests to Request and wait for reply but requests can not be converted to Roundtrip, so a broadcast has to be created manually with payload identical to the Request. Creating a Broadcast is not much of a deal but having two identical payloads is not ideal especially if the payload bundles multiple typedefs.

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

We are constantly having deployment errors on RT targets, mentioning the Simple Error Handler. Since on RT Targets that function is useless anyway, we've put a conditional disable structure around. This solved the error.

It would be nice, if that CDS would be added to a standard 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.

I sometimes need to implement a DQMH module in isolation. So the first thing I do is create a new blank project and save it (this will be the dev project for the new module). Then I try to create a new DQMH module in the same folder as that project (by editing the 'Module Save Path' to point to the folder containing the new blank project):

When I try to click OK, I get a dialog that says I can't create the module because the specified folder contains LabVIEW files:

Yeah, I know the folder contains a LabVIEW file... it's the blank project. The Add Module dialog wants me to create a new subfolder for the new module, but I don't want that... I want the module and all its files to live in the same folder as the isolated development .lvproj. I propose that this file check be changed to remove ".lvproj" files from the list of LabVIEW file types that it checks for.

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

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

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 DQMH module templates become more widely used, it would be very nice if, when adding a new DQMH module that was added as a custom template, the overlay pre-populated with the overlay that the template uses.

So maybe thinking about this on a lower level, this feature request comes in two parts. When saving a DQMH module as a template, store the metadata that makes up the current overlay in a config file somewhere. Then, on the Add New DQMH Module window, whenever a custom Module Type is selected, pre-populate the overlay with that metadata.

When opening a DQMH module .lvlib file directly, the LabVIEW IDE allows to call the DQMH Scripting Tools from the Tools menu, which results in an error message when trying to parse the project for modules:

This error should be handled the same way as when calling the DQMH Scripting Tools from a single VI (or even the getting started window):

This is bordering on "outrageously nitpicky", kind of like wanting all the error wires moved behind every other kind of wire (which I also consistently do, thanks Fab lol). But I'm just gonna say it and see how much traction it gets.

The default requests Show/Stop/Hide Module.vi etc., and all other default created VIs it seems, have "error in (no error)" as their error terminal name. For the VIs created by adding new events, the terminal name is "error in". My feature request is that these be changed to "error in (no error)" as well, to be consistent not only with the other VIs in the library but with most other VIs in vi.lib in general.

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 propose there be more items you can configure for a DQMH Module when creating it from scratch (ie not from a template). My current ideas are:

1. Name of the virtual folder in the target project to place the module tester

2. Name of the virtual folder in the target project to place the module library

3. Alternate path (other than "Libraries") to store the new module library on disk relative to the target project.

For example, our way of working defines that our DQMH modules are stored in a separate folder for each module under a /Modules folder. So a PowerSupply module would be stored in /Modules/PowerSupply/, both on disk and in the project as virtual folder. 

My suggestion is to have:

1. A way to enter these pieces of information directly when creating a new module

2. A way to store the defaults for these values "somewhere" (either in the LabVIEW.ini or maybe some other, user-specific place)

 

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.

Prior to DQMH 5, I would sometimes see developers add a VI reference output from Start Module.vi to the cloneable Main VI instance that was running:

This was sometimes convenient for the calling code, like in cases where you needed to insert the cloneable main VI instance into a subpanel or something like that. Unfortunately, you cannot use the same approach with Start Asynchronous Call in DQMH 5.0 and later. The VI Reference output from Start Asynchronous Call cannot be used for similar purposes. So you can't output the VI reference that was used to start the async call and expect your code to work the same. Instead, you'll likely want to create a request to the module that will use the "This VI" constant within the main VI instance itself to perform whatever operation needs to be done on the main VI instance. 

I propose there be a new DQMH Validate Module test that detects cases where the VI Reference output of the Start Asynchronous Call function is wired: