DQMH Consortium Toolkits Feature Requests

This suggestion is inspired by the following recent post in the LabVIEW Idea Exchange: Remove description of Error In and Error Out terminals 

It would be useful if the description of all error in/out terminals in all DQMH VIs was cleared (set to empty string). This would save 638 characters (0.62 KB) of disk space for each DQMH VI that uses error in/out terminals. It may help reduce EXE sizes, and may help speed up project load times and EXE build times, even if just by a fraction.

Many thanks,
Petru

I've been using cloneable modules on a regular basis. Wiring consecutive request VI calls become tedious with regards to the module ID. Having that as a pass-through makes so much more sense. This is kind of like a reference to the cloneable module if you think about it. So that wire should be treated as such on the connector pane.

This request is focused on simplifying the block diagram, one node at a time. it seems that when receiving a request and reply, you always need to pass the current module ID back. This seems to be a very common use-case. So common that perhaps there should be a convenient Module ID indicator on the Addressed to This Module VI? The purpose of this would be to reduce the clutter and allow more space for module functionality vs framework code.

When using the API Tester to, well, test my module, and an error occurs, I always would like to be able to clear the error indicator before moving on - just to make my life easier by being able to see clearly when new, further errors occur. 

Like this:

Is there anything at all speaking against adding this nifty little feature? 

DQMH does store some settings in the LabVIEW.ini file. For example, "The last used virtual folder for tester, virtual folder for module, and relative path on disk for module" (see WhatisNewInDQMH.html). 

I would like a Settings dialog that exposes all available settings and configurations so I

a) can learn about what's configurable
b) can switch settings easily and quickly

We could implement a "Tools -> DQMH -> Settings..." menu or add to the LabVIEW Options dialog.

This typedef should be public:

Here's a thread where a DQMH user is confused by a strange code break when they use subVIs to deal with launching modules. Here's another.

This datatype necessarily occurs in wires on the block diagram when registering for broadcasts therefore it is not "really" private, and scoping it private prevents us from using subVIs to register for events. Since subVIs are the main way we segregate code and prevent block diagrams from growing without limit, it should be possible to register for events in a subVI.

Over the years I find myself adding the following two requests to my modules more and more frequently:

The MHL code for these requests is very simple, and it doesn't get in the way for modules that don't interact with subpanels. I think these requests should be added to the standard singleton and cloneable templates.

I am familiar with the "create your own module template" argument against ideas like this. I've made those same arguments before. And I've implemented my own module templates with these requests before. But present-day, I equate the utility of these subpanel functions with the utility of existing core requests like 'Show Panel', 'Hide Panel', and 'Show Diagram'.

In addition to adding these requests to the core templates, we should also add a subpanel to the API Testers to (1) be able to test these requests (obviously), and (2) demonstrate the ease with which a DQMH module can be integrated into an existing subpanel-based UI.

It would be interesting to have the option to export the validation results from the UI with as much information as possible.

Adding the option to the CLI tool would also be interesting to create reports.

Format could be a CSV file (or HTML or PDF using the Asciidoctor toolkit 😉 ).

The 'External Launch' module data for a DQMH module indicates whether or not the Main VI was started externally (True) or launched as a top-level VI (False). For the top-level VI case, the last thing that runs in your DQMH Module Main VI is the following:

I propose that we change the code to this:

When running a Main VI as a top-level EXE, it should have standard shutdown behavior.

We all love that DQMH has that nice small icon of an antenna which allows identification of broadcasts easily.

Why not have something similar for requests to indicate, that this VI sends a message to the module and asks it to do something? 🤔

• 📩
• ➡️
• 📄
• 🗨️
• 🎯

Maybe place it to the left and use a complete different colour.

Feature request: The Add New Event dialog should always check the "add a button in the tester" Boolean by default.

Currently, it remembers whether you had it checked last time.

Reason #1: I think not adding a button is an exception, not the rule. Even though I didn't need a button last time doesn't mean that it's a pattern for how I work.

Reason #2: If you don't check it, the tester has empty events that are kind of useless until you add a button or reassign them to a different event. So you aren't saving the user any effort by not adding the button. My thinking is that it's the same amount of work to remove a button you don't want as it is to fix a broken event case.

Similar to this request.

I would like a button, on the API tester VI that ships with DQMH, to clear the status display.

Many DQMH developers (including myself!) encounter the stumbling block of firing requests before a module is "ready". We assume that the following code is sufficient for starting and synchronizing a module:



The 'Synchronize Module Events' VI ensures that request event references are valid, but it doesn't do anything about ensuring that the module is actually ready. One very common scenario is a module Main VI that includes code in the 'Initialize' frame of the MHL that fires private events to initialize Helper Loops. If the VI that called Start Module isn't waiting on the Module Did Init broadcast, then it could immediately fire a request after calling Synchronize Module Events, and if a helper loop is registered for that event, then helper loop could run the event frame for that fired event before the MHL has had a chance to fire the private event to initialize the helper loop. There are many other possible pitfalls, but this is one of the more common ones I've seen.

To solve this issue, I think DQMH should ship with a Public API VI that is a wrapper for Start Module + Synchronize Module Events, but includes the extra step of waiting for 'Module Did Init'. The module author needs to ensure that the Module Did Init broadcast is called after all necessary initialization code... if they do so, then it is "safe" to begin calling events externally.

Here's my proposed interface for the Start Module and Wait for Initialization VI:

And my proposed implementation:

If this VI shipped with the DQMH singleton and cloneable module templates, it would help us avoid module synchronization + initialization issues like what I describe above.

When renaming an event, the dialog allows you to edit the description. But it doesn't allow you to add a carriage return/newline, so you're limited in the kinds of edits you can make.

I'd like to see the ability to enter CR/LFs.

This is a blatant copy of an idea from 2021, but it came up in a recent customer meeting.

While I agree that modifying event arguments is possible to do manually, can we take another look at automating that?

Right now if an argument is added to / removed from the typedef, it requires the developer to manually perform a series of (scriptable) actions:

1. Open the public event VI
2. Create a new control or indicator OR remove existing
3. Expand the bundle/unbundle, and wire it in OR collapse the bundle/unbundle to get rid of the deleted argument(s)
4. Wire the new item to the conpane and set it to Required (in the case of a control)
5. Update the EHL case to make sure the cluster is properly bundled (can be checked by the validator)
6. Take care of updating the Tester

So here we have a multi-step process where things could be easily forgotten. Order of operations matters. The steps are well defined. The activity is dull. It feels like a good candidate for automation.

Loving the latest Validation tool, but I found a few improvements.  Putting it all here in one feature request for now.

1. Make Validation issues sortable by issue
   Background: I recently ran the validation over an old application (DQMH 5).  It seemed to sort things by VI.  It would be nice to be able to sort the list by issue, so that you can easily tick off each issue one at a time.  You can do that at the moment by multiple clicking separate lines, but it would be nicer if it was grouped together.

2. Put a tip somewhere on the panel: "Tip: Double click a row to show the issue." 

3. Double click didn't seem to work every time.  I tried it on a few issues, and nothing seemed to open or do anything.

4. Display a warning dialog after the Fix All Issues button is pressed.  I accidentally pressed Fix All Issues instead of Fix Selected Issues, and it just blazed away.  Suggest a dialog: "This will fix all issues listed here.  Do you want to continue?"

5. Fix All Issues button location - I prefer to use Fix Selected Issues, and it's so tempting to just press Fix All Issues.  Not sure what the answer is here, but perhaps Fix Selected Issues should be where Fix All Issues button is.  This is probably quite subjective. If we implement previous suggestion, then this may not matter as much.

6. Where an issue will actually potentially delete/remove code from an existing VI, I suggest rather than a "Note:" description, separate the text and call it a "Warning" or something similar, and colour in red if possible so that it stands out. I can't remember which issue this was related to sorry, but it was only one issue.

7. When we get this:
The block diagram of RT Event Logger.lvlib:Main.vi contains a Register For Events function labeled "DQMH_REG_EVENTS". The source of the RT Event Logger Request Events terminal on this function is named "Event Logger Request Events". In order for the DQMH scripting tools to work correctly, change the source of this wire (usually a subVI output or a user event constant) to have a label of "RT Event Logger Request Events" instead.

This information was redundant by the time I'd already fixed the sub VI.  Perhaps add an extra note to this description: "Note: This may become automatically resolved by addressing the associated Sub VI" or something to that affect.

I like the new additions to DQMH 7.1 including the Private Wait for Reply events. It's a shame however, that the feature was not fully fleshed out. It would be convenient to have the ability to convert Private Requests to Private Request and Wait for Reply.

There doesn't appear to be a distinction between standard Requests and Wait for Reply type requests for LOCAL INSTANCE.

I think this why when using the Remove DQMH Event Tool on a LOCAL INSTANCE Request and Wait for Reply, the "Request (Reply Payload)--cluster.ctl" file is not removed from the library and deleted as it is for public Requests.

Not a big deal, but would be a nice addition to not have to remember to remove it manually.

Thanks,

Aaron