DQMH Consortium Toolkits Feature Requests

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:

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?

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 creating a Request and Reply event, the scripter creates the corresponding calling code.
In this code the request VI is added on the diagram with all inputs empty (except for the error IOs).

Most of the time I select the VI and perform a 'CTRL+space + CTRL+D' to create all input/output controls and indicators.

And, therefore, it creates a boolean control for the 'Wait for Reply ?' input.

99.9% percent of the time I replace that control with a constant value, since I know if I need to wait for a reply or not for that specific request. And there is (close to) no chance that I'll need to set that using a control on my tester GUI.

Maybe placing the request VI and adding a constant linked to the 'Wait for reply ?' input on the tester diagram would help reducing the number of redundant actions one achieves when coding the tester ?

Connecting the constant would avoid having to change a control created by the 'CTRL+space + CTRL+D' shortcut into a constant each time.

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

Note: I couldn't find any idea/discussion about it and it's surprising. If I missed something, please point it out to me and accept my apology.

The idea would be to access the most used scripting tool via Quick Drop.

My wish list:

• Create New DQMH Event...
• Add New DQMH Module...

I use the Show Diagram debugging request on DQMH modules all the time. But sometimes it's not quite enough, like if there is a bug in my module *initialization*. By the time I fire the Show Diagram request, there is no way for me to debug the initialization problem. And when I say "initialization", I'm not only referring to the Initialize message in the MHL, but also all the code on the left side of the diagram that executes before we even get to the EHL and MHL.

I propose the following:

1. Add a new data member to the Module Admin class: "Show Diagram on Init"

2. Add a new input to Start Module.vi that sets this flag on the Module Admin class that is passed to the Main VI. Default is FALSE.

3. In the Main VI, if this flag is true, then Init Module.vi will show the diagram of the main VI on initialization AND turn on Retain Wire Values.

With these changes, the block diagram of the Main VI will appear immediately on init, and we can probe any wires on the diagram that executed during initialization to see their values.

It would be nice if there were a validate+fixer for this, but given that it is a debugging feature (as opposed to a change in framework behavior), I'm fine if there is no validate+fixer.

Hi,

Including DQMH modules into our application framework, we need to script the creation of new modules / requests and so on.

However, current scripting GUIs do not have any controls connected to the connector pane.

Also, even if we could pass some values to these interfaces, we would even need to control if we want to show their HMI or control the creation / cancellation of a scripting action whitout having to press on the OK / Cancel button.

Allowing to programmatically control the DQMH scripting VIs would be great !!

A round-trip can be summarized as a Request and Reply event + broadcast of the reply.

Round-trips are particularly useful when debugging systems where the access to the module itself is hard to get (like when using TestStand / VeriStand platforms). They are very good sniffers to understand what's going on under the hood.

I would find it very valuable if the broadcast could also carry the request arguments !

This way the 'sniffer' could expose the context of the reply : reply is formed that way when the request contains such arguments.

I'd like to have a way to duplicate a module easily through DQMH module menu.

It's not completely related to the framework itself, but I'd like to have a tool to generate an "error VI" (like Module Not Running--error.vi) with custom error code not already use in the project or selected among the existing ones.

If we could also have an API that list error codes and text, I would like it 🙂

It would be great to have an API that provides functions to :

• list project DQMH modules (with /type/icon/ (responsibility description <-- see previous request  
   
    ) 
• list request and broadcast for a module (with as many useful information that could be interesting to put in a project documentation) 
• for a request, which DQMH module/"stand alone VI" is calling it
• for a broadcast, which DQMH modules/"stand alone VI" register it

At the moment, when we create a request and wait for reply event, the reply payload (correctly) includes an error cluster to report any error that occurred during the handling of the request. However, the error cluster label includes the request name, even though it is within a typedef'd cluster which already uses the request name.

Not only is this a pain as it can take up a lot of block diagram space - I thought duplicating names of structures with a structure was not great style - if its in the "Do something request and wait for reply (Reply payload)" cluster, it probably doesnt need to be called the "Do something request and wait for reply_error"

Could it be changed to just be called "Error"?!

Just a thought...

Paul

Wouldn't it be great if we could hook into the scripting process of DQHM and, for example, add our own automation steps to the creation of new modules or new events? Something like the "post-build VI" feature of the application builder...

This has been discussed before in the now deprecated "Feature Requests" thread

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)

 

It can be hard to follow the flow of messages between DQMH module in a large project.

I find sequence diagrams great to document that, one tool that would rock is something that looks like a UML Sequence Diagram that is updated as messages are being sent. Columns generated the first time a module is started and then the lifelines of the modules are generated and terminated in their column.

Such a tool was created for the AF, so surely the same could be done for the DQMH.

I propose to let the script/scaffolding engine to make a folder with erros, I think it's cleaner

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.