DQMH Consortium Toolkits Feature Requests

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:

If feasible, I would recommend a tool to navigate an application. This request may be considered an extension to, and as the inverse of, the function "Find DQMH Event Frames" 

Include a navigation window with structure of Modules -> Broadcast Subscribers and Request Makers. 

The JKI State Machine Explorer is a great example of the developer experience I'm hoping for. 

Another approach may be the ability to right click on an event case and select "Find Broadcaster and/or Requestor" and show corresponding MLH case. 

Where do I send my $100 attached to this request? 😉 

Thanks - Jared

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)

Here's something I've been running into lately (for whatever reason hadn't done a ton with cloneable until now). I'm sure someone else must be as annoyed by this as I am.

Why do all the cloneable broadcast event VIs take a module ID and not a module admin object? Is there ever a reason where I would want to use a different module ID rather than the current one? I can't think of any, but maybe I am just not that imaginative.

Everywhere I drop a broadcast I have to also drop a property node and pull off the Module ID, why not just incorporate that into the broadcast VI?

By the framework not including that it requires extra effort on my part to wire it all up and it clutters my block diagram with property nodes that don't really add anything.

I'm sure there is probably some reason it was done this way. What use case am I missing where I would want to use a different module ID? and if there is a use case for that, I'm assuming it is an infrequent or minority use case. Is there some way we could make the primary use case the default (ie use the current module ID) without requiring all these extra property nodes, while still maintaining the ability to use a different module ID if needed?

Not sure if there is a way to do this and also make it backwards compatible? Maybe leave the existing broadcast vis as is and mark them as deprecated or something and add a wrapper that takes the module admin and then calls the 'deprecated' VI.

All I know is that there has to be a better way than dropping a property node every time or me manually creating a wrapper for every broadcast.

How does anyone else currently solve this problem?

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.

For the singleton and cloneable module type, there is an option to include "Do Something" events in the new created module.

I'm not sure it's often used.

I'd like to remove it to simplify the UI.

All,

The suggestion/request is mainly caputured in Implementation (1) at "https://delacor.com/dqmh-generic-networking-module/"

The proposal is to generalize the 'reply' communication by using a 'variant notifier' instead of a 'typedef notifier'.

I agree with the statement mentioned on the delacor website.

"This allows us to send and receive messages without knowing about their actual contents, and that’s the prerequisite for separating the module’s actual use code from the networking code."

The proposal is to change the DQMH scripting to always use the variant notifier. (instead of manually changing)

Actually I have changed the scripting to be able to have this automatically, which I use already 2 years. (If interest I can share with the consortium)

Personnally I don't see any disadvantages of using a variant instead of typedef in this case.

Also for writing the reply payload, this is not a problem as the typedef is also scripted automatically. (see screenshot) 

Any comments on potential disadvantages?

Regards,

Lucas

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.

Request:

Provide a mechanism to externally name the cloneable instances and retrieve the names to populate the "Select module" ring. 

Reason:

Lets say I have three power supplies. Having a ring displaying eg.: 5,6,7 has way less information than lets say "Main PS", "DUT PS", "Battery PS". Sure in the background they will be just numbers so the numeric part of the ring should remain the same. If no name is provided for a given instance then nothing should change.

This is a relatively simple change, can be done easily with a template so not sure if this should be the part of a DQMH release.

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.

Hi,

Some of my events have a common events arguments and/or reply payload.
Creating a template would speed up their creation.

Also, when using round trips from TestStand, I made a modification to the content of a round trip event to easily handle termination.
It could be nice if this modification could be saved as a template, so that every round trips I create to be used within a TS sequence would contain automatically that modification.

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! 

I was writing a module that interfaces with hardware and created an "initialize" request event to call the driver's init. Had I been thinking I would have realized there is already an "initialize" case native to DQMH, but the tool went ahead and scripted it out. The only indication of a problem was a broken run arrow due to duplicated case names.

Hello,

I'm working now on communication between two DQMH apps. Sending events between then is easy thanks to HSE Generic Networking for DQMH Module. However, each request that I want to transfer requires a wrapper (documentation) and the steps to create it are the same. It would be nice if I can automate this process by customing Create New DQMH Event function. So I have tried to find any information about how to add a type of event but without success. Is it possible? Another solution will be to have an option to add Post Event Creation action (vi), which gives a possibility to run self-created scripting code. 

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 sometimes create Cloneable modules that I intend on usually calling as singletons. For these modules, I often manually update each request to have its Module ID input recommended (instead of required) and the Module ID default value of 0 (instead of -1). I also make the 'call as singleton' input on Start Module.vi have a default value of TRUE (instead of FALSE).

I'd like for there to be an option when creating a new cloneable module that says something like "optimize for calling as singleton" that would create the default requests as described above, and would also be tagged in some way so when I add new requests they will be created as described above.

(idea originally posted here)

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.

For the Validate DQMH Module (Headless).vi, expose an event that allows for updating the status of the validation while it's running.

Similar to the AB API:

This would allow to update the UI or CI console during execution.