Find all while loops in the Main.vi of the specified module(s), and check if the DQMH Error Handler - Helper loop.vi is used to handle errors in each of the while loops, and flag it if not. Ignore the default EHL and MHL in this check.
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.
I want to be able to try to fix or poke the code more when an error occurs in the API Tester. The opportunity of going to the block diagram or attempting to send a different request goes away because the API Tester, by default, closes when an error occurs.
How I propose fixing it:
The first thing that I change on an API Tester at the first error is to remove the OR connected to the stop terminal in the loop and add an error indicator at the end instead of the Simple Error Handler and connect a local variable for the error. Would you please vote to have DQMH do this by default and have a validator to modify existing API Testers?
Current API Tester:
Fab (yes, being the DQMH Lead Architect does not guarantee that all my wishes are turned into reality 😉 )
When opening a DQMH module .lvlib file directly, the LabVIEW IDE allows to call the DQMH Scripting Tools from the Tools menu, which results in an error message when trying to parse the project for modules:
This error should be handled the same way as when calling the DQMH Scripting Tools from a single VI (or even the getting started window):
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.
As DQMH module templates become more widely used, it would be very nice if, when adding a new DQMH module that was added as a custom template, the overlay pre-populated with the overlay that the template uses.
So maybe thinking about this on a lower level, this feature request comes in two parts. When saving a DQMH module as a template, store the metadata that makes up the current overlay in a config file somewhere. Then, on the Add New DQMH Module window, whenever a custom Module Type is selected, pre-populate the overlay with that metadata.
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.
This is bordering on "outrageously nitpicky", kind of like wanting all the error wires moved behind every other kind of wire (which I also consistently do, thanks Fab lol). But I'm just gonna say it and see how much traction it gets.
The default requests Show/Stop/Hide Module.vi etc., and all other default created VIs it seems, have "error in (no error)" as their error terminal name. For the VIs created by adding new events, the terminal name is "error in". My feature request is that these be changed to "error in (no error)" as well, to be consistent not only with the other VIs in the library but with most other VIs in vi.lib in general.
Prior to DQMH 5, I would sometimes see developers add a VI reference output from Start Module.vi to the cloneable Main VI instance that was running:
This was sometimes convenient for the calling code, like in cases where you needed to insert the cloneable main VI instance into a subpanel or something like that. Unfortunately, you cannot use the same approach with Start Asynchronous Call in DQMH 5.0 and later. The VI Reference output from Start Asynchronous Call cannot be used for similar purposes. So you can't output the VI reference that was used to start the async call and expect your code to work the same. Instead, you'll likely want to create a request to the module that will use the "This VI" constant within the main VI instance itself to perform whatever operation needs to be done on the main VI instance.
I propose there be a new DQMH Validate Module test that detects cases where the VI Reference output of the Start Asynchronous Call function is wired:
I propose there be more items you can configure for a DQMH Module when creating it from scratch (ie not from a template). My current ideas are:
1. Name of the virtual folder in the target project to place the module tester
2. Name of the virtual folder in the target project to place the module library
3. Alternate path (other than "Libraries") to store the new module library on disk relative to the target project.
For example, our way of working defines that our DQMH modules are stored in a separate folder for each module under a /Modules folder. So a PowerSupply module would be stored in /Modules/PowerSupply/, both on disk and in the project as virtual folder.
My suggestion is to have:
1. A way to enter these pieces of information directly when creating a new module
2. A way to store the defaults for these values "somewhere" (either in the LabVIEW.ini or maybe some other, user-specific place)
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.
When working with helper loops in cloneable modules, it would be nice to have a way for sending messages from the MHL to the helper loop which doesn't need the module ID, and which doesn't interfere with other clones' helper loop timings. I'd still like this new mechanism to look and feel like the regular events, with all the scripting and other goodness.
Maybe instead of calling them private events, a better name would be "local" events (which would, of course, be set to private scope).
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.