DQMH Consortium Toolkits Feature Requests

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

This feature request is adding to the already existing "Private Request" and "Helper Loop Creation" requests (or not?):

 

When working with helper loops in cloneable modules, it would be nice to have a way for sending messages from the MHL to the helper loop which doesn't need the module ID, and which doesn't interfere with other clones' helper loop timings. I'd still like this new mechanism to look and feel like the regular events, with all the scripting and other goodness.

 

Maybe instead of calling them private events, a better name would be "local" events (which would, of course, be set to private scope).

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 !

j-medland

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
 

Olivier-JOURDAN

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.

Konan__

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

 

Clipboard01.jpg

 

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

 

thanks

 

 

Ozfarmboy

Credit goes to doyles for initially coming up with this idea.

 

Go here for previous discussions:

https://forums.ni.com/t5/Delacor-Toolkits-Discussions/Feature-request-Automate-the-Helper-Loop-creat...

 

My ideas for this are:
  1. Include a "checkbox" onto the Add New DQMH Module dialog panel that is labelled "Include a Helper Loop"
     

    image.png

     

  2. If the user checks this checkbox, a helper loop is automatically added to the Main.vi
  3. The helper loop would not be a sub-VI, but simply a third loop on the main.vi block diagram.
  4. A Wake up Helper Loop request is automatically created and included in a Private Requests virtual folder
  5. Make the helper loop generic as per Sam's suggestion. My suggestion is to have three user events: 1) Timeout 2) <Stop Module> 3) <Wakeup Helper Loop>
  6. Label the additional "Register for Events" node something different from the other "Register for Events" node, ie. DQMH_REG_EVENTS_HELPER_LOOP (so that the Validate tool does not raise it as an issue)
  7. When generating a helper loop for new cloneable modules, ensure that in the "Wakeup Helper Loop" and "Stop Module" user events, that the Addressed to this Module.vi is used.

Olivier-JOURDAN

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...

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

CyGa

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)

psmorris

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

Ozfarmboy

In the Create New DQMH Event... dialog panel, add a checkbox and label it "Make this a Private Request".
If this box is checked, the DQMH tools would create the request as normal, but store it under a virtual folder called "Private Requests" (Access scope = private)
 
image.png

 

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)

joerg.hampel

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

Darren

When I create a new Broadcast, here's what the new frame in the API Tester looks like:

 

1.png

 

I almost always end up adding the following code by hand (usually by copying it from another frame):

 

2.png

 

It seems to me that most of this code could be scripted. Maybe everything except the value of the first format string?

 

(idea originally posted here)

Darren

I would like a right-click plugin where I could right-click a DQMH broadcast subVI and "Find Event Frames". This would search all VIs in my current project for event structures that are registered for the broadcast event fired by the subVI I clicked on, and show me a list of results that I could double-click and be shown the event frames one at a time. Or I guess it could just open all the diagrams for me, since I probably want to walk through all of them anyway.

 

The operation could take a while, but would be worth it. I often find myself wondering where all the places are in my code that are registered for a particular broadcast.

 

(idea originally posted here)

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.

Olivier-JOURDAN

When creating new module, I'd like a way to add a text explaining its responsibility. It will reinforce good conception practices and allow Antidoc to retrieve information to generate a valuable documentation.

 

Note: IMO, this content should be added to the module lvlib description.

 

If this field could optionally mandatory to create the module, I would find this great 🙂

Darren

When I need one of the reply payload values of a Request and Wait for Reply VI, I need to unbundle 100% of the time. What if the Request and Wait for Reply VI output the reply payload elements individually on the VI conpane so I don't need to unbundle? I often make this change manually to my Request and Wait for Reply VIs. And I never unbundle the error from the payload, since it's already merged into the error stream inside the VI. So I wouldn't expect that output to be on the conpane. But all the other payload parameters, you betcha!

 

(idea originally posted here)

Darren

I use the Show Diagram debugging request on DQMH modules all the time. But sometimes it's not quite enough, like if there is a bug in my module *initialization*. By the time I fire the Show Diagram request, there is no way for me to debug the initialization problem. And when I say "initialization", I'm not only referring to the Initialize message in the MHL, but also all the code on the left side of the diagram that executes before we even get to the EHL and MHL.

 

I propose the following:

 

1. Add a new data member to the Module Admin class: "Show Diagram on Init"

2. Add a new input to Start Module.vi that sets this flag on the Module Admin class that is passed to the Main VI. Default is FALSE.

3. In the Main VI, if this flag is true, then Init Module.vi will show the diagram of the main VI on initialization AND turn on Retain Wire Values.

 

With these changes, the block diagram of the Main VI will appear immediately on init, and we can probe any wires on the diagram that executed during initialization to see their values.

 

It would be nice if there were a validate+fixer for this, but given that it is a debugging feature (as opposed to a change in framework behavior), I'm fine if there is no validate+fixer.