DQMH Consortium Toolkits Feature Requests

When dropping the Error Handler and creating the string constant from the input terminal, the DQMH validator will complain about the wrong naming of that constant.

"The Helper Loops do not have a DQMH_HELPER_LOOP_NAME string constant wired to the 'Error Debug' input of the DQMH Error Handler - Helper Loop subVI"

Please change the name of the string input for the Delacor_lib_QMH_Error Handler - Helper Loop.vi from "Error Debug" to "DQMH_HELPER_LOOP_NAME".

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.

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.

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.

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 🤔

Any reason not to?

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.

When preparing a project for Lumos tracking...

Lumos adds "Trace VIs", when migrating this code to another PC without Lumos installed
When opening DQMH module it asks for all the "Trace VIs" and breaks the code...

It be great to have another option to Remove or Un-prepare project for Lumos Tracking and be able

to distribute this code without Lumos installed

Thanks! Great tool!

In DQMH 7.0 you can create private requests now. This is a feature that I really like and the more you use something, the more ideas come to you.

In my current project I created a private request and shortly after I realized, that I need to call this request from another module. I tried to convert the private request into a public request, but this wasn't easy.

So here comes my idea: why is the conversation (public requests → private requests and privat requests → public requests) not included in the Convert DQMH Events dialogue? That would be the place where I would intuitively look for 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