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

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!

Sometimes you can lose communication with clones and can't send any "Stop" request.

In this case, those clones stay in memory in a running state, and it is very hard to kill them. Stop or Kill launcher have no effect. The only way I have found is to close the project but it's not very usefull.

It will be good to have a watchdog mechanism to kill lonely clones

As discussed here  JKI SMO and drjdpowell messenger library, have this kind of mechanism.

drjdpowell

Now, when creating a round trip event, the broadcast event uses the exact same typedef as the reply payload. When using a cloneable module, this causes the broadcast event to miss the module ID and therefore any listener to this broadcast event does not know from which module it comes.

One typical use case we have which illustrates this is a cloneable module to drive a thermal chamber. The "get thermal chamber status" must be a request + wait for reply, but we also added a helper loop in the module's main to execute a periodic status check and the status update must be shared to everyone using a broadcast event so it can be displayed on a top VI's user interface for example. Actually, if we create a "round trip event" the brodcast event created misses the module ID, therefore the top VI cannot know the status of which thermal chamber was updated.

A possible solution I see is the broadcast event to have it's own typedef, composed of the module ID and the typedef of the reply payload.

What do you think about this proposal? Do you have other suggestions?

The DQMH library has several errors defined in privately scoped VIs like "Module Not Running--error.vi".

It feels like the error codes associated with these error constants form part of the public API but there is no way that the library caller can know what these codes are without the omnipotent powers of the developer looking into the code (or deliberately triggering the error in an API call).

What would be people's thoughts on providing some public VIs which wrap up the private error constant VIs and just output the code for use with the things like the "Clear Errors.vi" or other error handling logic?

I know these could be added to a custom template but if the point of the DQMH is to encourage good practice then avoiding magic numbers in the caller's error handling logic is a win right!

Cheers

John
 

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 working with clonable modules it is possible (although not desired) to address a Module ID instance that doesn't exist (e.g. has already been closed, never existed in the first place). All clones would ignore said request and in the best case you'd see a timeout error. This may bring about unexpected bugs, especially when working with Requests (without reply).

I think the request should check if Module ID exists and throw an error if it doesn't. This could work by modifying the Request and Request with Reply template to the following:

I propose to add such functionality to the DQMH Clonable Template and check for this in module validation.

Today I want to validate one case of use in your QMH toolkit. My case is to simply add some messages queue with priority in front of the queue. But during my test, I encountered a strange result, the step isn't in the expected order. After looking in Delacor_lib_QMH_enqueue Message(poly).Vi, I show that vi run as coded, but not as (for me) expected and logical. I think that when you want to add some steps with the priority you want to add all steps in the same order as in the Message array, but with your vi it's not the case. For example, if you want to add 4 Messages (1,2,3,4) with priority, you won't obtain 1,2,3,4, but with your vi you obtain 1,4,3,2.

I send you a test vi to see that.

I have a workaround and propose some modifications for that vi.

1) I don't understand why you want to create an array for priority (boolean array priority message). I don't show why mix priority and not priority are use cases. And the result order is completely unpredictable. I propose to modify the array by just one boolean, and in this case, all message array became a priority (front) or not (back).

2) In case of the queue is empty, the priority has (for me) no sense, and i put all added Message array with no priority to respect order.

3) In case of the queue isn't empty, I invert all added Message array (and Message Datas array too) to respect order.

I send you one version of modified VI to see how. You must add it to your Delacor QMH library to run it.

Eric

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.

This feature request is adding to the already existing "Private Request" and "Helper Loop Creation" requests (or not?):

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