DQMH Consortium Toolkits Feature Requests

In our current practice, we encapsulate the content of DQMH MHL events within subVIs to maintain a tidy diagram and especially to facilitate the seamless propagation of changes to similar projects that use the same implementation. 

I think It would greatly benefit the DQMH framework if it could autonomously generate these subVIs as part of its MHL event scripting process.

Current situation:

Expected situation:

As users of SVN for source code control, we rely on SVN-Locks to maintain a conflict-free development environment when collaborating with multiple project team members.

When working on DQMH Projects as a team, it would greatly enhance our workflow if we could selectively apply SVN locks to specific subsets of the project.

Currently, the DQMH scripting necessitates write access to the entire project, limiting flexibility in group collaborations. 

Is it feasible to consider modifying this behavior to provide increased flexibility and efficiency for group work?

It would be awesome if the DQMH validation tool could go back more than one version.

eg.  If you open an old piece of code (that was written in say DQMH 4.2), the only way to upgrade it to 6.1 is to one version at a time, upgrade the code step by step.  This would mean the following:

 - Install DQMH 5.

 - Run Validation tool

 - Install DQMH 6

 - Run Validation tool

 - Install DQMH 6.1

 - Run Validation tool

This is a rather painful process, and when faced with this, I have decided to simply implement the module again starting from the latest version, and porting the code over rather than go through that.

Neither approach is obviously ideal.

We really need a tool that can convert an older module up to the latest standard.  This will become a more common problem now that we have DQMH-based code out there from 2018 onwards.  The more people use it, the more this problem will surface.

I sometimes need to launch and stop a tester programmatically (mainly from TS).

I can launch the tester programmatically using VI server, but I need to do this wrapper for each tester.

To stop a tester, there is no way to actually do it programmatically.

The only action that stop a tester is manual one (closing the tester's window).

I would like a Tester API (basically 2 VIs) created by default in every module that would allow me to launch and stop a tester programmatically.

Problem: 

Currently the DQMH stock requests / broadcasts (eg: Stop module, Hide panel etc) are mixed with the user created requests / broadcasts so if one likes to check which requests, broadcasts etc are in the module he needs to open different subfolders and visually filter out the stock events. 

This is a readability issue which makes it significantly harder to quickly understand (or recall) what events are available for the given module.

Possible solution: 

Instead of mixing the stock DQMH events with the non-stock events create a virtual folder above all the virtual folders called "Module Specific" with subfolders like Requests, Broadcasts, Private and Controls and put everything the user create to there by default.

Big advantage of this of organizing the files this way would be that one could assume that whatever is module specific can be found in the these dedicated folders instead of spreaded somewhat randomly in the virtual folder structure of the module. I said somewhat randomly because the strucure as is currently is hard to read so developers try to make it more readable, everyone on his own way (eg: creating different folders, prefixing the user created events etc). So besides the increased readability of the module by applying this feature there is a very good chance that modules' structure will become more standardized across developers working at different companies.

JKI State machine has a great tool that comes with it, when you right clic on a BD element of a VI that contains a JKI State Machine, the option menu has the item "JKI State Machine explorer", fantastic tool to facilitate browsing the numerous frames of the case and of the event structure.

A similar tool for the DQMH module would be a great help!

I dislike using Clone IDs, Whenever I have used Clones in real life application, I always start by editing the Start Module VI and adding in a Clone name input. As I do this for all my clones the input name tends to be specific like 'Bay Name', or 'PSU Name' but a generic 'Clone Name' would be good.

I then pass that Clone Name into my MHL Data cluster in 'Initialize', each clone now knows it own name this allows things like

• A Request to all Clones to get the instance for a name, so calling code can work in terms of Set Voltage(UUT_PSU), Set Voltage(RIG_PSU) rather than Set Voltage(45568) Set Voltage(40056), making a clone manager more code easier to read. -- I know this could be done in a clone manger with a Map or table, but I like the idea of the Clone know its own name.
• As the clone knows it own name, because I gave it its name, this means clone instance configuration is easier, I have can have a single configuration ini file with each clone name as separate sections or I can have each clone read from its own ini file simple based on its own name.
• Modules other than the clone manager can if needed talk to the correct clone using the name they do not need to know about the instance.

Thinking about this it would be, to my mind, a great feature addition to DQMH is by default there was a optional for providing a clone name at startup that was accessible as a Mod Admin property alongside the Module ID.

Please create an additional toolbar named "Delacor" that has at least 2 buttons: one to create a new module, one to create a new event.

It's too tedious to go everytime via menu Tools, Delacor, DQMH, bla bla

In this picture you can see on the right the JKI tester toolbar, and also the NI Unit Test Framework toolbar.

thanks

Running the validator on bigger projects takes quite long.

Would it be possible to speed up the process by running the validation of the modules in parallel?

Additionally: Also in CI/CD we know if the module has changed at all. It would be nice if the cli-module-validation could be called with a .lvlib instead of a .lvproj. Therefore, it could be handy to have a VI which lists all dqmh modules in a .lvproj.

When creating a Request and Reply event, the scripter creates the corresponding calling code.
In this code the request VI is added on the diagram with all inputs empty (except for the error IOs).

Most of the time I select the VI and perform a 'CTRL+space + CTRL+D' to create all input/output controls and indicators.

And, therefore, it creates a boolean control for the 'Wait for Reply ?' input.

99.9% percent of the time I replace that control with a constant value, since I know if I need to wait for a reply or not for that specific request. And there is (close to) no chance that I'll need to set that using a control on my tester GUI.

Maybe placing the request VI and adding a constant linked to the 'Wait for reply ?' input on the tester diagram would help reducing the number of redundant actions one achieves when coding the tester ?

Connecting the constant would avoid having to change a control created by the 'CTRL+space + CTRL+D' shortcut into a constant each time.

If you want to pass a parameter to your module when it starts, you can add that parameter as an input to Start Module VI:

The way you define the type of the Call By Reference node (to accept the new parameter) is usually by dragging the Main VI into the VI Reference constant wired to Open VI Reference. However, sometimes a different VI may be used to define the type, especially if there are multiple DQMH Modules in your project that take the same inputs on initialization. Also, the opposite situation can occur where you add an input to the Main VI connector pane, but forget to add that input to the Start Module VI.

If the connector pane of the Main VI doesn't match the VI Reference constant in the Start Module VI, you will receive an error when attempting to start the module. I propose that we add a Validate Module test that detects this situation (connector panes of Main VI and VI Reference constant don't match) and returns a validation failure.

Original idea from Matthias Baudot in https://anchor.fm/wired-in-software/episodes/Episode-6---Matthias-Baudot-from-Studio-Bods-emtpti

When you have lots of modules (20+), initializing module selector control tends to take seconds that can be annoying when you need to use the scripting tools.

Finding a way to remove this init time would greatly improve the user experience in large application development.

Request:

Provide a mechanism to externally name the cloneable instances and retrieve the names to populate the "Select module" ring. 

Reason:

Lets say I have three power supplies. Having a ring displaying eg.: 5,6,7 has way less information than lets say "Main PS", "DUT PS", "Battery PS". Sure in the background they will be just numbers so the numeric part of the ring should remain the same. If no name is provided for a given instance then nothing should change.

This is a relatively simple change, can be done easily with a template so not sure if this should be the part of a DQMH release.

If feasible, I would recommend a tool to navigate an application. This request may be considered an extension to, and as the inverse of, the function "Find DQMH Event Frames" 

Include a navigation window with structure of Modules -> Broadcast Subscribers and Request Makers. 

The JKI State Machine Explorer is a great example of the developer experience I'm hoping for. 

Another approach may be the ability to right click on an event case and select "Find Broadcaster and/or Requestor" and show corresponding MLH case. 

Where do I send my $100 attached to this request? 😉 

Thanks - Jared

Hi,

Including DQMH modules into our application framework, we need to script the creation of new modules / requests and so on.

However, current scripting GUIs do not have any controls connected to the connector pane.

Also, even if we could pass some values to these interfaces, we would even need to control if we want to show their HMI or control the creation / cancellation of a scripting action whitout having to press on the OK / Cancel button.

Allowing to programmatically control the DQMH scripting VIs would be great !!

Here's something I've been running into lately (for whatever reason hadn't done a ton with cloneable until now). I'm sure someone else must be as annoyed by this as I am.

Why do all the cloneable broadcast event VIs take a module ID and not a module admin object? Is there ever a reason where I would want to use a different module ID rather than the current one? I can't think of any, but maybe I am just not that imaginative.

Everywhere I drop a broadcast I have to also drop a property node and pull off the Module ID, why not just incorporate that into the broadcast VI?

By the framework not including that it requires extra effort on my part to wire it all up and it clutters my block diagram with property nodes that don't really add anything.

I'm sure there is probably some reason it was done this way. What use case am I missing where I would want to use a different module ID? and if there is a use case for that, I'm assuming it is an infrequent or minority use case. Is there some way we could make the primary use case the default (ie use the current module ID) without requiring all these extra property nodes, while still maintaining the ability to use a different module ID if needed?

Not sure if there is a way to do this and also make it backwards compatible? Maybe leave the existing broadcast vis as is and mark them as deprecated or something and add a wrapper that takes the module admin and then calls the 'deprecated' VI.

All I know is that there has to be a better way than dropping a property node every time or me manually creating a wrapper for every broadcast.

How does anyone else currently solve this problem?

It would nice to catch circular dependencies in the DQMH Validator Tool. Catching all circular dependencies would be hard ie A->B->C->D->A, but the simple case would be easy to catch A->B->A. This would be the case where A registers for the broadcasts of B but also sends requests to B.

If anyone has an easy way to catch the more complicated case, I'd be all for that too.

It's not completely related to the framework itself, but I'd like to have a tool to generate an "error VI" (like Module Not Running--error.vi) with custom error code not already use in the project or selected among the existing ones.

If we could also have an API that list error codes and text, I would like it 🙂

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

This has been discussed before in the now deprecated "Feature Requests" thread