Delacor Toolkits Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

DQMH Feature Requests

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

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Comments
Active Participant FabiolaDelaCueva Active Participant
Active Participant

 

Add a Rename Event utility to the Tools>Delacor>DQMH menu

Status: Done. Implemented in DQMH 3.0

 

 

 

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant FabiolaDelaCueva Active Participant
Active Participant

 

Add code to cloneable modules to make them behave as singletons

Status: Done. Implemented in DQMH 3.0

The Singleton would stay as is, since it is the easiest way to introduce LabVIEW developers to the DQMH.

 

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant FabiolaDelaCueva Active Participant
Active Participant

 

Add by default an error cluster in the Reply argument for Request & Wait for Reply Request Events

Status: Done. Implemented in DQMH 3.0

 

While working on code for a project that was using LabVIEW And TestStand, we ended up using Request & Wait for Reply events exclusively, this means that if the error is not part of the Reply argument and it is only sent to the error case and there is no one to listen to the error broadcast... calling code doesn't know that there was an error in the code called as part of the request.

Suggestion: Add Error cluster as part of the Reply argument by default.

Script wiring the bundle by name with the error going into the send notification and add a note indicating to developer to wire any errors generated by their code there.

Script unbundling the error from the reply on the Request and Wait for Reply API VI and merge it with any other errors and return it to the caller.

 

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant FabiolaDelaCueva Active Participant
Active Participant

 

Add Request events to TestStand insertion palette if TestStand is installed

 

Status: Won't Implement

If creating a new DQMH module AND TestStand is installed we could create a new insertion palette item representing the DQMH module with sub palette items for each request (and request + wait)

Creating new request (and request + reply) events would add them also to the particular DQMH palette item.

The events could then be dropped directly into the sequence.

The Physical files would reside wherever they were created and simply referenced by the palette definition file (it's an ini file)

We can also specify that when dropping a Start Module.vi from the palette we also drop Synch Module Events.vi at the same time.

 

 

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant FabiolaDelaCueva Active Participant
Active Participant

 

Support DQMH Modules Templates when creating a new DQMH Module

Status: Done. Implemented in DQMH 3.0

Discussion: https://decibel.ni.com/content/message/110465#110465

Add option to Tools>>Delacor>>DQMH>>Create DQMH Module from Template…

We would have a folder where DQMH Module templates could be saved and the tool would duplicate them, add them to the project and replace any "module name" mention with the "new instance name" provided by the developer.

 

 

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant FabiolaDelaCueva Active Participant
Active Participant

 

Add support for Real Time or create a new DQMH module/project that would work on Real Time Targets

Status: Wish List  Implemented in DQMH 4.0

Discussion:

https://decibel.ni.com/content/message/128227#128227

https://decibel.ni.com/content/message/137031#137031

We have received several requests to provide a DQMH Module template that would work on RT.

 

 

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant FabiolaDelaCueva Active Participant
Active Participant

 

Remove need for an argument when creating a new event.

Status: Implemented option to not have to add arguments DQMH 3.0

Discussion: https://decibel.ni.com/content/message/130068#130068

Remove the requirement to add an argument to the Argument window when creating an event. If no argument is provided, then the scripting would create the argument with a typedef that has a "dummy" boolean in its cluster.

 

 

Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant FabiolaDelaCueva Active Participant
Active Participant

A way for the creator of a module to provide parameters for the Message Handler Initialize case.

Status: Wish List


Discussion: https://decibel.ni.com/content/message/130979#130979

Mads' request:

"

1. A way for the creator of a module to provide parameters for the Message Handler Initialize case. The Start Module.vi currently only sets the Module Admin input of the module. The creation of this VI could be scripted to include whatever parameters the initialization would need (the same way we do for requests now). I guess the current way to do this is to create a separate initialization event and issue that after creation, but this would then not run until after the initialization has been done...

"

For DQMH 2.1, a "code needed" bookmark with instructions was added to Start Module.vi, so the developers would know where to add this initialization arguments if they needed to.


Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant FabiolaDelaCueva Active Participant
Active Participant

A way to name modules/module clones during creation and then address them by name instead of by Module ID

Status: Wish List

Discussion: https://decibel.ni.com/content/message/130979#130979

Mads' request

"A way to name modules/module clones during creation and then address them by name instead of by Module ID (Currently the creator(s) of modules woudl need to administrate a linked list here outside the DQMH framework...or we have to request every module for their identity and/or broadcast a message with a target name in it)."


Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant FabiolaDelaCueva Active Participant
Active Participant

Requests with a To/From/ReplyTo header

Status: Wish List

Discussion: https://decibel.ni.com/content/message/130979#130979

Mads' request

"Requests with a To/From/ReplyTo header: This one is a bit less general, but anyway: In one of my current use cases, modules might a) use a lot of time before the Message Handling Loop is able to process a request (it is doing time consuming work)...and b) the sender of the request might not necessarily be the one needing the reply. It would be cool to be able to issue a request to a module saying "take you time" - whenever you have finished handling this message (very long or even infinite timeout), send the reply to this given queue. (I would use queue here instead of notifier.) Here it would also be nice to just specify the target (queue) by name. That way the code issuing the request only needs to know the name (address) of the intended target (queue), not generate and supply a queue reference.

"


Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor
Active Participant Mads
Active Participant

Request for submodule feature

(multiple modules in one module lvlib, sharing the same events)

It would be very useful to have (full) support for having multiple main-VIs in (clonable) modules, and choose which type of the (sub)modules to start. All submodules otherwise share the same events/API. This is currently possible by manually adding copies of the main-VI, and manually modifying the start function, but when you add events they will only be scripted into the original main VI.

More details available in this discussion.

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Active Participant Mads
Active Participant

Extend Real-time support by not relying on front panel events

The module tester generated by the framework is designed to use front panel events to handle its front panel controls, this makes the controls unresponsive on real-time targets (which only support such events on targets with GUI capability). It would be nice if the template for the tester either used classical control polling instead to avoid the issue in general, or if there was a "to be used on real-time" option added to the module wizard that produced a no-front panel events version.

In its most basic version there are not that many of the controls that are supported anyway on RT, opening/closing panels for example, but the select module button is still nice to have working...and as a template it would be good to have it guide you to a working design for RT for any additional front panel controls you might add to the tester when you add user events etc.

MTO
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Member K.Ross
Member

Floating Dialog Box for Delacor Tools

 

It would be great to have a floating window that provided faster access to the Delacor Tools. I find it a bit clunky having to navigate through the menu every time I want to create an event. Especially in the scenarios where I have designed my module and I just want to build it up fast. 

 

My suggestion is to have a floating window going from this (below)

Delacor Tools.PNG

 

to this (below)

Delacor Tools floating Window.PNG

 

But having it available from the menu and/or the floating window.

 

Sorry if this is already a feature and I have just missed it. 

 

 

Thanks

 

 

Kev

Member mRadziwon
Member

Folder Cleanup

Currently all vis and typedefs are just thrown in one folder. It makes it difficult for a TestStand developer to find a particular request he is interested in. I suggest a cleanup in folder structure on the hard drive  to reflect the one of the library.

 

 

 

Member mRadziwon
Member

Separate VI residing in each of DQMH_MESSAGE_CASES. 

 

As your style guide suggest most cases commands are atomic and realized within one case. However, constrained space in each case makes it hard to accommodate more complicated code. There are two solutions - or to pack it to a subvi, or to expand the case structure and make it look ugly.

 

The first solution allows for neat hierarchy and even possible reuse for compound steps. 

Such a vi could have Event Argument and Data Cluster clusters as input, and Data Cluster and CreateNest (Reply Payload) //if applicable//. Also it could automatically connect its error cluster to merge errors of particular case.

Member mRadziwon
Member

By default, if the event type of an event is "Request and wait for reply" the merge errors node  DQMH_MESSAGE_CASES is placed exactly on the border of flat sequence structure.  It renderd merge errors node unavailable , before it, or the flat sequence, is moved.

I'd suggest to move the whole structures several pixels up to allow immediate access to its terminal.

Member psmorris
Member

Backing up Mike CCM's comment on folder cleanup - We're using VIPM to turn modules into installed packages with the public API (only) exposed through the palettes. It'd be really handy to have all the public API VIs (and .ctls) in their own "public API" folder to make it quicker to create the palettes in VIPM (just get rid of everything expect the public API folder! 

 

You could possibly go one stage further and sub-folder the "built in" API VIs (e.g. show panel, hide panel etc) and sub-folder "user created" API calls... but that may be a step further than absolutely necessary (I get why sticking close to a flat hierarchy is sensible too!)

 

Paul

Member jdebuhr Member
Member

Add the ability to choose the Icon Editor, currently only the default works. I use Mark Balla's Icon editor.

Jeff D.

Certified Architect LabVIEW Champion DQMH Framework

Active Participant joerg.hampel Active Participant
Active Participant

Scripting API

 

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

 

https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Scripting-API/m-p/3655950


Joerg Hampel, CLA & LabVIEW Champion | hampel-soft.com | alarchitects.org
Member Barney10
Member
Combining the functionality of all 3 event types of DQMH

Sometimes it's very helpful to combine all three event types of the DQMH framework to one event type. Especially by using TestStand for automated testing.

In TestStand I want that an event is blocking and after finishing, the next step is called. But if I use a graphical user Interface (created with LabVIEW) for manuell testing to call the events, I don't want to wait for finishing because my user Interface is blocking too.

So for automated testing I need "Request and Wait for Reply" and for manuell testing I need the "Request", but I don't want to create two Events for the same functionality (redundant code).

Optionally I could add an broadcast Event too.

 

Discussion: https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Combining-the-functionality-of-all-3-event-typ...

 

Active Participant K_Bull
Active Participant

It would be great if there was a polymorphic VI which held all the public APIs and got modified after creating new public APIs.

 

This would speed up the process of accessing the APIs using quick-drop. So the polymorphic VI could be dropped and the right instance chosen easily. 

Active Participant joerg.hampel Active Participant
Active Participant

DQMH Version Constant VI

 

In order to display or log the DQMH version number which any given application is built on, I pull it from a random DQMH VI by parsing its documentation tag: 

_____
Based on Delacor QMH Project Template 4.0.0.41.

 

So far so good. But depending on what exactly I want to achieve with this, I cannot just randomly pull this information from any given DQMH VI. I can read the Delacor QMH Project Template version that the VI was created with, and I can read the Delacor QMH Palette version. I cannot read the version of Delacor QMH as it shows up in VI Package Manager (if I'm not mistaken).

 

Feature Request: A VI that gets installed with DQMH that returns the version number of the currently installed .vip. I guess it's quite easy to script one...

 

dqmh-versions.png


Joerg Hampel, CLA & LabVIEW Champion | hampel-soft.com | alarchitects.org
Active Participant joerg.hampel Active Participant
Active Participant

Strip HTML formatting from VI description for MHL subdiagram label

 

All said, I think.

 

Feature Request: Remove the <b> and </b> tags from the description text before writing it to the message case's subdiagram label.

 

inject-key-command.png


Joerg Hampel, CLA & LabVIEW Champion | hampel-soft.com | alarchitects.org
Member doyles
Member

Have a Create DQMH Helper Loop option in the DQMH menu

 

I think helper loops are used by enough people that having that done automagically would be a great feature for the DQMH toolkit.  

 

Basically create the loop, the Wake Helper Loop event, the Sleep Helper Loop event, and then register the loop for those two and the Stop Module event for the module that the loop is placed within.  The actions within the Timeout case would have the #CodeNeeded note.  Possibly a #CodeRecommended note in the Sleep Helper Loop and Stop Module cases as well.    Also event requests should be placed in a PrivateRequest folder in the project.

 

Discussion is located here: https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Feature-request-Automate-the-Helper-Loop-creat...

Active Participant joerg.hampel Active Participant
Active Participant

Icon Overlay for Broadcast VIs

 

Sometimes when looking at a DQMH (main) VI's block diagram, I find it difficult to spot which VIs are just subVIs encapsulating functions, and which VIs are broadcasting and communicating data to the outside world. Our coding conventions now make a rule of manually changing the VI icon of broadcast VIs to carry a glyph symbolizing the broadcast character, as can be seen in the screenshot below:

hse-dqmh-broadcast example.png

(We dictate icon layouts and colors. The colored bar is green because this is a User Interface module. The colored square is used to distinguish multiple UI-related modules from each other. The broadcast glyph is then colored as the square is, but with inverted colors.)

 

Here's the glyph PNG that we put into LabVIEW's data folder, eg. C:\Users\admin\Documents\LabVIEW Data\Glyphs\

hse-dqmh-broadcast.png

 

Feature Request: Change the VI icon of broadcast VIs during generation (automated scripting) so they are more easily distinguishable.

 

Edit: More details in my guest blog post on delacor.com/vi-scripting-add-glyph-to-vi-icon/.


Joerg Hampel, CLA & LabVIEW Champion | hampel-soft.com | alarchitects.org
Example Gatekeeper
Example Gatekeeper

joerg.hampel wrote:

Feature Request: Remove the <b> and </b> tags from the description text before writing it to the message case's subdiagram label.


Or even better, actually bold the specified text in the MHL subdiagram label. I like this idea.

DNatt, LV R&D
Member nilsdornblut
Member

Feature Request: Please add a new tool to convert "Request and Wait for Reply" Events to "Round Trip" Events. (Discussion is located here)

 

That would take a lot of click work off our hands.

 

 

Active Participant Kenny_K
Active Participant

Feature Request:  Ability to see what modules or VI are set to read only when attempting to modify the a module.   If there are multiple modules, it can be difficult to locate the offending vi.

 

See here for original post in forum.

Kenny

Member Ozfarmboy
Member
Feature Request: Create New DQMH Event - Private Request
 
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)private request.png

 

 

 
Christopher Farmer

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

Feature Request: Rename DQMH Event - Ability to edit description 

 

When renaming an event, include a control to display the description of the event so that it can be edited and updated automatically.

 

event description.png

 

Christopher Farmer

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

Feature Request:  Create New DQMH Event - Two Argument Windows for Req&Wait4Reply

 

When creating an event of type Request and Wait For Reply, display two Argument Windows - one for the request, and the other for the reply payload. This will save time in having to go back and edit the payload control afterwards. Clearly mark each window as Request Arguments and Reply Payload Arguments.
 
reqandwait4reply.png
 
 
 
Christopher Farmer

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

Feature Request: New menu option: Save DQMH Module as Template

 

New menu item: Save DQMH Module as Template.  This would allow the user to select a module and save it as a template.  A dialog would appear prompting the user to select the DQMH module they would like to save as a template. This would then automatically create the xml file, and copy the module over to the LabVIEW Data folder, ready to be used as a template. Saves a lot of time and confusion with regard to setting up the xml file.

 

save dqmh as template.png

 

Christopher Farmer

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

Buttons for newly created events in API Testers

 

When creating new requests, the first window that pops up is the block diagram of the API tester, where (99% of all times in my case) you need to add a button, and link the event case to that button. 

 

Feature Request: When scripting the new event case in the DQMH_EVENT_TESTER event structure, also create a button and link the event case to that button. 


Joerg Hampel, CLA & LabVIEW Champion | hampel-soft.com | alarchitects.org
Contributors