DQMH Consortium Toolkits Documents
EDIT: We now have a place for you to post DQMH Feature requests here:
https://forums.ni.com/t5/DQMH-Feature-Requests/idb-p/delacor-ideas?profile.language=en
Hello everyone,
We have been getting DQMH feature requests via this forum, via conversations during NI events and direct e-mail. We keep track of every suggestion in our internal tracking system, but we thought it would be a good idea to have a central location for others to add their own requests. Please create a different discussion for people to discuss your feature request and point to that entry in your post here.
We will add some of the ones we have already received. If you find a feature request you agree we should implement, please vote by clicking on the "Kudos" button for that post. Also, our CCFO (Cheap Chief Financial Officer) has asked us to add the following: "If you consider a feature to be particularly important, be sure to mail in your vote written on the back of a new US$100 bill. Multiple votes are, of course, allowed and encouraged"
The more votes we receive for a particularly important feature, the more likely we are to implement it!
Best regards,
The Delacor team
Current feature requests:
Add a Rename Event utility to the Tools>>Delacor>>DQMH menu
Status: Done. Implemented in DQMH 3.0
Add a code to cloneable modules to make them behave as singletons
Status: Done. Implemented in DQMH 3.0
Add by default an error cluster in the Reply argument for Request & Wait for Reply Request Events
Status: Done. Implemented in DQMH 3.0
Add Request events to TestStand insertion palette if TestStand is installed
Status: Won't implement.
Support DQMH Modules Templates when creating a new DQMH Module
Status: Done. Implemented in DQMH 3.0
in DQMH 4.0 added the option for these templates for them not have to be installed in the LabVIEW Data folder, instead, the metadata file can include a full path instead of a relative path.
Discussion: DQMH first experience and a bit of a feature request
Add support for Real-Time or create a new DQMH module/project that would work on Real Time Targets
Status: Done. Implemented in DQMH 4.0
Discussion: Any caveats in using DQMH on Real Time
Module initialization with input from creator via Start Module
Remove the need for an argument when creating a new event
Status: Won't implement Implemented option to not have to add arguments in DQMH 3.0
Discussion: No arguments discussion
A way for the creator of a module to provide parameters for the Message Handler Initialize case
Status: Done. DQMH 2.1, we added a "code needed" bookmark with instructions inside Start Module.vi, so the developers would know where these initialization arguments if they needed to.
Discussion: Module initialization from Start Module and other ideas
A way to name modules/module clones during creation and then address them by name instead of by Module ID
Status: Wish List
Discussion: Module initialization from Start Module and other ideas
Requests with a To/From/Reply To header
Status: Wish List
Discussion: Module initialization from Start Module and other ideas
Floating Dialog Box for the Delacor Tools
Status: Wish List
Discussion: No discussion, the suggestion by K.Ross found further down in the comments to this document. If you want to discuss it further, feel free to start a new discussion.
Folder Cleanup
Status: Wish List
Discussion: No discussion, the suggestion by mRadziwon found further down in the comments in this document. If you want to discuss it further, feel free to start a new discussion.
Separate VI residing in each of DQMH_MESSAGE_CASES.
Status: Won't Implement
Discussion: No discussion, the suggestion by mRadziwon found further down in the comments in this document. If you want to discuss it further, feel free to start a new discussion.
Move sequence structure in Request and wait for reply to have access to merge errors
Status: Won't implement. The majority of DQMH developers remove the sequence structure anyway. It is there to facilitate scripting.
Discussion: No discussion, the suggestion by mRadziwon found further down in the comments in this document. If you want to discuss it further, feel free to start a new discussion.
Add the ability to choose the Icon Editor, currently only the default works. (I use Mark Balla's Icon editor.)
Status: Won't implement.
Discussion: No discussion, the suggestion by jdebuhr found further down in the comments in this document. If you want to discuss it further, feel free to start a new discussion.
Scripting API
Status: Wish List
Discussion: Scripting API
Combining the functionality of all 3 event types of DQMH
Status: Wish List
Discussion: suggestion by Barney10 found further down in the comments in this document. Also discussion available via Combining the functionality of all 3 event types of DQMH
Change "bundle" to "bundle by name" in EHL, Use dummy Cluster or improve wire-scripting
If we add new items to a request argument, the bundle function in the EHL (3) automatically expands to the new item. However the new arguments are not being wired in automatically (2) and the VI doesn't break (1):
I've wondered a few times, why my new argument in the MHL doesn't have the value I've wired into the request, because it was "forgotten" in the EHL. Someone else had this problem?
Suggestions for solution:
- The LV function bundle doesn't break if you don't wire in every item of the cluster, but the bundle by name function does. So the easiest solution to at least break the VI would be to use the BBN function
- Use a "Dummy Cluster", so that the argument can be passed to Enqueue Message without bundle at all:
- Since changing the arguments of a typedef is done manually and not with a DQMH-Script automatically wiring seems more difficult...
Edit: Added Link to Discussion
Feature Request: Add a 'Duplicate DQMH Event' option
A feature that I would find useful would be a 'Duplicate Event' option, that behaves a bit like LabVIEW's Save As> Open Additional Copy. It would bring you to the 'Create New Event Page' but already be populated with the data from the event that you selected to duplicate. This would make it really easy to tweak the description, names and arguments from the old event to make a new one.
There are lots of times where I have to make almost identical events and I am lazy *ahem* wanting to optimise when it comes to finding all of my argument controls and copy-pasting the code over. Has anyone suggested this before?
Feature Request: Change the default Test <Module> API.vi to not stop on an error
At present, the default Test <Module> API.vi stops if an error occurs.
I think the tester should keep running if you have an error. Certainly report the error, but don't stop the tester from running (and consequently shutting down the module(s) that are being tested). The error could simply be a timeout error, and is not catastrophic enough reason to stop the tester
At Wired-in we end up changing each Test <Module> API.vi from this:
to this:
An alternative is that the error could be added to the Status indicator (rather than show the dialog).
Feature Request: Automatically create a Message Sub-VI for every Request, Request and Wait For Reply, and Roundtrip event
This idea expands on ideas already raised by mRadziwon and Evan, but seem to have gone amiss. For the background go here:
https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Scripting-API/m-p/3656625/highlight/true#M296
This is a new revelation for me. The reasons for this request are:
- The undisciplined developer can let their MHL blow out into a large size, by employing the habit of implementing the "Do" code right there in the MHL case. In my experience, this code is not always simple and short and ends up rather messy. You are starting off in a small and restricted area to begin with, so you're up against it as soon as you create the event.
- It is also tempting for the average punter to use the MHL queues as a quasi-state machine. This is not recommended best practise, and has gotten us into trouble on multiple occasions.
Instead, for every Request type event, let's have DQMH create a sub-vi that is placed in the new case of the MHL. This sub-vi would be one of two types, perhaps selectable during creation:
- Single Process Step Sub-VI - The sub-VI would have inputs: Internal Data, Variant In, Error In, Internal Data Out, Error Out. It would carry out one action.
- State Machine Process Step Sub-VI - - The sub-VI would have inputs: Internal Data, Variant In, Error In, Event Registration Refnum, Internal Data Out, Error Out.
- This VI has a state machine architecture automatically created. This state machine would have the EVENT structure ready to handle the Stop Module Event (just like one would do with a Helper loop), and as per Fab's Tip 4 from this blog post. The state machine would have a enum control (also automatically created), with default values "Init" Run" "End".
This change would have huge benefits:
1) The MHL would be much smaller.
2) A mature DQMH Module would be simpler, and easier to read
3) Discourages the use of the MHL Queues to be used a state machine.
4) Would achieve Sam's rule "Do make MHL actions atomic" as written in his blog post here
BEFORE:
AFTER:
If this is not possible, then Joerg's suggestion of a Scripting API would help one to do this on their own (in an automated way).
Feature Request: Stop Module should stop the module even if there's an error in.
I expected Stop Module to be like the various "Close" functions in LabVIEW, where it would attempt to stop the module even if there's an error input. It does not behave this way.
I suppose that's why the API Tester has a "Clear Error" before Stop Module.
My current application is a simple, linear flow that...
1) starts modules
2) does some stuff
3) stops the modules
So, it doesn't use an event handler to control program flow at the top level the way the API tester does. I can easily wrap the stops in a subVI that ignores errors itself, but I still expected Stop Module to do that on its own.
Usability Improvement for Rename DQMH Event Dialog:
Remove the ".vi" suffix from the entries in the "Specify the event you wish to rename" dropdown menu.
E.g., it shows things like "Request: MyEvent.vi". (Which leads to me not really thinking it through, and filling in the new name of the event with a ".vi" suffix, so I end up with "MyRenamedEvent.vi.vi")
I know this is a small thing, but I don't think there's any reason to show the ".vi" suffix here, is there?
Usability Improvement for Create New DQMH Event:
This is admittedly minor, but it's annoyed me a few times, so I thought I'd submit it.
When I create a round trip event, I sometimes use similar names for both the request and broadcast. For example:
Configure some-really-long-measurement-name
and
Configuration updated for some-really-long-measurement-name
I will enter the former into the request name. Then, I enter "Configuration updated for " into the broadcast name, and go copy "some-really-long-measurement-name" from the request name.
When I return to the broadcast name to paste it in, the dialog has inconveniently truncated the trailing space after "for ", so I end up with "Configuration updated forsome-really-long-measurement-name".
I'm all for truncating trailing spaces on the names, but I think it's being done prematurely. Can it be delayed until after I click OK?
Hi hi,
Not sure this is a feature or a noteworthy item. While attempting to validate a previous version of DQMH module to 5.
It's great that the tool prompts you to connect the additional information input for Broadcast Error Reported. The fix does what it says on the tin:
But the module name is already part of the argument inside the broadcast.
Noteworthy perhaps.
Edit: Thanks for a super quick response from Fab: https://forums.ni.com/t5/Delacor-Toolkits-Discussions/DQMH-5-0-Error-message-takes-the-Module-Name-a...
