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

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.


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:




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


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.


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?




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




When creating a RT Tester, the wizard asks for which modules it should do so. And it lists all modules in the project, even those which already have a RT Tester generated.


Maybe only showing the modules which do not already have a tester would help shorting the list ?


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)




In order to reduce the number of clicks to launch a DQMH scripter, that would be great to be able to launch them from the LabVIEW New... menu !

Indeed this window has several advantages :

  1. The tree view keeps its layout from one excution to another. So if the last thing I did from that window was to launch the 'New Event...' scripter, next time I'll launch this window this item will be directly accessible
  2. It allows inserting the created code into the project or not. So to create quick code without adding it to the currently open project, this is quite usefull
  3. The tree view makes easier to choose the scripter to launch. With Tools menu, if the mouse pointer accidently leaves the menu and overs another menu entry, you've got to go back and re-do some of the menu selection process
  4. A LV keyboard shortcut can be added to the New... action. In my case I redirected the CTRL+N shortcut to launch the 'New...' window instead of triggering the 'New VI' action. It would allow me to launch a scripter with 1 keyboard shortcut + 1 double click ! Quite fast !


Original idea from Matthias Baudot in https://anchor.fm/wired-in-software/episodes/Episode-6---Matthias-Baudot-from-Studio-Bods-emtpti


When you have lots of modules (20+), initializing module selector control tends to take seconds that can be annoying when you need to use the scripting tools.


Finding a way to remove this init time would greatly improve the user experience in large application development.



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)


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 I create a new Broadcast, here's what the new frame in the API Tester looks like:




I almost always end up adding the following code by hand (usually by copying it from another frame):




It seems to me that most of this code could be scripted. Maybe everything except the value of the first format string?


(idea originally posted here)


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


I would like a right-click plugin where I could right-click a DQMH broadcast subVI and "Find Event Frames". This would search all VIs in my current project for event structures that are registered for the broadcast event fired by the subVI I clicked on, and show me a list of results that I could double-click and be shown the event frames one at a time. Or I guess it could just open all the diagrams for me, since I probably want to walk through all of them anyway.


The operation could take a while, but would be worth it. I often find myself wondering where all the places are in my code that are registered for a particular broadcast.


(idea originally posted here)


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 🙂