DQMH Consortium Toolkits Feature Requests

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

Basically what I am looking for is something similar to this (except for DQMH)

https://forums.ni.com/t5/Actor-Framework-Documents/Actor-Framework-Sequence-Diagram-Parser/ta-p/3536...

It allows you to generate a trace with DETT and then use that as the basis for a sequence diagram.

A couple use cases:

1. You inherit a project that doesn't have any sequence diagrams. It would be nice to run this and see which modules launch which and how they communicate.

2. Troubleshooting - Things are supposed to happen in a certain order, but aren't working

3. Generating documentation - Let's say you didn't start by writing a sequence diagram, but now want to document the order things happen in.

I think this compliments the static diagrams in Anti-doc. Anti-doc clearly shows who sends broadcasts/requests to who, but doesn't show anything about timing.

@Olivier I think this would be a cool addition to Anti-Doc. It obviously couldn't generate the traces, but if you had a few, you could probably figure out how to point to them and include them. And maybe Anti-doc doesn't even run the tool on the traces. Maybe you run that seperately and then have antidoc render the resulting plant uml?

Hi,

When creating a RT Tester, the wizard asks for which modules it should do so. And it lists all modules in the project, even those which already have a RT Tester generated.

Maybe only showing the modules which do not already have a tester would help shorting the list ?

When developer use DQMH on RT, it is not possible to use the show diagram function. It could be painful when cloneable DQMH are used on RT target.

One solution to temporary  debug the system is :

• Change the main DQMH VI in Non Reentrant execution
• Change in the Reference management Vi the way we open the VI

It could be great to add two tools :

• Temporally change this two option ( with message pop up to explain that it is only for debugging)
• Add in the checklist on Validate DQMH, and add the possibility to go back

Now, when creating a round trip event, the broadcast event uses the exact same typedef as the reply payload. When using a cloneable module, this causes the broadcast event to miss the module ID and therefore any listener to this broadcast event does not know from which module it comes.

One typical use case we have which illustrates this is a cloneable module to drive a thermal chamber. The "get thermal chamber status" must be a request + wait for reply, but we also added a helper loop in the module's main to execute a periodic status check and the status update must be shared to everyone using a broadcast event so it can be displayed on a top VI's user interface for example. Actually, if we create a "round trip event" the brodcast event created misses the module ID, therefore the top VI cannot know the status of which thermal chamber was updated.

A possible solution I see is the broadcast event to have it's own typedef, composed of the module ID and the typedef of the reply payload.

What do you think about this proposal? Do you have other suggestions?

For the Validate Module\Validate DQMH Module (Headless).vi, consider formatting the Validation Results in xUnit format. 

A time delayed message in my opinion would be an useful edition to DQMH.

I understand that helper loops can be used to do timing with event structure timeouts. This becomes problematic when you need arbitrary number of timing instances at runtime. I agree resource intensive timing should be in helper loops but you may want to set up a heartbeat or check a certain signal periodically.

I did this in my application by creating a child of the messaging class and extending the class with AF style timing. But it would be nice to have this naively in the messaging library.

AF Time-Delayed Send Message VI: https://zone.ni.com/reference/en-XX/help/371361R-01/lvcomm/af_td_send/

Add an always available "None" option in the drop list, 

Selecting this option will avoid creating a case for the event in the Message Handling Loop (MHL) nor any other place

Here...

so by default this droplist will include, 
- Event Handling Loop
- None (this will avoid generating a consuming case anywhere)

or it could be 

a checkbox next to the consuming event loop droplist

to allow developer to select avoid generating it

When creating a batch of modules at the begining of a new project, it may be usefull to be able to create a new event in more than one module at a time.

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?