DQMH Consortium 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

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

 

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

Status: Done. Implemented in DQMH 3.0

 

 

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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?
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

 

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.

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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?
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

 

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.

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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?
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

 

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.

 

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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?
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

 

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.

 

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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?
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

 

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.

 

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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?
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

 

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.

 

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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?
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

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.


For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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?
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

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


For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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?
FabiolaDelaCueva
Active Participant Active Participant
Active Participant
on

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.

"


For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out 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?
Mads
Active Participant
Active Participant
on

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.

Mads
Active Participant
Active Participant
on

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.

K.Ross
Member
Member
on

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

mRadziwon
Member
Member
on

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.

 

 

 

mRadziwon
Member
Member
on

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.

mRadziwon
Member
Member
on

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.

psmorris
Member
Member
on

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

jdebuhr
Active Participant Active Participant
Active Participant
on

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

joerg.hampel
Active Participant Active Participant
Active Participant
on

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


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

Barney10
Member
Member
on
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...

 

K_Bull
Active Participant Active Participant
Active Participant
on

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. 

joerg.hampel
Active Participant Active Participant
Active Participant
on

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


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

joerg.hampel
Active Participant Active Participant
Active Participant
on

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


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

doyles
Member
Member
on

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

joerg.hampel
Active Participant Active Participant
Active Participant
on

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


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

Darren
Proven Zealot
Proven Zealot
on

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.

nilsdornblut
Member
Member
on

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.

 

 

Kenny_K
Active Participant
Active Participant
on

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

Ozfarmboy
Active Participant Active Participant
Active Participant
on
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 and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Ozfarmboy
Active Participant Active Participant
Active Participant
on

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 and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Ozfarmboy
Active Participant Active Participant
Active Participant
on

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 and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Ozfarmboy
Active Participant Active Participant
Active Participant
on

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 and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

joerg.hampel
Active Participant Active Participant
Active Participant
on

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. 


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

T.L.
Member
Member
on

Error tolerant "Module Did Init" Broadcast Vi

 

if i put some initialization code into the "Initialize" MHL-Case and there occurs an error, the Module Did Init Broadcast will not be send if the error wire is wired through.

That's why i have to modify the code to route the error around the broadcast-vi:

 

With Error Handling.PNG

 

I like to have the error routing code integrated into the "Module Did Init" broadcast vi:

 

Modified.PNG

 

This would guaranty the message will be send always and makes the code in MHL case cleaner.

 

regards,

Thomas

joerg.hampel
Active Participant Active Participant
Active Participant
on

Thomas did you see this discussion: https://forums.ni.com/t5/Delacor-Toolkits-Discussions/DQMH-Module-Did-Init-broadcast-event/td-p/3776...


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

Ozfarmboy
Active Participant Active Participant
Active Participant
on

Feature Request: Request and Wait for Reply: Make timeout an error bool input

 

Update the Request and Wait For Reply vi to have a boolean input titled "Make timeout an error".  If set to true, the VI would generate an error from the timeout scenario, and hence avoiding the need to handle the timeout after every call of a Request and Wait For Reply.

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

joerg.hampel
Active Participant Active Participant
Active Participant
on

I gotta say that we modify the Request and Wait for Reply most of the times to make the timeout an actual error out. I would actually prefer changing the behavior to always throw an error when the reply times out. See James' comment here.


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

joerg.hampel
Active Participant Active Participant
Active Participant
on

API Tester and request VIs for cloneable modules

 

When creating new requests, DQMH 4.2 now not only creates the case in the API Tester but also creates a button and links it to that event case. For singleton modules, all done and dusted. For cloneables though, I still need to wire the module ID. 

 

Bildschirmfoto 2019-03-07 um 18.26.15 (2).png

 

Feature request: When scripting a new request into the API Tester, connect the module ID wire coming from the shift register to the "Module ID" terminal of the new request VI.


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

Ozfarmboy
Active Participant Active Participant
Active Participant
on

Feature Request: Option to create a cloneable version of a singleton module

Bonus Feature: Option to create a singleton version of a cloneable module.

 

The benefit of such a feature would come from the fact that we have a number of internal team templates, and we often need to maintain update two of each ( a singleton version, and a cloneable version).  The main reason we need to do this is because RT requires all modules to be cloneable, but Windows does not.  So when we build up our internal team templates, we need to create two - a singleton for Windows and a cloneable for RT. But if we had such a feature we could simple code up a singleton, and then convert it (or save as) to a cloneable.

 

convert singleton to cloneable.png

 

 

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

joerg.hampel
Active Participant Active Participant
Active Participant
on

Chris, I'll pm you regarding the need for cloneables on RT (there isn't one).


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

Ozfarmboy
Active Participant Active Participant
Active Participant
on

OK, thanks Joerg.  

 

Just to be clear though, this feature is not just about RT (although it was a big motivation for it).  It could apply to non-RT modules.

Christopher Farmer

Certified LabVIEW Architect and LabVIEW Champion
DQMH Trusted Advisor
https://wiredinsoftware.com.au

Darren
Proven Zealot
Proven Zealot
on

Feature Request: Script the 'Status' string update code in the API Tester for new broadcast events

 

When I create a new Broadcast, here's what the new frame in the API Tester looks like:

1.png

 

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

2.png

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

REAL!
Member Member
Member
on

Feature Request: Ability to create several events that have the same payload at the same time.

 

In a recent project I had to create 15-20 "request and wait for reply" events, each of which had the same payloads. On my machine it takes 20-30 seconds to create each event, so not long enough to actually do anything, but long enough that I start to get annoyed.

 

Ideally I would like to be able to have a "create multiple" option, supply the event names (method open for discussion), select my payload stuff and click OK. I can then go and make myself a cuppa while it crunches away on all the scripting loveliness.

 

I believe that this could have saved me quite a lot of time in this last project, not to mention it's more efficient as I can do parallel tasks (like drink tea).

 

As an expanded option, I could see the benefit of being able to create all the events from an Excel type sheet. That way in an architecture meeting each event can be discussed and decided upon, diagrams drawn, spreadsheet created and then just loaded in and boom, done! BTW, I use the terms "Excel" and "spreadsheet" as examples, I hate both concepts but everyone knows what I mean.

 

Cheers,

Darren.

REAL!
Member Member
Member
on

Feature Request: Option to not script the "todo" type labels when creating new events

 

After using DQMH for more than one project I imagine most people just immediately delete the labels describing what needs to be done in each case generated. While they are very useful the first few times, it would be handy if there was an ini token or a checkbox where you could turn off their creation.

 

Cheers,

Darren.

Mads
Active Participant
Active Participant
on

Feature request: Plugin framework / Automated packaging into ppl upon build

 

The current way to use DQMH with plugins (packing it into a ppl) is, unlike so many of the other nice features of DQMH, not a smooth automated process - and doing it means you lose access to many of the scripted features of DQMH.

 

It would be great if plugin architectures were handled by the toolkit itself - meaning we could use DQMH as it is all the way until we need to build the application, and then the DQMH toolkit would automatically take care of the steps required to convert the solution into one based on ppls Smiley Very Happy

Olivier-JOURDAN
Active Participant Active Participant
Active Participant
on

Feature Request: Add module description field to Add New DQMH Module window 

 

When creating new modules, I'd like a way to add a description (like for a new event) to enforce good practices and allow automatic a future documentation tool to retrieve information.

 

Note: description could be added to module lvlib. 

 

[EDIT]

  • May I suggest to name the field Responsability instead of Description ?
  • May I suggest to have this field mandatory ?

[\EDIT]


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
REAL!
Member Member
Member
on

Feature Request: Renaming of Module Template during creation

 

When creating a module template there should be an option to run the "rename DQMH module" process first, however instead of just renaming the original it should create a duplicate module with the new name. 

 

Why?

 

Recently I created a new template from a "real" module (i.e. one I was actually using in the project) and then when I created a new module using the template it recreated the real module, along with all the events, SubVIs etc. I had added since creating the template. I assume this is something to do with the library file still being in memory/part of the project. I didn't specifically set out to create a template, which is what I should have done.

 

Hope that's in some way clear.

 

Cheers,

Darren.

joerg.hampel
Active Participant Active Participant
Active Participant
on

Message Name in Error Handler for Message Handling Loop

 

Sometimes, the error cluster that feeds into the Delacor QMH Error Handler - Message Handling Loop.vi doesn't convey enough information to identify the origin of the error. For example, an Error "91 - Variant To Data in xyz.lvlib:Main.vi" does not tell me in which MHL case the variant to data operation failed. It would be nice to have the selector label of the MHL's case that the error occurred in.

 

Bildschirmfoto 2019-09-30 um 13.10.09 (2).png

 

Feature Request: Somehow (not sure what the best way would be) make the error handler include the last message's name (string) in the error broadcast.


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

danny_t
Active Participant
Active Participant
on

Hi,

 

A minor feature request / bug report running DQMH 4.2.1.46

 

 When renaming a module should also rename the Test API.vi

 

I had a working module called Results that was a singleton and I decided that I really wanted a clonable version. So I used the rename module option and changed Results to _Results ready to create new new Results module, Did not intend to keep the singleton module I just wanted it for reference.

 

The rename nicely works I now have a _Results.lvlid in a new folder _Results all in my project but the tester VI is still called Test Results API.vi. this means when I go to create a new Results module the scripts fail with a error 7 file copy on the trying to create the new Test_results API.vi as there is already one in the project.

 

Took me only a few minutes to realize what the problem was and sort it, but it could catch others out.

 

cheers 

 

Danny

Danny Thomson AshVire Ltd
Darren
Proven Zealot
Proven Zealot
on

When I need one of the reply payload values of a Request and Wait for Reply VI, I need to unbundle 100% of the time. What if the Request and Wait for Reply VI output the reply payload elements individually on the VI conpane so I don't need to unbundle? I often make this change manually to my Request and Wait for Reply VIs. And I never unbundle the error from the payload, since it's already merged into the error stream inside the VI. So I wouldn't expect that output to be on the conpane. But all the other payload parameters, you betcha!

Contributors