DQMH Consortium Toolkits Feature Requests

It would be awesome if the DQMH validation tool could go back more than one version.

eg.  If you open an old piece of code (that was written in say DQMH 4.2), the only way to upgrade it to 6.1 is to one version at a time, upgrade the code step by step.  This would mean the following:

 - Install DQMH 5.

 - Run Validation tool

 - Install DQMH 6

 - Run Validation tool

 - Install DQMH 6.1

 - Run Validation tool

This is a rather painful process, and when faced with this, I have decided to simply implement the module again starting from the latest version, and porting the code over rather than go through that.

Neither approach is obviously ideal.

We really need a tool that can convert an older module up to the latest standard.  This will become a more common problem now that we have DQMH-based code out there from 2018 onwards.  The more people use it, the more this problem will surface.

I have 'barebones' singleton and cloneable module templates that I always use when creating new DQMH modules for projects. I started with the shipping module templates and removed:

- 'Do Something' events

- All #Bookmarks

- Simulate EHL/MHL error buttons

I propose DQMH ship with these simple module templates. They help save several minutes when creating a new module. I'm not suggesting changing the project template, but rather simply adding two new options in the Add New DQMH Module drop-down:

I'm open to suggestions for different names. 🙂

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.

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

For some reason I need to know the module name of the module that I start.

Module name constant is a private VI and therefore cannot be called in a cller VI diagram.

Having the Start Module VI returning this information could be useful (instead of specifically creating a R&R just for this purpose).

For DQMH modules written prior to DQMH 7, helper loops will unlikely have the "DQMH_HELPER_LOOP_NAME" string constant wired to the error helper VI as shown below.

This idea is to propose a new test be added to DQMH Validate Module to check that all helper loops have this string constant present.

In DQMH 7.0 you can create private requests now. This is a feature that I really like and the more you use something, the more ideas come to you.

In my current project I created a private request and shortly after I realized, that I need to call this request from another module. I tried to convert the private request into a public request, but this wasn't easy.

So here comes my idea: why is the conversation (public requests → private requests and privat requests → public requests) not included in the Convert DQMH Events dialogue? That would be the place where I would intuitively look for it.

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. 

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!

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.

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:

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.

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

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.