DQMH Feature Requests

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


Today when I finish creating an event / module, If I want to create a new one I've got to click again on Tools => Delacor => DQMH => Create...

Sometimes, after planning my architecture I'll need to create several modules/events in a row to start building my app.

Going through the menus each time is a pain in such case.


Maybe replacing the OK button by a Create button and a Create and Continue button would help to this (like you can have using Redmine for example).


The Create button would act like the OK button today.

The Create and Continue button would generate the new event / module but without closing the window.

It would simply reset the fields to their defaut values (and reopen a new virgin payload/paramater window in case of creating an event).


This way creating several items in a row would be really faster and easier.


(more details in the ppt attached)

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

Please create an additional toolbar named "Delacor" that has at least 2 buttons: one to create a new module, one to create a new event.


It's too tedious to go everytime via menu Tools, Delacor, DQMH, bla bla




In this picture you can see on the right the JKI tester toolbar, and also the NI Unit Test Framework toolbar.





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.


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.

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






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

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.

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

Just a very, very simple proposal for consistency, as per what the title says: when a "Panel close?" event is triggered in "External Launch" mode, the module should probably broadcast a "Panel hidden." Status updated. Like this:




Do you agree or is there any reason I'm missing for which the broadcast was not placed there?



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.

In the Create New DQMH Event... dialog panel, add a checkbox and label it "Make this a Private Request".
If this box is checked, the DQMH tools would create the request as normal, but store it under a virtual folder called "Private Requests" (Access scope = private)


Credit goes to doyles for initially coming up with this idea.


Go here for previous discussions:



My ideas for this are:
  1. Include a "checkbox" onto the Add New DQMH Module dialog panel that is labelled "Include a Helper Loop"



  2. If the user checks this checkbox, a helper loop is automatically added to the Main.vi
  3. The helper loop would not be a sub-VI, but simply a third loop on the main.vi block diagram.
  4. A Wake up Helper Loop request is automatically created and included in a Private Requests virtual folder
  5. Make the helper loop generic as per Sam's suggestion. My suggestion is to have three user events: 1) Timeout 2) <Stop Module> 3) <Wakeup Helper Loop>
  6. Label the additional "Register for Events" node something different from the other "Register for Events" node, ie. DQMH_REG_EVENTS_HELPER_LOOP (so that the Validate tool does not raise it as an issue)
  7. When generating a helper loop for new cloneable modules, ensure that in the "Wakeup Helper Loop" and "Stop Module" user events, that the Addressed to this Module.vi is used.

This was originally raised by Joerg here:



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


0 Kudos

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 !




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

When creating new module, I'd like a way to add a text explaining its responsibility. It will reinforce good conception practices and allow Antidoc to retrieve information to generate a valuable documentation.


Note: IMO, this content should be added to the module lvlib description.


If this field could optionally mandatory to create the module, I would find this great 🙂

A time delayed message in my opinion would be an useful edition to DQMH.


I understand that helper loops can be used to do timing with event structure timeouts. This becomes problematic when you need arbitrary number of timing instances at runtime. I agree resource intensive timing should be in helper loops but you may want to set up a heartbeat or check a certain signal periodically.


I did this in my application by creating a child of the messaging class and extending the class with AF style timing. But it would be nice to have this naively in the messaging library.


AF Time-Delayed Send Message VI: https://zone.ni.com/reference/en-XX/help/371361R-01/lvcomm/af_td_send/



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