DQMH Consortium Toolkits Feature Requests

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.

All,

The suggestion/request is mainly caputured in Implementation (1) at "https://delacor.com/dqmh-generic-networking-module/"

The proposal is to generalize the 'reply' communication by using a 'variant notifier' instead of a 'typedef notifier'.

I agree with the statement mentioned on the delacor website.

"This allows us to send and receive messages without knowing about their actual contents, and that’s the prerequisite for separating the module’s actual use code from the networking code."

The proposal is to change the DQMH scripting to always use the variant notifier. (instead of manually changing)

Actually I have changed the scripting to be able to have this automatically, which I use already 2 years. (If interest I can share with the consortium)

Personnally I don't see any disadvantages of using a variant instead of typedef in this case.

Also for writing the reply payload, this is not a problem as the typedef is also scripted automatically. (see screenshot) 

Any comments on potential disadvantages?

Regards,

Lucas

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):

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.

The problem I want to fix:

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:

Proposed change:

Thanks,

Fab (yes, being the DQMH Lead Architect does not guarantee that all my wishes are turned into reality 😉 )

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)

 

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.

Basically what I am looking for is something similar to this (except for DQMH)

https://forums.ni.com/t5/Actor-Framework-Documents/Actor-Framework-Sequence-Diagram-Parser/ta-p/3536...

It allows you to generate a trace with DETT and then use that as the basis for a sequence diagram.

A couple use cases:

1. You inherit a project that doesn't have any sequence diagrams. It would be nice to run this and see which modules launch which and how they communicate.

2. Troubleshooting - Things are supposed to happen in a certain order, but aren't working

3. Generating documentation - Let's say you didn't start by writing a sequence diagram, but now want to document the order things happen in.

I think this compliments the static diagrams in Anti-doc. Anti-doc clearly shows who sends broadcasts/requests to who, but doesn't show anything about timing.

@Olivier I think this would be a cool addition to Anti-Doc. It obviously couldn't generate the traces, but if you had a few, you could probably figure out how to point to them and include them. And maybe Anti-doc doesn't even run the tool on the traces. Maybe you run that seperately and then have antidoc render the resulting plant uml?

Greetings from France

be able to upgrade the module type, for example singleton type to cloneable type, would be a great feature.

menu -> DQMH -> Module -> updgrade

A+

Luc

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.

Original idea from @FabiolaDelaCueva 

Sometimes you could need to unregister broadcast events. To do this you want to use the Broadcast Events--cluster.ctl, but it's set to private scope (it's totally fine).

Having a public wrapper to this control just giving access to the type and not the current event like you can get with Obtain Broadcast Events For Registration function would be great.

Considering providing a fixer to add this wrapper to all other existing modules.

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

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,

When creating a RT Tester, the wizard asks for which modules it should do so. And it lists all modules in the project, even those which already have a RT Tester generated.

Maybe only showing the modules which do not already have a tester would help shorting the list ?

So - we have a few modules now where we essentially strip out the message handling loop as the modules are essentially "UI" modules.

DQMH 5 broke them (well, broke the ability to use the scripting tools with them), DQMH 6 allows them to work but could it do one more thing for me?

I have a cloneable DQMH event only module - it creates the event case, but it DOESNT put the "addressed to this Module.vi" into the newly created case as it would with a regular DQMH...

Any chance you can rejig the scripting order to get that back in?

Thanks! 

When developer use DQMH on RT, it is not possible to use the show diagram function. It could be painful when cloneable DQMH are used on RT target.

One solution to temporary  debug the system is :

• Change the main DQMH VI in Non Reentrant execution
• Change in the Reference management Vi the way we open the VI

It could be great to add two tools :

• Temporally change this two option ( with message pop up to explain that it is only for debugging)
• Add in the checklist on Validate DQMH, and add the possibility to go back

I was writing a module that interfaces with hardware and created an "initialize" request event to call the driver's init. Had I been thinking I would have realized there is already an "initialize" case native to DQMH, but the tool went ahead and scripted it out. The only indication of a problem was a broken run arrow due to duplicated case names.

When a request times out, the present code returns the value returned by the Wait on Notification VI, which contains the reply payload cluster with all the contents replaced with the respective data type defaults. For example, if the is a DBL control in the cluster, this is set to zero. This is the code I'm talking about:

My suggestion is instead to output the default values of the cluster as they have been defined in the TypeDef, like this:

where in the False case of the inner case structure the reply payload wire just passes through.

I find this useful when for example I want a VI that reads a sensor to output NaN if there is any kind of error, including a request timeout.

Let me know if this makes sense, or if you approach this use case in a different way.

Thank you!