DQMH Consortium Toolkits Feature Requests

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.