DQMH Consortium Toolkits Feature Requests

Hi,

The idea is to add a converter that would allow a 'plain' (standard) module to match a template.

Let's say I've got a Singleton module that contains logic a defined Public API and a template named MyVeryOwnSingleton.

I'd like the public API + MHL cases + helper loop of the Singleton module to be 'copied' into a new (?) module based on MyVeryOwnSingleton template.

A the end, I'd have a 'MyVeryOwnSingleton' module that exposes the same API as defined in the origin module + helper loop + MHL cases prepared.

If would be a nice feature if a module could be moved on disk without any further interaction. It could help a lot when one needs to restructure his project. The best would be to include it to the rename tool which - by this - would become a "Rename / move" tool.

In many cases (mostly for debugging) it would be useful who called the given request. Currently there is no built in mechanism to know that. One possible solution is to add an extra "origin" (or "originator") string control or string array to the arguments cluster and then pass the call-chain to the module as a flattened string or as a string array. This works although quite painful to implement especially if you realize that you have a problem and need to change the requesting VIs in the Public API folder. You can add this function upfront when the request is created, but its also painful, cause its probably wont be used in the vast majority of the cases, but it adds complexity to the arguments cluster.

There is some discussion about this feature here: https://forums.ni.com/t5/DQMH-Consortium-Toolkits/Who-called-my-request/td-p/4345086

At some point during one of the upgrades from an older version of DQMH to DQMH 6.1, one of the upgrade VIs errored out (sorry, I don't have what the error was).

But the end result was that the Safe to Destroy Refums.vi was not properly upgraded, resulting in an issue where if there are multiple instances of the modules running, the module may never actually close and stop.

what was missing?

the input empty?  was not present, and therefore the boolean wire was not created from the Clone Registration: Remove vi.

None of the Sempahore handling was on the block diagram of the Safe to Destroy Refum, it was a while loop from an older version of DQMH.

(I manually upgraded, so it is not exactly in the same format with comments, etc as the formal code).

FYI - DQMH 6.1 Version of the Safe to Destroy Refnum vi

Would it be possible to include a boolean input to the Start Module VI called "Launch API Tester?".  Set to False by default.

If TRUE, the Start Module would launch the API Tester upon being called. If RT target, then launch the RT API Tester VI.

Probably opens a big can of worms, but it would be pretty handy in some debugging cases!

Distribute DQMH Template Metadata alongside the template (i.e. not in [LabVIEW Data]/DQMH Module Templates). With the goal to enable template XML metadata to be distributed and versioned as code.

This would solve the problem where each developer has a slightly different template configuration and needs to go through the "Create DQMH Module Template" process when setting up a new system etc.

Example workflow:

1. Clone new project containing it's own set of custom DQMH templates
2. Add new DQMH Module
   
3. Specify path to template (template location includes all relevant metadata alongside in the same folder).
   

    

   
   

    

Idea:

Create a new DQMH component almost identical to the API Tester and call it Application Test Panel (ATP from now)

Loose definition of the ATP: a user interface visible to the end user in the final application which provides access to the DQMH functionalities in an application specific way.

Reason:

In many application an ATPs should be provided so the user can play around with different parts of the application. The DQMH module itself has the core functionality and its generic, the API tester is for testing the functionality of the module, and the ATP would be the application specific user interface.

Examples: 

1. Relay board module
   • The DQMH module is a generic relay control module. Can connect to the instrument, can open and close relays in general etc
   • the API tester is to test the module
   • the ATP would display the relay configuration the customer has in his system. The user should not be able to start or stop the module and in many cases he doesnt have to connect to the instrument as the connection built up earlier. Could have safety mechanisms like it doesnt allow to close relay K1 until relay K2 is closed etc which are not build to the DQMH module
2. Database module:
   • The DQMH module creates generic database functionalities
   • The API tester is to test the module
   • The ATP is an interface where the user can interacts with his database specifically. Could display functionalities which is a combination of the atomic requests provided by the module.

In most cases the API tester can't be used as an ATP, simply because of the reasons above: the API tester is generic the ATP is specific. Also in the vast majority of the cases we dont want to the user to be able to start or stop the module, launch a new cloneable instance etc. Another factor is the GUI design which will be most likely different for the API tester and the ATP. 

How:

The ATP is practically a second API tester. If a new request is created, an existing is renamed / removed (etc) then the change should be applied to the ATP as well. The ATP should have two extra requests by default: load to subpanel (input a subpanel reference) and an unload from subpanel, so the ATP is prepared to be shown to the user easily. 

At this point the API tester and the ATP development can be forked. The API tester works just as usual but the developer can start building a UI for the ATP.

There should be a mechanism to generate a new ATP from scratch as a given DQMH module might have a different ATP for the different applications (example: different customers have different relay layout, database structure etc).

And at the end the most obvious question:

So why not simply copy-paste the API tester? Cause the ATP should follow the changes of the DQMH module like the API tester does so the developer doesn't have to add each and every requests manually.

Sorry if this has already been discussed, I did look, but failed to find anything.

It might just be me but I find this VI very often does not give me directly what I actually want, which is to identify when a message is address to this modules only.

If think the addition of a "Address to only this instance" output would be very useful and I could make a great deal more use of this VI, it would mean I do not have to get the Module Instance from the module admin myself and check it for = to the modules ID passed in.

I recently started using this in one of my DQMH modules, it's a tiny feature and could be added to the DQMH palette.

The idea is to spawn a dynamic VI (using call and forget) that will wait a certain time (delay) and then enqueue a message in the MHL queue.

It allows to not block the MHL for other actions and make sure that a message will be enqueued with a delay.

It consists in 2 VIs, here's a simple demo :

During initializing, the window is open, center and the title is change. Those operations are very slow in RT target (4 seconds on my cRio).

It is much faster if I disable them with a Conditional Disable Structure.
Could it be like this in the template?

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

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

Hi Everyone, 

I'm wondering if anyone already wanted to port existing DQMH module to a newer version.

Basically, we implemented our own DQMH Template, that we improved it days after days. As we added some amazing and usefull feature to our internal DQMH Framework, we'd like to port some existing modules to our newest version.

I know, this would intensively use VI Scripting. But, maybe the Delacor team has a Magic Tool to do this porting 😉

By the way, If anyone has already been facing this situation and I'll appreciate to discuss about it.