Delacor Toolkits Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

DQMH Feature Requests

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" Smiley Wink

 

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



Opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
DSH Pragmatic Software Development Workshop

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Comments
Active Participant Active Participant
Active Participant
on

+1 for the Request and Wait for Reply VI to output the cluster elements individually.

 

+1 for Darren's comment about the error. And by the way, I always rename the error in the cluster to just "Error" so the bundle by name in the MHL takes away less space.


An opportunity to learn from experienced developers / entrepreneurs (Fab, Steve and Brian amongst them):
DSH Pragmatic Software Development Workshops
Automate the analyzing, testing, documenting, building, packaging and publishing of your projects via CI/CD:
Release Automation Tools for LabVIEW

Proven Zealot
Proven Zealot
on

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.

DNatt, NI
Active Participant Active Participant
Active Participant
on

When I start a LabVIEW project based o DQMH, I would like to be able to create multiple modules (different name/type/icon/ (responsibility description <-- see previous request 😉 ) at once.

Olivier JOURDAN

Wovalab | Certified LabVIEW Architect | DQMH Trusted Advisor |
Active Participant Active Participant
Active Participant
on

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

As we are really close to Xmas (and I've been really nice all the year long), I would ask Santa to give me the 2 following additional functions :

  • for a request, which DQMH module is calling it
  • for a broadcast, which DQMH modules register it

Thank you in advance Santa 😉

 

Olivier JOURDAN

Wovalab | Certified LabVIEW Architect | DQMH Trusted Advisor |
Active Participant Active Participant
Active Participant
on

Add private events for helper loop 

 

This summarises / repeats doyle's feature request and Chris' feature request. Pleaase go there and give them kudos.

 

Seeing as the private request events would live in a "Private API" virtual subfolder, it'd be great if the tools (rename, delete event etc) would work with those too.


An opportunity to learn from experienced developers / entrepreneurs (Fab, Steve and Brian amongst them):
DSH Pragmatic Software Development Workshops
Automate the analyzing, testing, documenting, building, packaging and publishing of your projects via CI/CD:
Release Automation Tools for LabVIEW

Proven Zealot
Proven Zealot
on

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.

DNatt, NI
Member
Member
on

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

 

 

dqmh-newArg.PNG

 

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:

dqmh-newArg2.PNG

  •  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

Member
Member
on

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.

 

Idea for what the menu option would look likeIdea for what the menu option would look like

 

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?

Member
Member
on

Feature Request: Include the error number in the comment for each DQMH specific error

 

For any DQMH specific errors, (eg. Request and Wait For Reply Timeout--error.vi), modify the comment on the block diagram from "Generate an error for the situation where the Request and Wait for Reply times out." to "Generate error 403686 for the situation where the Request and Wait for Reply times out."

 

We got this error the other day and a search didn't find it.  But if these codes are not going to change (and on the surface of things are not easily changeable), then having the comment reference the error number would be a quick and easy way to trace this error code down.

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au
Member
Member
on

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:

 

Stops on an errorStops on an error

 

 

 

 

 

 

 

 

 

 

 

 

 

to this:

 

Continue on error and show error dialogContinue on error and show error dialog

 

 

 

 

 

 

 

 

 

 

 

An alternative is that the error could be added to the Status indicator (rather than show the dialog).

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au
Member
Member
on

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-Documents/DQMH-Feature-Requests/tac-p/3636423/highlight/tr...

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:

  1. 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.
  2. 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:

  1. 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.
  2. 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:

 

dqmh_message_cases_BEFORE.png

 

AFTER:

 

dqmh_message_cases_AFTER.png

 

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

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au
Active Participant Active Participant
Active Participant
on

The one less-than-beneficial thing I've seen with customers is that you end up with lots of VIs that just encapsulate *everything*. Every MHL case looks exactly identical then, just a subVI that consumes the whole data cluster (in and out). 

 

I found it very hard to read what's going on. Obviously, I support the idea of proper encapsulation, but experience says it's not that each and every MHL case is by default one subVI encapsulating that stuff. 

 

Again, I'm not saying that's not a good idea. I just want to add some potential downsides for the sake of this discussion.


An opportunity to learn from experienced developers / entrepreneurs (Fab, Steve and Brian amongst them):
DSH Pragmatic Software Development Workshops
Automate the analyzing, testing, documenting, building, packaging and publishing of your projects via CI/CD:
Release Automation Tools for LabVIEW

Member
Member
on

Right now, I'm updating a rather small Project (just 13 modules) to version 5.0 and there is one little thing that could be improved in my opinion. After updating to version 5 I started the validation tool to update my existing modules. After scanning the modules, you get a list of issues to fix where you have to click every single issue and fix it by clicking the “Fix Issues” button. It would be very convenient to have a “Fix All Issues” button.

 

link to the discussion: https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Announcing-DQMH-5-0-Beta/m-p/4031704/highlight...

 

Best regards

Member Member
Member
on

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.

Brian Powell
Stravaro, LLC


Learn more about the DSH Pragmatic Software Development Workshops.
Member Member
Member
on

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?

 

Brian Powell
Stravaro, LLC


Learn more about the DSH Pragmatic Software Development Workshops.
Member Member
Member
on

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?

Brian Powell
Stravaro, LLC


Learn more about the DSH Pragmatic Software Development Workshops.
Active Participant Active Participant
Active Participant
on

Hi hi, 

 

Not sure this is a feature or a noteworthy item. While attempting to validate a previous version of DQMH module to 5.

K_Bull_0-1588930227794.png

 

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:

K_Bull_1-1588930287409.png

But the module name is already part of the argument inside the broadcast.

K_Bull_2-1588930436512.png

 

 

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

Active Participant Active Participant
Active Participant
on

Hello everyone, 

 

I am pleased to announce that we have now a dedicated area for you to post your DQMH Feature Requests and we will be able to keep the feature request discussion right next to the request itself. Check it out at:

 

https://forums.ni.com/t5/DQMH-Feature-Requests/idb-p/delacor-ideas?profile.language=en

 

Happy wiring, 

Fab



Opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
DSH Pragmatic Software Development Workshop

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Member
Member
on

That's fantastic Fab!  Well done.

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au
Contributors