DQMH Consortium Toolkits Feature Requests

Community Browser
Top Authors
Showing results for 
Search instead for 
Did you mean: 
Get support when using Delacor toolkits.
Post an idea

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.


When developer use DQMH on RT, it is not possible to use the show diagram function. It could be painful when cloneable DQMH are used on RT target.


One solution to temporary  debug the system is :

  • Change the main DQMH VI in Non Reentrant execution
  • Change in the Reference management Vi the way we open the VI



It could be great to add two tools :

  • Temporally change this two option ( with message pop up to explain that it is only for debugging)
  • Add in the checklist on Validate DQMH, and add the possibility to go back


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.


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


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:





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)


The DQMH library has several errors defined in privately scoped VIs like "Module Not Running--error.vi".

It feels like the error codes associated with these error constants form part of the public API but there is no way that the library caller can know what these codes are without the omnipotent powers of the developer looking into the code (or deliberately triggering the error in an API call).

What would be people's thoughts on providing some public VIs which wrap up the private error constant VIs and just output the code for use with the things like the "Clear Errors.vi" or other error handling logic?

I know these could be added to a custom template but if the point of the DQMH is to encourage good practice then avoiding magic numbers in the caller's error handling logic is a win right!







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.


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







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.


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


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


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)


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:


Bildschirmfoto 2020-07-19 um 10.46.24.png

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


When you add a new Request and wait for reply event, the scripting tool adds automatically, in the Modules consumer, the handler case. In this case, there is also added the bundle for the Reply message and the Wait for reply? case structure. 

Personally, i move every time the bundle inside the Wait for reply? case structure to have a cleaner area.

The scripting tool can add this automatically for a cleaner view and maybe an optimized code. There is no need to create a bundle, if you do not use it forward.


Download All

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


When using the Request and Wait for Reply pattern, the time-out happens locally (with a usually hard-coded default-value).

The module receiving the message has no idea of the time-out on the client side (timeout meaning: When did I send the message to the module?, When do I not care about an answer anymore?).


I suggest incorporating such info (i.e. "Timeout End Timestamp") into the request message automatically, so that the module can do sanity checks before processing the request (i.e. "Time-out occured already, so I'm not executing the request at all, since the caller doesn't care anymore").


Furthermore, I think it is helpful, if you can choose during creation of a "Request and Wait for Reply" event with the wizard, if the time-out should be exposed or the default constant should be used, bringing this decision to the attention of the developer.


Thanks !





Instead of selecting each item to be updated then click update. It would be nice to have an update all or be able to select multiple items to be updated.. Especially when going to a newer version (like 4.x to 5.0)



For the Validate Module\Validate DQMH Module (Headless).vi, consider formatting the Validation Results in xUnit format.