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
Darren

All DQMH modules come with a Module Timeout--constant.vi:

 

timeout1.png

 

This value defaults to 5 seconds, but I've worked with many modules over the years (usually having to do with serial devices) where this value is modified. I find it tedious to have to dig into the timeout VI any time I want to find out what the timeout actually is. Especially when I'm working with multiple modules at the same time that may have different (legitimate) timeout values. So I propose the following:

 

1) The default modules that ship with DQMH should include the timeout value in their icons:
timeout2.png

 

2) There should be a Validate test that ensures the Timeout VI icon displays the correct value, and provide a fixer that will update the icon if it does not.

Ozfarmboy

When you create a new cloneable module from the default Cloneable, it creates the new module which includes the following automatically created libraries:

 1) VI Reference Management

 2) Clone Registration

 

However these libraries do not have a description.  Could we please add a description to these for the next DQMH release?

 

Ozfarmboy_0-1707195691476.png

 

Main reason for this request: We have an inhouse tool that finds all libraries/classes/VIs/ctls that do not have a description and then allows the user to edit these in one place. These two libraries keep showing up in the list for each DQMH module.

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

 

 

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?

Ozfarmboy

It would be awesome if the DQMH validation tool could go back more than one version.

 

eg.  If you open an old piece of code (that was written in say DQMH 4.2), the only way to upgrade it to 6.1 is to one version at a time, upgrade the code step by step.  This would mean the following:

 - Install DQMH 5.

 - Run Validation tool

 - Install DQMH 6

 - Run Validation tool

 - Install DQMH 6.1

 - Run Validation tool

 

This is a rather painful process, and when faced with this, I have decided to simply implement the module again starting from the latest version, and porting the code over rather than go through that.

 

Neither approach is obviously ideal.

 

We really need a tool that can convert an older module up to the latest standard.  This will become a more common problem now that we have DQMH-based code out there from 2018 onwards.  The more people use it, the more this problem will surface.

 

 

 

JoGra

Hi,

 

This might be a special use case, but maybe there are more applications for a cluster of event registration refnums for helper loops.

 

My use case involves DAQmx or IMAQdx events. These events get registered through a DAQmx or IMAQdx reference, like this:

JoGra_2-1704363872542.png

 

The register for events for the helper loop is happening before the loop and the task is started, which means that registering to the "Done" event of the task doesn't work if done like this:

JoGra_4-1704364222059.png

Because there is no valid task reference yet, so the event registration gives an error.

What works instead is the bundling of the "Module Request Events"-event registration refnum with a static event registration refnum of the task "Done" event. 

JoGra_5-1704364472523.png


Inside the helper loop, at a point where the task has been created, the event registration for "Done" event can be updated.

JoGra_6-1704364631172.png

 

This works very well and simplified my code, which before had another async VI which registered to the daqmx event and sent a broadcast to the helper loop. This is much nicer. 

 

The drawback is that the DQMH event scripting tool does not support the extra namespace ("Module Events") of the clustered event registration refnums. This results in that every time the Module Request Events get updated the assignment of events to in helper loops event handler gets broken and they need to assigned again manually.

JoGra_7-1704365226221.png


This happens when any kind of request is created. If the request is created for the helper loop this error appears:

JoGra_8-1704365328661.png

 

This is how my helper looks like after assigning the events again:
(using just a bundle instead of bundle by name for space reasons)

JoGra_9-1704365643845.png

 

 

Proposal:

 

Addition of check to request (and broadcast) creation, that when a helper loop exists and  the event registration refnum for the request events (and probably also the broadcast events) is bundled in a cluster with some other event registration refnum, the extra namespace (eg "Module Events") gets handled and the events can be created and assigned.

 

 

 

Darren

I have 'barebones' singleton and cloneable module templates that I always use when creating new DQMH modules for projects. I started with the shipping module templates and removed:

- 'Do Something' events

- All #Bookmarks

- Simulate EHL/MHL error buttons

 

I propose DQMH ship with these simple module templates. They help save several minutes when creating a new module. I'm not suggesting changing the project template, but rather simply adding two new options in the Add New DQMH Module drop-down:

 

addmod.png

I'm open to suggestions for different names. 🙂

CyGa

Hi,

 

Most of the time we create multi-layer applications, and bottom modules need to share information that might have to cross several upper layers.

To avoid coupling and jumps between any non-adjacent layers, we have to create similar broadcast in the parent modules to repeat child broadcast one layer upper.

 

It would be interesting to have a utility that 'copies' an existing broadcast from one module into another.

 

And maybe have an option to code the forwarding :

  1. automatically register for child broadcast in the parent if not done already
  2. in the selected braodcast EHL case, map broadcast arguments onto parent broadcast VI inputs

 

I guess the same thing can be done when the communication needs to go down the layers, and therfore applied to requests.

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.

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

 

joerg.hampel

Wouldn't it be great if double-clicking on certain failures in the Validator results window took us directly to the related place on the BD or the corresponding VI in the project window?

 

I'm thinking about the ones where you need to manually do something. Like disconnecting the Main VI terminals from its connector when moving from Run VI method to Start Async method, or updating your static VI ref by dragging the main VI onto the constant...

1984

In many cases I launch the cloneable instance(s) and launch the API tester on demand. In this case the API tester doesnt show if any instances are already running, I need to press the refresh button which I forgot in most of the cases. Other developer not that familiar with DQMH forgot it all the time causing confusion.

 

I have fixed this in the template module we use for cloneables:

 

1984_0-1692337113322.png

Enrique.Noe

Everytime I create a new request to a DQMH cloneable module I always end up connecting the Module ID terminal to the new request added to API Tester, please add an additional scripting step to connect this terminal automatically

Screenshot 2023-10-18 at 11.27.25 a.m..png

 

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.

joerg.hampel

This is more of a question or request for comments than an actual feature request:

 

In the dialogue window for creating a new DQMH module, should we rename the caption "Module Type" to "Module Template"? For a vanilla installation of DQMH, there are only two templates to choose from (Singleton and Cloneable), so the caption makes sense. Once you start adding your own templates, not so much anymore. Also, for documentation purposes, it would make things clearer if we separated the term "type" from the term "template".

 

In addition, it would be nice to see the actual type of the module (singleton or cloneable) added to the name in the dropdown list (see screenshot).

 

Opinions?

 

Bildschirmfoto 2023-10-05 um 11.14.33.png

Petru_Tarabuta

Currently on the block diagram of VIs that implement Request events, the Bundle By Name node and associated typedef cluster constant are located outside of the case structure, even though their output is used only by the False case of the case structure (and not by the True case). The screenshot below shows the unmodified "Do Somthing.vi" VI.

Petru_Tarabuta_0-1701638967912.png

 

The code would be slightly cleaner if the BBN and typedef constant were moved inside the False case of the event structure. This follows the clean code rule that if an action is relevant only to one case of a case structure, then it should be located inside that case. The code would then look like below.

Petru_Tarabuta_1-1701639034664.png

 

Thanks!

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 ?

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

 

SAndreas

Let developer create own DQMH validation test which allows them to test company specific style and scripting.

 

At that point, it would although be great to store a test configuration. E.g. which tests should be executed and which severity a failing test hast. 

CyGa

Today most of our screens support a 1920x1080 resolution.

And the actual space that I can basically use in the MHL is 530x315 pixels (roughly, surface of the MHL minus subdiagram comment).

Which means that my useful coding surface is only 30% of my screen resolution.


I guess the EHL and MHL can be designed wider so that we have more space for our custom code.