DQMH Consortium Toolkits Feature Requests

It could be nice if "reply code" for a request and reply would we wrapped into a subVI and not scripted into the MHL.

For example, a request and reply named "Request X" would generate 2 VIs:

- One VI "Request X.vi" to send the request.

- Another VI "Reply to Request X.vi" to send the reply to the caller from the MHL.

Screenshots illustrate the idea. "bis" files are just a cosmetic alternative to simplify the reply VI inputs and wiring.

I like the idea of having messaging code into subVIs of the framework not in the MHL.

Error management in a DQMH module could be compatible with multiple errors feature in error clusters. 

>> Send an « Error reported » broadcast for each error in the error cluster. 

>> Display only the first / last error in the module tester. 

>> Apply errors filtering for each error in the error cluster. 

I am using DQMH 7.1.2.1547 and have found that when I create new Local Instance Only requests for modules with a helper loop that registers for broadcasts of other DQMH modules, it shifts the User Event case for the other DQMH modules in the helper loop only down by one event. Typically in these modules, I am only registering for other broadcasts in a helper loop, leaving the event handling loop only with the events for the current module. Whenever I create a new local instance I have to edit each test case to select the User Event I previously configured. This behavior seems to be the same regardless of the event consuming loop. If this can be corrected in the next update I would appreciate it!

For those of us building DQMH modules into PPLs as runtime dependencies, we can add requests and distribute an updated PPL with no issue. Broadcasts on the other hand cause a problem because all broadcasts appear on the connector pane of not just "Obtain Broadcast Events..." but "Start Module.vi," so every user of a module will have a static call site with that big cluster. If I build an exe that calls "Start Module.vi" from an external PPL, and later a broadcast is added to the PPL, the exe will break and need to be rebuilt because the conpane has changed.

Instead, for this use case it would be better if the big cluster was totally private (not just the typedef) so it does not occur on callers' block diagrams. Instead, each broadcast would have a public VI that returns the UE (or a pre-registered refnum) for that specific broadcast. This would allow new broadcasts to be added without breaking existing compiled callers.

Because this approach won't really benefit anyone who isn't building PPLs/VIs to be loaded directly in the runtime engine, it may make sense to have it be an option when creating the module or perhaps only when adding broadcasts to an existing module.

I propose helper loops (HL) to register only for explicitly used events instead all cases.

Arguments:

• Improves readability: It becomes immediately clear which events the HL reacts to.
• Reduces cognitive load: No need to navigate through case structures to understand behavior.
• Enhances maintainability: Adding/removing events is more transparent and less error-prone.

This would align well with our preference for simple, explicit, and robust designs.

Currently, this is not possible, as it would break existing scripting functionality, when creating a new request, which should be handled by the HL.

By the way:Great that we have seen the scripting of the helper loop already being improved regarding...

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

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.

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.

When using the "Rename DQMH Event" feature, the scripting tools regenerate the VI icon and erase any customization in the VI icon (icon text, icon template, layers ...).

It would be greate if the scripting tools could update icon text and "Border" layer but keep icon template or additional layers if existing.

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.

We utilize VI Analyzer in our code analysis, but when using DQMH modules, it requires a lot of copy and paste for the same issue in any DQMH event code.

I am proposing that DQMH ship with the #Via_ignore for certain VI Analyzer tests.

Examples:

-Obtain Request Events (this is a non-reentrant VI in a Shared Clone reentrant VI)

- Wired Terminals in Subdiagrams (terminals from a wait and reply are in a subdiagram)

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.

Similar to this request.

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

Hi, I'm currently refactoring some old code that contains helper loops, those helper loops weren't created using the DQMH Scripting tool, to homologize them, I'm following the helper loop prerequisites described here , one of the prerrequisites is that the error debug input to have a constant with the label "DQMH_HELPER_LOOP" and write the actual name of the helper loop, what I'm proposing here is to change the Error Debug name to this label only for the Error handler - helper loop.vi

This will help us create a constant for this input with the label already there, eliminating the need to visit the DQMH documentation website to get the right name.

Best Regards,

Enrique.

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.

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?