DQMH Consortium Toolkits Feature Requests

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 
Overview
Get support when using Delacor toolkits.
Post an idea
Ozfarmboy

Credit goes to doyles for initially coming up with this idea.

 

Go here for previous discussions:

https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Feature-request-Automate-the-Helper-Loop-creat...

 

My ideas for this are:
  1. Include a "checkbox" onto the Add New DQMH Module dialog panel that is labelled "Include a Helper Loop"
     

    image.png

     

  2. If the user checks this checkbox, a helper loop is automatically added to the Main.vi
  3. The helper loop would not be a sub-VI, but simply a third loop on the main.vi block diagram.
  4. A Wake up Helper Loop request is automatically created and included in a Private Requests virtual folder
  5. Make the helper loop generic as per Sam's suggestion. My suggestion is to have three user events: 1) Timeout 2) <Stop Module> 3) <Wakeup Helper Loop>
  6. Label the additional "Register for Events" node something different from the other "Register for Events" node, ie. DQMH_REG_EVENTS_HELPER_LOOP (so that the Validate tool does not raise it as an issue)
  7. When generating a helper loop for new cloneable modules, ensure that in the "Wakeup Helper Loop" and "Stop Module" user events, that the Addressed to this Module.vi is used.

Ozfarmboy

In the Create New DQMH Event... dialog panel, add a checkbox and label it "Make this a Private Request".
If this box is checked, the DQMH tools would create the request as normal, but store it under a virtual folder called "Private Requests" (Access scope = private)
 
image.png

 

joerg.hampel

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

FabiolaDelaCueva

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:

FabiolaDelaCueva_0-1639365709864.png

 

Proposed change:

 

FabiolaDelaCueva_1-1639365774495.png

 

Thanks,

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

 

Konan__

Please create an additional toolbar named "Delacor" that has at least 2 buttons: one to create a new module, one to create a new event.

 

It's too tedious to go everytime via menu Tools, Delacor, DQMH, bla bla

 

Clipboard01.jpg

 

In this picture you can see on the right the JKI tester toolbar, and also the NI Unit Test Framework toolbar.

 

thanks

 

 

SAndreas

We have identified that, if multiple clonable module instances are executed and a specific module (e.g. the first launched module) is stopped (no waiting) and afterward all open modules are stopped at once (incl. wait) the "stop module.vi" an error 1 is returning.

SAndreas_1-1679304847554.png

Steps to reproduce

  1. Create a project and add a new clonable module
  2. Create a tester VI and implement the code above 
  3. Run the VI and see error 1 at second Stop Module.

 

What is happening in the Background

Situation 1 - "Stall Data Flow" = 0

  1. "Stop Module.vi" 2 runs into "Wait on Stop Sync.vi" and synchronizes stop over rendezvous.
    The acquired rendezvous size is 3 (Module 1 which is at stopping, Module 2 and Stop Module)
  2. Module 1 is waiting in "Safe to Destroy Refnums.vi"
  3. Module 2 runs into "Close Module.vi"
    SAndreas_2-1679305809604.png

     

    1. Last clone instance is fire at (1)
    2. Releasing the Semaphore (2) will wake up module 1 that it is now safe to destroy refnums now.
      Module 2 runs into "Wait on Stop Sync.vi" (3) and synchronizes over rendezvous.
    3. "Stop Module.vi" and Module 2 waiting for a third participation to join the rendezvous.
    4. Module executes case to destroy Master reference.... and executes "Wait on Stop Sync.vi" (3) with no synchronization as the boolean "Wait for Module to stop?" is on false.
    5. Module 1 executes "Destroy Sync Refnums.vi" (4) and is destroying the rendezvous.
    6. Module 2 and "Stop Module.vi" will be release from the waiting of the rendezvous as the reference is now invalid and returning error 1.

Situation 2 - "Stall Data Flow" = e.g. 2000ms

  1. In compare to the situation 1 the first module is already removed here. The obtained rendezvous has the expected size of 2.
  2. When module 2 enters rendezvous synchronization in "Wait on Stop Sync.vi" (3) the expected amount of participant is reached, and the execution can continue.
  3. In most of our tests, this situation worked fine and did not create an error.
  4. For some situation, we had the behavior that shutdown of the first module seems to be faster as the wake-up from rendezvous of the second module. The module main of module 2 opened and showed error 1. Module 1 seems to destroy the references to early. 

Situation 3 - First Module will be stopped with last "Stop Module.vi" call

SAndreas_3-1679309356975.png

The shutdown of a module is for this scenario delayed (add a wait 1000ms to exit case of the module)

  1. Stop Module 2 waits for 11 rendezvous participations. (10 module and itself)
  2. One of the previously closed module will destroy the synchronization events and makes the rendezvous reference invalid. => Error 1 at "Stop Module.vi"

 

Potential Fix

Spoiler
The following screenshots are showing an extension of the "Stop Module.vi" and the "Close Module.vi".

The idea is to use a single element queue (SEQ) containing a map of sets. The key of the map refers to a "Stop Module.vi" which waits for stopping all module at the time when the "Stop Module.vi" is executed. The Set contains all Module ID's which should be stopped. Each module checks in its close condition if the SEQ is existing. If so, the module ID will be removed from the sets which containing the module ID. An empty set refers to all required modules have stopped and a notifier which is used for synchronization will be fired.
Close Module.vi extentionClose Module.vi extention
Stop Module.vi extentionStop Module.vi extention

 

With those extensions, all three described scenarios should be fixed. In addition, should it be possible to stop all module and launch in the background new ones, the stop and wait will wait until all those modules ID run at the stop execution are finished.

 

I added the project which the extensions and tests to the post.

Addition

I'm not sure, but I think that with the described change, destroy of the Module's Semaphore (1) should be done with the boolean condition of the First & Last Instance (2). (Red line)

SAndreas_2-1679321193186.png

 

 

Please let me know if you need any additional information and details.

Darren

I would like a right-click plugin where I could right-click a DQMH broadcast subVI and "Find Event Frames". This would search all VIs in my current project for event structures that are registered for the broadcast event fired by the subVI I clicked on, and show me a list of results that I could double-click and be shown the event frames one at a time. Or I guess it could just open all the diagrams for me, since I probably want to walk through all of them anyway.

 

The operation could take a while, but would be worth it. I often find myself wondering where all the places are in my code that are registered for a particular broadcast.

 

(idea originally posted here)

CyGa

When you create a Request and Reply event, the scripter creates such code in the MHL :
 
CyGa_1-1659106158802.png
And I always end up refactoring it this way :
CyGa_2-1659106201028.png

('Status update' related code can be ignored if it is a bit too much).
Is it possible, using scripting, to directly script that so we don't have to do this each time ?

Darren

When I create a new Broadcast, here's what the new frame in the API Tester looks like:

 

1.png

 

I almost always end up adding the following code by hand (usually by copying it from another frame):

 

2.png

 

It seems to me that most of this code could be scripted. Maybe everything except the value of the first format string?

 

(idea originally posted here)

LabVIEW-Surfer

In our current practice, we encapsulate the content of DQMH MHL events within subVIs to maintain a tidy diagram and especially to facilitate the seamless propagation of changes to similar projects that use the same implementation. 

I think It would greatly benefit the DQMH framework if it could autonomously generate these subVIs as part of its MHL event scripting process.

Current situation:

LabVIEWSurfer_0-1694505543696.png

Expected situation:

LabVIEWSurfer_1-1694505568496.png

LabVIEWSurfer_2-1694505656107.png

 

 

Olivier-JOURDAN

When creating new module, I'd like a way to add a text explaining its responsibility. It will reinforce good conception practices and allow Antidoc to retrieve information to generate a valuable documentation.

 

Note: IMO, this content should be added to the module lvlib description.

 

If this field could optionally mandatory to create the module, I would find this great 🙂

Olivier-JOURDAN

IMHO, it would make more sense to have the Stop Module request at the same level than Start and Sync functions.

 

OlivierJOURDAN_0-1664382201793.png

 

LabVIEW-Surfer

As users of SVN for source code control, we rely on SVN-Locks to maintain a conflict-free development environment when collaborating with multiple project team members.

 

When working on DQMH Projects as a team, it would greatly enhance our workflow if we could selectively apply SVN locks to specific subsets of the project.

 

Currently, the DQMH scripting necessitates write access to the entire project, limiting flexibility in group collaborations. 

LabVIEWSurfer_0-1694506083568.png

 

Is it feasible to consider modifying this behavior to provide increased flexibility and efficiency for group work?

CyGa

Today when an event is removed, no special actions are done in the testers and a 'manual search' has to be done in the module's main VI.

Here is what is suggested in DQMH help :

 

  • In the case of a Request:
    • In the Tester VI:
      • Open the block diagram and find the event frame configured to test calling this request.
      • ...
    • In the DQMH Module Main.vi:
      • Open the block diagram and find the event frame configured for this request (It might no longer be listed and instead say something like “Unknown Event (0x0)”).
      • ...
  • In the case of a Broadcast:
    • In the Tester VI:
      • Open the block diagram and find the event frame configured for this broadcast. (It might no longer be listed and instead say something like “Unknown Event (0x0)”.)
      • ...
    • In the Module Main VI:
      • Open the block diagram and find the places where the broadcast VI is called and remove it.
      • ...

 

It would be nice to attract dev eyes on the places where modifications need to be done post event-removing.

Maybe adding a comment like this would be enough ?

CyGa_0-1671029428837.png

It is not much, but the comment color and hashtag would ease the 'finding' process.

Ozfarmboy

Please add a test to the Validate Module tool:

 

Find all while loops in the Main.vi of the specified module(s), and check if the DQMH Error Handler - Helper loop.vi is used to handle errors in each of the while loops, and flag it if not.  Ignore the default EHL and MHL in this check.

Olivier-JOURDAN

When you update the DQMH version, you can have hundreds of failures to fix in your projects (not because everything is broken but just because, for example, a new feature requires updating a VI).

 

A fixer is available most of the time, and you just have to click the button to make the code change.

 

For me, the UX issue is that after you hit the fix button, you need to select the next failure with your mouse and then click on the fix button. I'm not too fond of this kind of mouse gymnastics.

 

My proposition: If the fix is successful, the next failure could be selected automatically.

 

The fixing process would be significantly improved.

Desruelle_luc

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

Update module.png

Darren

When I need one of the reply payload values of a Request and Wait for Reply VI, I need to unbundle 100% of the time. What if the Request and Wait for Reply VI output the reply payload elements individually on the VI conpane so I don't need to unbundle? I often make this change manually to my Request and Wait for Reply VIs. And I never unbundle the error from the payload, since it's already merged into the error stream inside the VI. So I wouldn't expect that output to be on the conpane. But all the other payload parameters, you betcha!

 

(idea originally posted here)

CyGa

When creating a new event for a module and my project contains numerous modules, finding the correct module in the list can be somehow painfull.

Listing the DQMH modules in alphabetic order would help finding the correct module faster.

CyGa_0-1686929334157.png

 

Ozfarmboy

By default, in the MHL Error case, the "error out" local variable is written to.  But the error that is written is NOT the error that came into the MHL Error case!

 

Ozfarmboy_0-1649207744606.png

 

I propose the above be changed to this:

 

Ozfarmboy_1-1649207803027.png

By doing this, the actual error that was raised by the module will be copied to "error out"