DQMH Consortium Toolkits Feature Requests

Well, it is a corner case, but I somehow ran into the situation, that the xml metadata at <LabVIEW Data>\DQMH Module Templates\ defined a name for the API tester which was not correct, resulting in an error 7 message

Please add the path, which the scripting is trying to copy to the message, as a first hint.

Adding a note to check the XML would be a second nice hint for the user.

Offtopic: Lastly, I wonder, why the name of the API Tester needs to be present in the XML at all. I was expecting that the module validation fails, if the tester doesn't match the naming rule, which is also applied, when a module is being renamed. A quick test shows, that my assumption is not correct: The API Tester of a module can be named randomly. I am pretty sure, I have applied Fixes to API Testers via the validation dialogue in the past and I wonder how that works, if the naming rule is not required 🤔

Using DQMH 7.0.1.1316 (currently the latest version), the error message generated inside the Default case of the Message Handling Loop is "The invalid message string "%s" was received in the Message Handling Loop for module "%s"."

"The invalid message string "%s" was received in the Message Handling Loop of module "%s"." might be a small improvement.

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.

Add an always available "None" option in the drop list, 

Selecting this option will avoid creating a case for the event in the Message Handling Loop (MHL) nor any other place

Here...

so by default this droplist will include, 
- Event Handling Loop
- None (this will avoid generating a consuming case anywhere)

or it could be 

a checkbox next to the consuming event loop droplist

to allow developer to select avoid generating it

I saw that this request for automatically refreshing the modules was released: https://forums.ni.com/t5/DQMH-Consortium-Toolkits-Feature/Auto-press-the-refresh-button-on-cloneable....  I am thrilled that idea was submitted, approved, implemented, and released by the time I got here to submit the idea.

I believe there is one other aspect of the API Testers that should be configured by default: the visibility of the Show Block Diagram and Show Diagram on Init buttons.  Since these buttons have no use in an executable, they cause confusion for operators.  I would propose the following code is scripted (instead of me needing to add it to every API Tester):

Thanks,

Scott

When I first saw the auto-generated VIs in the DQMH framework, I was surprised at how chaotic they looked, despite being automatically generated. I thought, "Alright, it’s auto-generated anyway, so there's no point in worrying about it." However, it kept bothering me. Eventually, I decided, "I’ll replace the template with one where the elements are better organized, and I can also add a few small modifications of my own."

However, when I tried to do this, I realized that the templates didn’t include stubs for everything, and what was generated from scratch covered much more than I had expected. This completely disrupted my plans.

Therefore, I would like to request a modification of the generation process so that the templates include more stubs, which the generator replaces in a more predictable manner. Additionally, I’d appreciate clear documentation that would allow me to customize the template without risking breaking anything. Perhaps I’m mistaken, but I don’t think there are that many possible combinations in these templates?

I’m most interested in the request templates, but I believe the idea could be generalized to other cases as well.

I would like a new option in the DQMH-> Event menu and two options within that sub-menu for changing the scope of request events.

A new Change Request Event Scope sub-menu with the following options:

And the following options within that action:

1. Change Request event from Public to Private
2. Change Request event from Private to Public

This would be helpful for properly scoping events in projects that are inherited and all events are set to public.

Thanks,

Scott

I’d like to suggest making the DQMH scripting tools API public. This would allow new events or modules to be generated programmatically.

My use case: I’d like to take any non-DQMH library and generate a DQMH layer for the library’s public API. With some clever coding and discipline, this could automate the creation of a TestStand API based on DQMH, which would be incredibly useful.

Moreover, public APIs often encourage the development of supporting tools and promote the technology, especially within creative communities.

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 creating a new DQMH event, I'd like this

When creating a batch of modules at the begining of a new project, it may be usefull to be able to create a new event in more than one module at a time.

When the DQMH Consortium introduced the support for private requests with DQMH 7.0, a conscious decision was made not to support synchronous requests with reply, to avoid dead-lock scenarios.

With the way we at HSE start additional DQMH modules from any given DQMH module (by sending a request from the MHL to the EHL to start and register for modules, then reply back to the calling MHL case, so the whole process becomes synchronous), it would be super helpful if we could script those private "start submodule" requests the exact same way as all other private requests.

TL;DR: Add support for private Request and Wait for Reply.

Edit: After internal discussion, let me add that I know how to make a regular request a private one by setting the access scope. I don’t want to do that - I want the private Request with Reply to be the same as all other private events, and not a modified public request.

Edit2: If you scroll down, you'll see that Manu added a vital piece of information. We usually communicate with one of the EHLs/Helper Loops, not the MHL. So scripting should not create another case in the MHL but keep the reply in the targeted EHL/Helper Loop.

For some reason I need to know the module name of the module that I start.

Module name constant is a private VI and therefore cannot be called in a cller VI diagram.

Having the Start Module VI returning this information could be useful (instead of specifically creating a R&R just for this purpose).

Today DQMH scripters add comments with specific hashtags. But some of these hashtags names are very generic (for example #CodeNeeded or #CodeRecommended).

Adding a 'DQMH_' prefix would allow a better isolation of DQMH related hashtags in the bookmark manager (ie. #DQMH_CodeNeeded).

Actually some DQMH tags already have this prefix (#DQMH_HowTo).

Today when creating adding a module template it is not possible to set a 'human readable' name for template.

The template name is the module's library name. Having a field to specify a more friendly name could be useful (could be set by default withe the module's library name though).

When creating a new Event, it would be empowering to be able to automatically call a VI immediately after the scripting completes. The idea is based on the behavior of the Pre- and Post-Build VI calling ability of the application build process. The implementation should provide an option to specify a VI to call and an option to generate a VI with the proper controls already on the connector pane. A proposed set of such controls would be VI references or paths to the Event VI or VIs (Broadcast or Request... or both for Round Trip) and VI references or paths to the Tester VI and RT Tester VI (if there is one).

Adding the feature would allow developers using DQMH to create their own extensions to the built-in scripting. For example, if the other feature request here is not accepted, this one would allow a developer to implement it on our own.

Once a Broadcast happens, only modules that are registered for it can access the value contained in the Broadcast. If a module starts execution and registers for Broadcasts from another module after that module has sent a Broadcast, the registering module must wait until the Broadcast happens again before it has the latest value. We have encountered some use cases where it is beneficial to know the most recent value of a particular Broadcast. In those cases, we have created workarounds such as a "Refresh" Request that can force a module to repeat all or a subset of its Broadcasts. Of course, that requires the addition of a Request and the code to handle it, etc.

The feature request is to have the Broadcast scripting create two additional VIs for each Broadcast. One VI would be Private, and it would be a data store for the value of the Broadcast event (message). The other VI would be Public, and it would be a Read Accessor for that value. I am picturing the Public VI calling the Private one, and the Private one is a Functional Global. In the Broadcast event VI, the value would get written to the Private VI's Functional Global.

Having a Public VI that contains the most recent value for the Broadcast make it easy to write small state machines or action engines that can access Broadcast value data without Event Structures.

There are other messaging architectures that implement the "Read Global" ability, and it has proven to have value for us in development of some systems.

For Cloneable modules, the "Read Accessor" could take a Module ID as an input.

Hi,

The idea is to add a converter that would allow a 'plain' (standard) module to match a template.

Let's say I've got a Singleton module that contains logic a defined Public API and a template named MyVeryOwnSingleton.

I'd like the public API + MHL cases + helper loop of the Singleton module to be 'copied' into a new (?) module based on MyVeryOwnSingleton template.

A the end, I'd have a 'MyVeryOwnSingleton' module that exposes the same API as defined in the origin module + helper loop + MHL cases prepared.

For DQMH modules written prior to DQMH 7, helper loops will unlikely have the "DQMH_HELPER_LOOP_NAME" string constant wired to the error helper VI as shown below.

This idea is to propose a new test be added to DQMH Validate Module to check that all helper loops have this string constant present.