DQMH Consortium Toolkits Feature Requests

Instead of selecting each item to be updated then click update. It would be nice to have an update all or be able to select multiple items to be updated.. Especially when going to a newer version (like 4.x to 5.0)

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
 

Just a very, very simple proposal for consistency, as per what the title says: when a "Panel close?" event is triggered in "External Launch" mode, the module should probably broadcast a "Panel hidden." Status updated. Like this:

Do you agree or is there any reason I'm missing for which the broadcast was not placed there?

Thanks!

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?

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/

Handle Exit.vi executes Hide VI Panel.vi.

If the module's front panel is inserted into another front panel via a subpanel, the main panel will be hidden, which could cause the entire application to disappear.

The solution is to use the Remove VI method before the Stop Module API method.

An example illustrating the use of subpanels with DQMH would be interesting.

It would be nice to have an example provided with the framework to demonstrate the implementation of a plugins architecture with DQMH :

Main Application (sources) <---> Plugin Interface (PPL) <---> Plugin (sources or PPL)

When refactoring "Request" events into "Request and wait for Reply" events the scripting tools always create a new MHL case. If just wanted to modify the existing event I need to copy reply code, delete the new MHL case and add the reply code to the old MHL case.. 

It would be much better if the new MHL frame would be a checkbox option and the normal behavior is that the reply code just gets added to the original MHL case 

In the helper loop this already works and the reply gets directly wired.

My use case is simple :

I have a module that uses DAQmx functions, so the module's main VI will only be executable in DAQmx is installed.

Having a public VI from the module to check if the main.vi is executable is, I think, the fastest way for my app to report that a feature is not available due to missing driver.

Please create and add checksums for the Core and each of the individual packages.  This is necessary for companies to be able to trust the integrity of software being downloaded.

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.