DQMH Consortium Toolkits Feature Requests

I dislike using Clone IDs, Whenever I have used Clones in real life application, I always start by editing the Start Module VI and adding in a Clone name input. As I do this for all my clones the input name tends to be specific like 'Bay Name', or 'PSU Name' but a generic 'Clone Name' would be good.

I then pass that Clone Name into my MHL Data cluster in 'Initialize', each clone now knows it own name this allows things like

• A Request to all Clones to get the instance for a name, so calling code can work in terms of Set Voltage(UUT_PSU), Set Voltage(RIG_PSU) rather than Set Voltage(45568) Set Voltage(40056), making a clone manager more code easier to read. -- I know this could be done in a clone manger with a Map or table, but I like the idea of the Clone know its own name.
• As the clone knows it own name, because I gave it its name, this means clone instance configuration is easier, I have can have a single configuration ini file with each clone name as separate sections or I can have each clone read from its own ini file simple based on its own name.
• Modules other than the clone manager can if needed talk to the correct clone using the name they do not need to know about the instance.

Thinking about this it would be, to my mind, a great feature addition to DQMH is by default there was a optional for providing a clone name at startup that was accessible as a Mod Admin property alongside the Module ID.

There is an option to convert Requests to Request and wait for reply but requests can not be converted to Roundtrip, so a broadcast has to be created manually with payload identical to the Request. Creating a Broadcast is not much of a deal but having two identical payloads is not ideal especially if the payload bundles multiple typedefs.

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.

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"
   

    

   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

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 extention
Stop 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)

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

As mentioned in DQMH Forum: VI Reentrance issue VIs which are required to be non-reentrant are not reported from the DQMH validation tool if they were changed (e.g. to shared clone)

Some of the important VIs which should be reported:

• Obtain Broadcast Events.vi
• Obtain Request Events.vi
• Clone Registration AE.vi
• Start Module (is already reported)
• Basically all used FGV's

Steps to reproduce:

1. Create Project with a new clonable module
2. Change all non-reentrant VIs to shared clone
   

    

3. Run module validation and execute fix
   1. Start Module.vi will be updated and changed
4. Rerun module validation
   1. No issues reported

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. 

Problem: 

Currently the DQMH stock requests / broadcasts (eg: Stop module, Hide panel etc) are mixed with the user created requests / broadcasts so if one likes to check which requests, broadcasts etc are in the module he needs to open different subfolders and visually filter out the stock events. 

This is a readability issue which makes it significantly harder to quickly understand (or recall) what events are available for the given module.

Possible solution: 

Instead of mixing the stock DQMH events with the non-stock events create a virtual folder above all the virtual folders called "Module Specific" with subfolders like Requests, Broadcasts, Private and Controls and put everything the user create to there by default.

Big advantage of this of organizing the files this way would be that one could assume that whatever is module specific can be found in the these dedicated folders instead of spreaded somewhat randomly in the virtual folder structure of the module. I said somewhat randomly because the strucure as is currently is hard to read so developers try to make it more readable, everyone on his own way (eg: creating different folders, prefixing the user created events etc). So besides the increased readability of the module by applying this feature there is a very good chance that modules' structure will become more standardized across developers working at different companies.

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!

We are constantly having deployment errors on RT targets, mentioning the Simple Error Handler. Since on RT Targets that function is useless anyway, we've put a conditional disable structure around. This solved the error.

It would be nice, if that CDS would be added to a standard DQMH module.

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

    

   
   

    

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.

For the singleton and cloneable module type, there is an option to include "Do Something" events in the new created module.

I'm not sure it's often used.

I'd like to remove it to simplify the UI.

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 ?

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

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.

Hi DQMH Enthusiasts,

What we always do by adapting the std DQMH template is adding a logging functionality into the dequeue VI of the MHL of each module (our logger of choice is a LV wrapper around Log4Net, but it doesn't matter). In my recent project, I added this logging functionality also into every request and broadcast. That means I get a XML document that contains all messages that are sent and received. Then I wrote a parser that creates a plantuml sequence diagram out of the xml, because the sent messages had the same title as the received ones.

All I had to do to get a full blown sequence diagram of my application was to run a standard operation once and let the parser do its magic.

So my feature requests would be:

- add automated logging to each notification sent and received

- Create an add-on that takes a logging file and creates a Plantuml text from it

I am happy to help/demonstrate/explain what I did and what would be ideal. I know you guys think about logging, so this might be just a small step ahead.

Cheers, Niko

Request:

Provide a mechanism to externally name the cloneable instances and retrieve the names to populate the "Select module" ring. 

Reason:

Lets say I have three power supplies. Having a ring displaying eg.: 5,6,7 has way less information than lets say "Main PS", "DUT PS", "Battery PS". Sure in the background they will be just numbers so the numeric part of the ring should remain the same. If no name is provided for a given instance then nothing should change.

This is a relatively simple change, can be done easily with a template so not sure if this should be the part of a DQMH release.

When validating a number of modules and going through the list of fixes, it's sometimes hard to keep track of what has already been fixed.

It would be nice to have some information on which failures were already fixed, and whether the fix was applied successfully or if there were errors or if there's a need for manual work.

I just put some icons into the screenshot to illustrate my idea - my feature request asks for a prettier implementation 😉

When adding a new event, I think it would be really nice if the scripting code that adds the new case structure case to the main VI also scans the event description for formatting tags, and then applies them to the new case's subdiagram label. That way the subdiagram label will be formatted exactly the same way as it appears in the VI documentation. For those of us who adhere to the convention of bold facing control names as we mention them when writing VI documentation.

I sometimes need to implement a DQMH module in isolation. So the first thing I do is create a new blank project and save it (this will be the dev project for the new module). Then I try to create a new DQMH module in the same folder as that project (by editing the 'Module Save Path' to point to the folder containing the new blank project):

When I try to click OK, I get a dialog that says I can't create the module because the specified folder contains LabVIEW files:

Yeah, I know the folder contains a LabVIEW file... it's the blank project. The Add Module dialog wants me to create a new subfolder for the new module, but I don't want that... I want the module and all its files to live in the same folder as the isolated development .lvproj. I propose that this file check be changed to remove ".lvproj" files from the list of LabVIEW file types that it checks for.

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