DQMH Consortium Toolkits Feature Requests

Lately I've been running into lots of code that looks like this:

I just need to start a module, call a request (and wait for reply, usually), then stop the module. I think it would be convenient if the module templates included a 'Start and Sync Module' VI that wrapped the Start Module.vi and Synchronize Module Events.vi. This is for the use case where you won't be needing to register for any of the module's broadcasts.

I dislike using Clone IDs, Whenever I have used Clones in real life application, I always start by editing the Start Module VI and adding in a Clone name input. As I do this for all my clones the input name tends to be specific like 'Bay Name', or 'PSU Name' but a generic 'Clone Name' would be good.

I then pass that Clone Name into my MHL Data cluster in 'Initialize', each clone now knows it own name this allows things like

• A Request to all Clones to get the instance for a name, so calling code can work in terms of Set Voltage(UUT_PSU), Set Voltage(RIG_PSU) rather than Set Voltage(45568) Set Voltage(40056), making a clone manager more code easier to read. -- I know this could be done in a clone manger with a Map or table, but I like the idea of the Clone know its own name.
• As the clone knows it own name, because I gave it its name, this means clone instance configuration is easier, I have can have a single configuration ini file with each clone name as separate sections or I can have each clone read from its own ini file simple based on its own name.
• Modules other than the clone manager can if needed talk to the correct clone using the name they do not need to know about the instance.

Thinking about this it would be, to my mind, a great feature addition to DQMH is by default there was a optional for providing a clone name at startup that was accessible as a Mod Admin property alongside the Module ID.

When adding a new event, I think it would be really nice if the scripting code that adds the new case structure case to the main VI also scans the event description for formatting tags, and then applies them to the new case's subdiagram label. That way the subdiagram label will be formatted exactly the same way as it appears in the VI documentation. For those of us who adhere to the convention of bold facing control names as we mention them when writing VI documentation.

If you want to pass a parameter to your module when it starts, you can add that parameter as an input to Start Module VI:

The way you define the type of the Call By Reference node (to accept the new parameter) is usually by dragging the Main VI into the VI Reference constant wired to Open VI Reference. However, sometimes a different VI may be used to define the type, especially if there are multiple DQMH Modules in your project that take the same inputs on initialization. Also, the opposite situation can occur where you add an input to the Main VI connector pane, but forget to add that input to the Start Module VI.

If the connector pane of the Main VI doesn't match the VI Reference constant in the Start Module VI, you will receive an error when attempting to start the module. I propose that we add a Validate Module test that detects this situation (connector panes of Main VI and VI Reference constant don't match) and returns a validation failure.

Hi,

In order to reduce the number of clicks to launch a DQMH scripter, that would be great to be able to launch them from the LabVIEW New... menu !

Indeed this window has several advantages :

1. The tree view keeps its layout from one excution to another. So if the last thing I did from that window was to launch the 'New Event...' scripter, next time I'll launch this window this item will be directly accessible
2. It allows inserting the created code into the project or not. So to create quick code without adding it to the currently open project, this is quite usefull
3. The tree view makes easier to choose the scripter to launch. With Tools menu, if the mouse pointer accidently leaves the menu and overs another menu entry, you've got to go back and re-do some of the menu selection process
4. A LV keyboard shortcut can be added to the New... action. In my case I redirected the CTRL+N shortcut to launch the 'New...' window instead of triggering the 'New VI' action. It would allow me to launch a scripter with 1 keyboard shortcut + 1 double click ! Quite fast !

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!

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:

Running the validator on bigger projects takes quite long.

Would it be possible to speed up the process by running the validation of the modules in parallel?

Additionally: Also in CI/CD we know if the module has changed at all. It would be nice if the cli-module-validation could be called with a .lvlib instead of a .lvproj. Therefore, it could be handy to have a VI which lists all dqmh modules in a .lvproj.

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

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.

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.

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

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?

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 🙂