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.
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.
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:
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 :
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)
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!
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.
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.
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.
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.
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.
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.
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)