DQMH Consortium Toolkits Feature Requests

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

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)

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.

A round-trip can be summarized as a Request and Reply event + broadcast of the reply.

Round-trips are particularly useful when debugging systems where the access to the module itself is hard to get (like when using TestStand / VeriStand platforms). They are very good sniffers to understand what's going on under the hood.

I would find it very valuable if the broadcast could also carry the request arguments !

This way the 'sniffer' could expose the context of the reply : reply is formed that way when the request contains such arguments.

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

Handle Exit.vi executes Hide VI Panel.vi.

If the module's front panel is inserted into another front panel via a subpanel, the main panel will be hidden, which could cause the entire application to disappear.

The solution is to use the Remove VI method before the Stop Module API method.

An example illustrating the use of subpanels with DQMH would be interesting.

It would be nice to have an example provided with the framework to demonstrate the implementation of a plugins architecture with DQMH :

Main Application (sources) <---> Plugin Interface (PPL) <---> Plugin (sources or PPL)

When refactoring "Request" events into "Request and wait for Reply" events the scripting tools always create a new MHL case. If just wanted to modify the existing event I need to copy reply code, delete the new MHL case and add the reply code to the old MHL case.. 

It would be much better if the new MHL frame would be a checkbox option and the normal behavior is that the reply code just gets added to the original MHL case 

In the helper loop this already works and the reply gets directly wired.