DQMH Consortium Toolkits Feature Requests

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.

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!

As mentioned in DQMH Forum: VI Reentrance issue VIs which are required to be non-reentrant are not reported from the DQMH validation tool if they were changed (e.g. to shared clone)

Some of the important VIs which should be reported:

• Obtain Broadcast Events.vi
• Obtain Request Events.vi
• Clone Registration AE.vi
• Start Module (is already reported)
• Basically all used FGV's

Steps to reproduce:

1. Create Project with a new clonable module
2. Change all non-reentrant VIs to shared clone
   

    

3. Run module validation and execute fix
   1. Start Module.vi will be updated and changed
4. Rerun module validation
   1. No issues reported

When creating new module, I'd like a way to add a text explaining its responsibility. It will reinforce good conception practices and allow Antidoc to retrieve information to generate a valuable documentation.

Note: IMO, this content should be added to the module lvlib description.

If this field could optionally mandatory to create the module, I would find this great 🙂

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.

The below image comes from the Error Reported broadcast event case in the API Tester (as found in the default Singleton or Cloneable DQMH module templates):

This produces strings that look like this:

This could be improved by adding the "message" component of the error, by using the Simple Error Handler.vi.  Using the message makes the error report more descriptive, and doesn't rely on the user having to use "Explain Error" to review what the error code's could possibly be related to.

This produces strings that look like this:

Observe that the error message is now present in the text.

Hi,

Today when I finish creating an event / module, If I want to create a new one I've got to click again on Tools => Delacor => DQMH => Create...

Sometimes, after planning my architecture I'll need to create several modules/events in a row to start building my app.

Going through the menus each time is a pain in such case.

Maybe replacing the OK button by a Create button and a Create and Continue button would help to this (like you can have using Redmine for example).

The Create button would act like the OK button today.

The Create and Continue button would generate the new event / module but without closing the window.

It would simply reset the fields to their defaut values (and reopen a new virgin payload/paramater window in case of creating an event).

This way creating several items in a row would be really faster and easier.

(more details in the ppt attached)

1)I don't think it's possible in DQMH 5.0 to modify arguments of one Event without removing it and re-create it. Lots scripting but very useful. Perhaps, in the convert tool menu?

2) Remove automatically all vi's and controls create during event creation if there is a problem during this process. I have encountered this problem and I have lost time before understanding why I couldn't recreate the same event.

When I need one of the reply payload values of a Request and Wait for Reply VI, I need to unbundle 100% of the time. What if the Request and Wait for Reply VI output the reply payload elements individually on the VI conpane so I don't need to unbundle? I often make this change manually to my Request and Wait for Reply VIs. And I never unbundle the error from the payload, since it's already merged into the error stream inside the VI. So I wouldn't expect that output to be on the conpane. But all the other payload parameters, you betcha!

(idea originally posted here)

Reviewing somebody's DQMH code I noticed an error generated in the exit case where they had cleanup code (1) was not captured by the Tester. This is purely because the exit case causes the MHL to terminate (2), so the normal error handling strategy (3) doesn't work (enqueuing another job called Error). Can I propose, unless there's a better technique, that adding the "Error Report" broadcast at the end of the Exit case (4) is a simple way to ensure any errors generated here get reported.

Add Error Broadcast in MHL Exit Case

Hi, I would suggest adding a boolean called 'Include Dependencies' to the function on the scripting API to search for DQMH modules on the project, sometimes we have projects and we call DQMH Modules not listed on the project itself, but the developer should be aware we are calling those DQMH modules under dependencies, the Panther Dashboard for DQMH already is searching for DQMH modules under dependencies but it would be great if the native function does this functionality, also, I suggest adding a boolean array output to know if the resulting modules are located under dependencies or they are in the project.

This is how I visualize the connector pane of the 'Get DQMH Modules in Project.vi'

Thank you!.

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.

I feel like a DQMH module isn't "valid" if its Main VI or its Tester are broken. Right now a module with either of these VIs being broken can pass all validation tests. If something goes wrong after I've run some module "fixers" (or perhaps an external factor has caused my module to become broken without my knowledge), the DQMH Validate Module tool seems like a good place to let me know about it.

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.

Currently on the block diagram of VIs that implement Request events, the Bundle By Name node and associated typedef cluster constant are located outside of the case structure, even though their output is used only by the False case of the case structure (and not by the True case). The screenshot below shows the unmodified "Do Somthing.vi" VI.

The code would be slightly cleaner if the BBN and typedef constant were moved inside the False case of the event structure. This follows the clean code rule that if an action is relevant only to one case of a case structure, then it should be located inside that case. The code would then look like below.

Thanks!

When adding a new event, I think it would be really nice if the scripting code that adds the new case structure case to the main VI also scans the event description for formatting tags, and then applies them to the new case's subdiagram label. That way the subdiagram label will be formatted exactly the same way as it appears in the VI documentation. For those of us who adhere to the convention of bold facing control names as we mention them when writing VI documentation.

Lately I've been running into lots of code that looks like this:

I just need to start a module, call a request (and wait for reply, usually), then stop the module. I think it would be convenient if the module templates included a 'Start and Sync Module' VI that wrapped the Start Module.vi and Synchronize Module Events.vi. This is for the use case where you won't be needing to register for any of the module's broadcasts.

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.

Hi,

In order to reduce the number of clicks to launch a DQMH scripter, that would be great to be able to launch them from the LabVIEW New... menu !

Indeed this window has several advantages :

1. The tree view keeps its layout from one excution to another. So if the last thing I did from that window was to launch the 'New Event...' scripter, next time I'll launch this window this item will be directly accessible
2. It allows inserting the created code into the project or not. So to create quick code without adding it to the currently open project, this is quite usefull
3. The tree view makes easier to choose the scripter to launch. With Tools menu, if the mouse pointer accidently leaves the menu and overs another menu entry, you've got to go back and re-do some of the menu selection process
4. A LV keyboard shortcut can be added to the New... action. In my case I redirected the CTRL+N shortcut to launch the 'New...' window instead of triggering the 'New VI' action. It would allow me to launch a scripter with 1 keyboard shortcut + 1 double click ! Quite fast !