DQMH Consortium Toolkits Feature Requests

This was originally raised by Joerg here:

https://forums.ni.com/t5/Delacor-Toolkits-Documents/DQMH-Feature-Requests/tac-p/3974021/highlight/tr...

To quote Joerg:

"Sometimes, the error cluster that feeds into the Delacor QMH Error Handler - Message Handling Loop.vi doesn't convey enough information to identify the origin of the error. For example, an Error "91 - Variant To Data in xyz.lvlib:Main.vi" does not tell me in which MHL case the variant to data operation failed. It would be nice to have the selector label of the MHL's case that the error occurred in."

Feature Request: Somehow (not sure what the best way would be) make the error handler include the last message's name (string) in the error broadcast."

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.

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)

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

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.

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.

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)

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
 

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

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/

Hi, I'm currently refactoring some old code that contains helper loops, those helper loops weren't created using the DQMH Scripting tool, to homologize them, I'm following the helper loop prerequisites described here , one of the prerrequisites is that the error debug input to have a constant with the label "DQMH_HELPER_LOOP" and write the actual name of the helper loop, what I'm proposing here is to change the Error Debug name to this label only for the Error handler - helper loop.vi

This will help us create a constant for this input with the label already there, eliminating the need to visit the DQMH documentation website to get the right name.

Best Regards,

Enrique.