DQMH Consortium Toolkits Feature Requests

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

Please add a test to the Validate Module tool:


Find all while loops in the Main.vi of the specified module(s), and check if the DQMH Error Handler - Helper loop.vi is used to handle errors in each of the while loops, and flag it if not.  Ignore the default EHL and MHL in this check.


Lately I've been running into lots of code that looks like this:



I just need to start a module, call a request (and wait for reply, usually), then stop the module. I think it would be convenient if the module templates included a 'Start and Sync Module' VI that wrapped the Start Module.vi and Synchronize Module Events.vi. This is for the use case where you won't be needing to register for any of the module's broadcasts.


The problem I want to fix:

I want to be able to try to fix or poke the code more when an error occurs in the API Tester. The opportunity of going to the block diagram or attempting to send a different request goes away because the API Tester, by default, closes when an error occurs.


How I propose fixing it:

The first thing that I change on an API Tester at the first error is to remove the OR connected to the stop terminal in the loop and add an error indicator at the end instead of the Simple Error Handler and connect a local variable for the error. Would you please vote to have DQMH do this by default and have a validator to modify existing API Testers?


Current API Tester:



Proposed change:





Fab (yes, being the DQMH Lead Architect does not guarantee that all my wishes are turned into reality 😉 )



When you update the DQMH version, you can have hundreds of failures to fix in your projects (not because everything is broken but just because, for example, a new feature requires updating a VI).


A fixer is available most of the time, and you just have to click the button to make the code change.


For me, the UX issue is that after you hit the fix button, you need to select the next failure with your mouse and then click on the fix button. I'm not too fond of this kind of mouse gymnastics.


My proposition: If the fix is successful, the next failure could be selected automatically.


The fixing process would be significantly improved.


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):






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.


As DQMH module templates become more widely used, it would be very nice if, when adding a new DQMH module that was added as a custom template, the overlay pre-populated with the overlay that the template uses.


So maybe thinking about this on a lower level, this feature request comes in two parts. When saving a DQMH module as a template, store the metadata that makes up the current overlay in a config file somewhere. Then, on the Add New DQMH Module window, whenever a custom Module Type is selected, pre-populate the overlay with that metadata.





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.


The below image comes from the Error Reported broadcast event case in the API Tester (as found in the default Singleton or Cloneable DQMH module templates):




This produces strings that look like this:




This could be improved by adding the "message" component of the error, by using the Simple Error Handler.vi.  Using the message makes the error report more descriptive, and doesn't rely on the user having to use "Explain Error" to review what the error code's could possibly be related to.




This produces strings that look like this:




Observe that the error message is now present in the text.


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.


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:




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)


Bildschirmfoto 2021-12-08 um 09.08.45.png


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.


Greetings from France

be able to upgrade the module type, for example singleton type to cloneable type, would be a great feature.

menu -> DQMH -> Module -> updgrade



Update module.png


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.


This feature request is adding to the already existing "Private Request" and "Helper Loop Creation" requests (or not?):


When working with helper loops in cloneable modules, it would be nice to have a way for sending messages from the MHL to the helper loop which doesn't need the module ID, and which doesn't interfere with other clones' helper loop timings. I'd still like this new mechanism to look and feel like the regular events, with all the scripting and other goodness.


Maybe instead of calling them private events, a better name would be "local" events (which would, of course, be set to private scope).


It would nice to catch circular dependencies in the DQMH Validator Tool. Catching all circular dependencies would be hard ie A->B->C->D->A, but the simple case would be easy to catch A->B->A. This would be the case where A registers for the broadcasts of B but also sends requests to B.


If anyone has an easy way to catch the more complicated case, I'd be all for that too.




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?








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.






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)