DQMH Consortium Toolkits Feature Requests

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.

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

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

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.

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.

When NI released VI Analyzer 2018, they included a feature to ignore VI Analyzer test failures for specific objects and VIs through the use of #via_ignore bookmarks:

I would like similar functionality for ignoring DQMH Validate Module failures. I propose that if a VI contains a #dqmh_validate_ignore bookmark anywhere on its diagram, then that VI will not return a failure for any DQMH Validate Module test whose name is included in that bookmark's label. Something like this:

Hi,

When creating Request And Reply / Round Trip events, the timeout to get the answer is set as a constant which is global to the module.

It would be nice to personalize this timeout to choose between :

• Module timeout
• Personnalized timeout with a control to enter a value in millisecond

If Module timeout is selected, then module timeout -- constant.vi would be wired to the 'wait for notification' timeout input.
If Personnalized is selected the value set by the user would replace the module timeout -- constant.vi (using a constant instead, or better calling a newly create 'request name' timeout -- constant.vi)

When developing a DQMH Module Template, the meta data XML file that goes along with the module template library defines various aspects of the module. Currently, the only user-configurable parts of the XML file are the module description, and where you want to store the template on disk.

I propose there be more items you can configure for a DQMH Module Template when creating it. 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, I have a DQMH module template for creating a test for my test framework. I want its tester to go in a 'Test Testers' virtual folder in my project, I want its library to go in a 'Test Libraries' virtual folder in my project, and I want the module to be saved in a 'Tests' folder that sits next to my project. It would be nice if all of these things could be not only specified in the UI of the Add New DQMH Module dialog, but default values for each of them could be defined in the module template meta data XML as well.

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.

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.

So - we have a few modules now where we essentially strip out the message handling loop as the modules are essentially "UI" modules.

DQMH 5 broke them (well, broke the ability to use the scripting tools with them), DQMH 6 allows them to work but could it do one more thing for me?

I have a cloneable DQMH event only module - it creates the event case, but it DOESNT put the "addressed to this Module.vi" into the newly created case as it would with a regular DQMH...

Any chance you can rejig the scripting order to get that back in?

Thanks! 

This was originally raised by Joerg here:

https://forums.ni.com/t5/Delacor-Toolkits-Documents/DQMH-Feature-Requests/tac-p/3974021/highlight/tr...

To quote Joerg:

"Sometimes, the error cluster that feeds into the Delacor QMH Error Handler - Message Handling Loop.vi doesn't convey enough information to identify the origin of the error. For example, an Error "91 - Variant To Data in xyz.lvlib:Main.vi" does not tell me in which MHL case the variant to data operation failed. It would be nice to have the selector label of the MHL's case that the error occurred in."

Feature Request: Somehow (not sure what the best way would be) make the error handler include the last message's name (string) in the error broadcast."

I'm triggering module validation with CI. On a large project (40+ modules), the validation takes 20+ minutes to execute.

I'm wondering if there are ways to reduce this execution time.