DQMH Consortium Toolkits Feature Requests

Community Browser
Labels
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Overview
Get support when using Delacor toolkits.
Post an idea
joerg.hampel

Wouldn't it be great if double-clicking on certain failures in the Validator results window took us directly to the related place on the BD or the corresponding VI in the project window?

 

I'm thinking about the ones where you need to manually do something. Like disconnecting the Main VI terminals from its connector when moving from Run VI method to Start Async method, or updating your static VI ref by dragging the main VI onto the constant...

Darren

I have 'barebones' singleton and cloneable module templates that I always use when creating new DQMH modules for projects. I started with the shipping module templates and removed:

- 'Do Something' events

- All #Bookmarks

- Simulate EHL/MHL error buttons

 

I propose DQMH ship with these simple module templates. They help save several minutes when creating a new module. I'm not suggesting changing the project template, but rather simply adding two new options in the Add New DQMH Module drop-down:

 

addmod.png

I'm open to suggestions for different names. 🙂

CyGa

Hi,

 

Most of the time we create multi-layer applications, and bottom modules need to share information that might have to cross several upper layers.

To avoid coupling and jumps between any non-adjacent layers, we have to create similar broadcast in the parent modules to repeat child broadcast one layer upper.

 

It would be interesting to have a utility that 'copies' an existing broadcast from one module into another.

 

And maybe have an option to code the forwarding :

  1. automatically register for child broadcast in the parent if not done already
  2. in the selected braodcast EHL case, map broadcast arguments onto parent broadcast VI inputs

 

I guess the same thing can be done when the communication needs to go down the layers, and therfore applied to requests.

joerg.hampel

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 😉

 

validate-results.png

FireFist-Redhawk

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.

 

FireFistRedhawk_0-1667222483932.png

 

Ozfarmboy

Please add a test to the Validate Module tool:

 

Find all while loops in the Main.vi of the specified module(s), and check if the DQMH Error Handler - Helper loop.vi is used to handle errors in each of the while loops, and flag it if not.  Ignore the default EHL and MHL in this check.

Darren

Lately I've been running into lots of code that looks like this:

 

combined.png

I just need to start a module, call a request (and wait for reply, usually), then stop the module. I think it would be convenient if the module templates included a 'Start and Sync Module' VI that wrapped the Start Module.vi and Synchronize Module Events.vi. This is for the use case where you won't be needing to register for any of the module's broadcasts.

Olivier-JOURDAN

When you update the DQMH version, you can have hundreds of failures to fix in your projects (not because everything is broken but just because, for example, a new feature requires updating a VI).

 

A fixer is available most of the time, and you just have to click the button to make the code change.

 

For me, the UX issue is that after you hit the fix button, you need to select the next failure with your mouse and then click on the fix button. I'm not too fond of this kind of mouse gymnastics.

 

My proposition: If the fix is successful, the next failure could be selected automatically.

 

The fixing process would be significantly improved.

lderuyter

All,

 

The suggestion/request is mainly caputured in Implementation (1) at "https://delacor.com/dqmh-generic-networking-module/"

 

The proposal is to generalize the 'reply' communication by using a 'variant notifier' instead of a 'typedef notifier'.

 

I agree with the statement mentioned on the delacor website.

"This allows us to send and receive messages without knowing about their actual contents, and that’s the prerequisite for separating the module’s actual use code from the networking code."

 

The proposal is to change the DQMH scripting to always use the variant notifier. (instead of manually changing)

Actually I have changed the scripting to be able to have this automatically, which I use already 2 years. (If interest I can share with the consortium)

 

Personnally I don't see any disadvantages of using a variant instead of typedef in this case.

Also for writing the reply payload, this is not a problem as the typedef is also scripted automatically. (see screenshot) 

lderuyter_0-1643367717612.png

 

Any comments on potential disadvantages?

 

Regards,

Lucas

 

 

 

Desruelle_luc

Greetings from France

be able to upgrade the module type, for example singleton type to cloneable type, would be a great feature.

menu -> DQMH -> Module -> updgrade

A+

Luc

Update module.png

Samuel_DAM

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

Samuel_DAM_0-1623068752852.png

 

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

CyGa

A round-trip can be summarized as a Request and Reply event + broadcast of the reply.

Round-trips are particularly useful when debugging systems where the access to the module itself is hard to get (like when using TestStand / VeriStand platforms). They are very good sniffers to understand what's going on under the hood.

 

I would find it very valuable if the broadcast could also carry the request arguments !

This way the 'sniffer' could expose the context of the reply : reply is formed that way when the request contains such arguments.

CyGa

Hi,

In order to reduce the number of clicks to launch a DQMH scripter, that would be great to be able to launch them from the LabVIEW New... menu !

Indeed this window has several advantages :

  1. The tree view keeps its layout from one excution to another. So if the last thing I did from that window was to launch the 'New Event...' scripter, next time I'll launch this window this item will be directly accessible
  2. It allows inserting the created code into the project or not. So to create quick code without adding it to the currently open project, this is quite usefull
  3. The tree view makes easier to choose the scripter to launch. With Tools menu, if the mouse pointer accidently leaves the menu and overs another menu entry, you've got to go back and re-do some of the menu selection process
  4. A LV keyboard shortcut can be added to the New... action. In my case I redirected the CTRL+N shortcut to launch the 'New...' window instead of triggering the 'New VI' action. It would allow me to launch a scripter with 1 keyboard shortcut + 1 double click ! Quite fast !

Darren

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:

 

Untitled.png

 

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:

 

Untitled2.png

Olivier-JOURDAN

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.

CyGa

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.

CyGa

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)

TiTou

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.

 

jdebuhr

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)