DQMH Consortium Toolkits Feature Requests

If you want to pass a parameter to your module when it starts, you can add that parameter as an input to Start Module VI:

The way you define the type of the Call By Reference node (to accept the new parameter) is usually by dragging the Main VI into the VI Reference constant wired to Open VI Reference. However, sometimes a different VI may be used to define the type, especially if there are multiple DQMH Modules in your project that take the same inputs on initialization. Also, the opposite situation can occur where you add an input to the Main VI connector pane, but forget to add that input to the Start Module VI.

If the connector pane of the Main VI doesn't match the VI Reference constant in the Start Module VI, you will receive an error when attempting to start the module. I propose that we add a Validate Module test that detects this situation (connector panes of Main VI and VI Reference constant don't match) and returns a validation failure.

When creating a Request and Reply event, the scripter creates the corresponding calling code.
In this code the request VI is added on the diagram with all inputs empty (except for the error IOs).

Most of the time I select the VI and perform a 'CTRL+space + CTRL+D' to create all input/output controls and indicators.

And, therefore, it creates a boolean control for the 'Wait for Reply ?' input.

99.9% percent of the time I replace that control with a constant value, since I know if I need to wait for a reply or not for that specific request. And there is (close to) no chance that I'll need to set that using a control on my tester GUI.

Maybe placing the request VI and adding a constant linked to the 'Wait for reply ?' input on the tester diagram would help reducing the number of redundant actions one achieves when coding the tester ?

Connecting the constant would avoid having to change a control created by the 'CTRL+space + CTRL+D' shortcut into a constant each time.

Hi,

Including DQMH modules into our application framework, we need to script the creation of new modules / requests and so on.

However, current scripting GUIs do not have any controls connected to the connector pane.

Also, even if we could pass some values to these interfaces, we would even need to control if we want to show their HMI or control the creation / cancellation of a scripting action whitout having to press on the OK / Cancel button.

Allowing to programmatically control the DQMH scripting VIs would be great !!

It's not completely related to the framework itself, but I'd like to have a tool to generate an "error VI" (like Module Not Running--error.vi) with custom error code not already use in the project or selected among the existing ones.

If we could also have an API that list error codes and text, I would like it 🙂

Wouldn't it be great if we could hook into the scripting process of DQHM and, for example, add our own automation steps to the creation of new modules or new events? Something like the "post-build VI" feature of the application builder...

This has been discussed before in the now deprecated "Feature Requests" thread

It would nice to catch circular dependencies in the DQMH Validator Tool. Catching all circular dependencies would be hard ie A->B->C->D->A, but the simple case would be easy to catch A->B->A. This would be the case where A registers for the broadcasts of B but also sends requests to B.

If anyone has an easy way to catch the more complicated case, I'd be all for that too.

If feasible, I would recommend a tool to navigate an application. This request may be considered an extension to, and as the inverse of, the function "Find DQMH Event Frames" 

Include a navigation window with structure of Modules -> Broadcast Subscribers and Request Makers. 

The JKI State Machine Explorer is a great example of the developer experience I'm hoping for. 

Another approach may be the ability to right click on an event case and select "Find Broadcaster and/or Requestor" and show corresponding MLH case. 

Where do I send my $100 attached to this request? 😉 

Thanks - Jared

Here's something I've been running into lately (for whatever reason hadn't done a ton with cloneable until now). I'm sure someone else must be as annoyed by this as I am.

Why do all the cloneable broadcast event VIs take a module ID and not a module admin object? Is there ever a reason where I would want to use a different module ID rather than the current one? I can't think of any, but maybe I am just not that imaginative.

Everywhere I drop a broadcast I have to also drop a property node and pull off the Module ID, why not just incorporate that into the broadcast VI?

By the framework not including that it requires extra effort on my part to wire it all up and it clutters my block diagram with property nodes that don't really add anything.

I'm sure there is probably some reason it was done this way. What use case am I missing where I would want to use a different module ID? and if there is a use case for that, I'm assuming it is an infrequent or minority use case. Is there some way we could make the primary use case the default (ie use the current module ID) without requiring all these extra property nodes, while still maintaining the ability to use a different module ID if needed?

Not sure if there is a way to do this and also make it backwards compatible? Maybe leave the existing broadcast vis as is and mark them as deprecated or something and add a wrapper that takes the module admin and then calls the 'deprecated' VI.

All I know is that there has to be a better way than dropping a property node every time or me manually creating a wrapper for every broadcast.

How does anyone else currently solve this problem?

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.

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.

I was writing a module that interfaces with hardware and created an "initialize" request event to call the driver's init. Had I been thinking I would have realized there is already an "initialize" case native to DQMH, but the tool went ahead and scripted it out. The only indication of a problem was a broken run arrow due to duplicated case names.

Hello,

I'm working now on communication between two DQMH apps. Sending events between then is easy thanks to HSE Generic Networking for DQMH Module. However, each request that I want to transfer requires a wrapper (documentation) and the steps to create it are the same. It would be nice if I can automate this process by customing Create New DQMH Event function. So I have tried to find any information about how to add a type of event but without success. Is it possible? Another solution will be to have an option to add Post Event Creation action (vi), which gives a possibility to run self-created scripting code. 

I sometimes create Cloneable modules that I intend on usually calling as singletons. For these modules, I often manually update each request to have its Module ID input recommended (instead of required) and the Module ID default value of 0 (instead of -1). I also make the 'call as singleton' input on Start Module.vi have a default value of TRUE (instead of FALSE).

I'd like for there to be an option when creating a new cloneable module that says something like "optimize for calling as singleton" that would create the default requests as described above, and would also be tagged in some way so when I add new requests they will be created as described above.

(idea originally posted here)

When you add a new Request and wait for reply event, the scripting tool adds automatically, in the Modules consumer, the handler case. In this case, there is also added the bundle for the Reply message and the Wait for reply? case structure. 

Personally, i move every time the bundle inside the Wait for reply? case structure to have a cleaner area.

The scripting tool can add this automatically for a cleaner view and maybe an optimized code. There is no need to create a bundle, if you do not use it forward.

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

The DQMH library has several errors defined in privately scoped VIs like "Module Not Running--error.vi".

It feels like the error codes associated with these error constants form part of the public API but there is no way that the library caller can know what these codes are without the omnipotent powers of the developer looking into the code (or deliberately triggering the error in an API call).

What would be people's thoughts on providing some public VIs which wrap up the private error constant VIs and just output the code for use with the things like the "Clear Errors.vi" or other error handling logic?

I know these could be added to a custom template but if the point of the DQMH is to encourage good practice then avoiding magic numbers in the caller's error handling logic is a win right!

Cheers

John
 

When using the Request and Wait for Reply pattern, the time-out happens locally (with a usually hard-coded default-value).

The module receiving the message has no idea of the time-out on the client side (timeout meaning: When did I send the message to the module?, When do I not care about an answer anymore?).

I suggest incorporating such info (i.e. "Timeout End Timestamp") into the request message automatically, so that the module can do sanity checks before processing the request (i.e. "Time-out occured already, so I'm not executing the request at all, since the caller doesn't care anymore").

Furthermore, I think it is helpful, if you can choose during creation of a "Request and Wait for Reply" event with the wizard, if the time-out should be exposed or the default constant should be used, bringing this decision to the attention of the developer.

Thanks !

Cheers

Niels

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?

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