DQMH Consortium Toolkits Feature Requests

Note: I couldn't find any idea/discussion about it and it's surprising. If I missed something, please point it out to me and accept my apology.

The idea would be to access the most used scripting tool via Quick Drop.

My wish list:

• Create New DQMH Event...
• Add New DQMH Module...

When NI released VI Analyzer 2018, they included a feature to ignore VI Analyzer test failures for specific objects and VIs through the use of #via_ignore bookmarks:

I would like similar functionality for ignoring DQMH Validate Module failures. I propose that if a VI contains a #dqmh_validate_ignore bookmark anywhere on its diagram, then that VI will not return a failure for any DQMH Validate Module test whose name is included in that bookmark's label. Something like this:

I'm triggering module validation with CI. On a large project (40+ modules), the validation takes 20+ minutes to execute.

I'm wondering if there are ways to reduce this execution time.

Original idea from Matthias Baudot in https://anchor.fm/wired-in-software/episodes/Episode-6---Matthias-Baudot-from-Studio-Bods-emtpti

When you have lots of modules (20+), initializing module selector control tends to take seconds that can be annoying when you need to use the scripting tools.

Finding a way to remove this init time would greatly improve the user experience in large application development.

Hi,

Some of my events have a common events arguments and/or reply payload.
Creating a template would speed up their creation.

Also, when using round trips from TestStand, I made a modification to the content of a round trip event to easily handle termination.
It could be nice if this modification could be saved as a template, so that every round trips I create to be used within a TS sequence would contain automatically that modification.

Hi,

When creating Request And Reply / Round Trip events, the timeout to get the answer is set as a constant which is global to the module.

It would be nice to personalize this timeout to choose between :

• Module timeout
• Personnalized timeout with a control to enter a value in millisecond

If Module timeout is selected, then module timeout -- constant.vi would be wired to the 'wait for notification' timeout input.
If Personnalized is selected the value set by the user would replace the module timeout -- constant.vi (using a constant instead, or better calling a newly create 'request name' timeout -- constant.vi)

Hi Everyone, 

I'm wondering if anyone already wanted to port existing DQMH module to a newer version.

Basically, we implemented our own DQMH Template, that we improved it days after days. As we added some amazing and usefull feature to our internal DQMH Framework, we'd like to port some existing modules to our newest version.

I know, this would intensively use VI Scripting. But, maybe the Delacor team has a Magic Tool to do this porting 😉

By the way, If anyone has already been facing this situation and I'll appreciate to discuss about it.

Sometimes, I need to create two or more very similar request and wait for reply events - one to perform some kind of action (e.g. set the value of vertical range on a scope card) and one to query that value. In both cases I want to return the value that was actually set. At the moment, I end up with two identical reply payload typedefs as its not trivial to reuse them between events.

When creating a broadcast event you can already select to use the payload of a previously created request and wait for reply, I'd like to see that option available in request and wait for reply events too...

Thanks

Paul

At the moment, when we create a request and wait for reply event, the reply payload (correctly) includes an error cluster to report any error that occurred during the handling of the request. However, the error cluster label includes the request name, even though it is within a typedef'd cluster which already uses the request name.

Not only is this a pain as it can take up a lot of block diagram space - I thought duplicating names of structures with a structure was not great style - if its in the "Do something request and wait for reply (Reply payload)" cluster, it probably doesnt need to be called the "Do something request and wait for reply_error"

Could it be changed to just be called "Error"?!

Just a thought...

Paul

Hi,

Today when I finish creating an event / module, If I want to create a new one I've got to click again on Tools => Delacor => DQMH => Create...

Sometimes, after planning my architecture I'll need to create several modules/events in a row to start building my app.

Going through the menus each time is a pain in such case.

Maybe replacing the OK button by a Create button and a Create and Continue button would help to this (like you can have using Redmine for example).

The Create button would act like the OK button today.

The Create and Continue button would generate the new event / module but without closing the window.

It would simply reset the fields to their defaut values (and reopen a new virgin payload/paramater window in case of creating an event).

This way creating several items in a row would be really faster and easier.

(more details in the ppt attached)

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

Please create an additional toolbar named "Delacor" that has at least 2 buttons: one to create a new module, one to create a new event.

It's too tedious to go everytime via menu Tools, Delacor, DQMH, bla bla

In this picture you can see on the right the JKI tester toolbar, and also the NI Unit Test Framework toolbar.

thanks

It can be hard to follow the flow of messages between DQMH module in a large project.

I find sequence diagrams great to document that, one tool that would rock is something that looks like a UML Sequence Diagram that is updated as messages are being sent. Columns generated the first time a module is started and then the lifelines of the modules are generated and terminated in their column.

Such a tool was created for the AF, so surely the same could be done for the DQMH.

When developing a DQMH Module Template, the meta data XML file that goes along with the module template library defines various aspects of the module. Currently, the only user-configurable parts of the XML file are the module description, and where you want to store the template on disk.

I propose there be more items you can configure for a DQMH Module Template when creating it. My current ideas are:

1. Name of the virtual folder in the target project to place the module tester

2. Name of the virtual folder in the target project to place the module library

3. Alternate path (other than "Libraries") to store the new module library on disk relative to the target project.

For example, I have a DQMH module template for creating a test for my test framework. I want its tester to go in a 'Test Testers' virtual folder in my project, I want its library to go in a 'Test Libraries' virtual folder in my project, and I want the module to be saved in a 'Tests' folder that sits next to my project. It would be nice if all of these things could be not only specified in the UI of the Add New DQMH Module dialog, but default values for each of them could be defined in the module template meta data XML as well.

I propose to let the script/scaffolding engine to make a folder with erros, I think it's cleaner

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

For the Validate DQMH Module (Headless).vi, expose an event that allows for updating the status of the validation while it's running.

Similar to the AB API:

This would allow to update the UI or CI console during execution.

I'd like to have a way to duplicate a module easily through DQMH module menu.

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!