Fab

Hi Jordan, I will be using the DQMH shipping examples for the demos in the Reusable code presentation and we use DQMH for the project described in the Curing Cancer presentation, one of our customers will be presenting about his experience using our modular approach to his projects vs his old code & fix approach. Chris Roebuck will be using DQMH in his demos to show how to leave the coding and debugging in LabVIEW and call the public API from a DQMH via TestStand sequences during his LabVIEW Developers guide to TestStand presentation. You can also watch some of the getting started videos that we have created for DQMH, there is a link to them at: http://delacor.com/products/ Here are the presentation details: TS6420 - 5 Tips to Modularize, Reuse, and Organize Your Development Chaos Fabiola De la Cueva, Delacor Tuesday, August 4, 3:30 PM - 4:30 PM Room 19A TS7238 - Curing Cancer: Using a Modular Approach to Ensure the Safe and Repeatable Production of Medicine Duncan MacIntosh, PerkinElmer Fabiola De la Cueva, Delacor Wednesday, August 5, 3:30 PM - 4:30 PM Room 19A TS6421 - Don't Panic: LabVIEW Developer's Guide to TestStand Chris Roebuck, Delacor Thursday, August 6 2:00 PM - 3:00 PM Room 16B Hope to see you there, Fab

Glad you liked it, this has been a Delacor team effort: we had 3 CLAs involved in architectural design decisions, design reviews and implementation. We also have been using this in several projects and gathering feedback from customers and Delacor team members. I don't want to take all the credit. I am sure there are lots of versions of this architecture out there. The community has been using variations of QMH architectures for a long, long, long time. Delacor team members have been using variations of the DQMH for at least 10 years. We decided to publish ours, because it is easier to ask our customers to use something available from the LabVIEW Tools Network that has the "LabVIEW compatible" logo and it is more convenient for us instead of having to reinvent the wheel for every project, or worse, a flatten tire, because we forgot one little detail here and there. IMHO, the scripting tools are the biggest feature in DQMH. I still smile every time I create an event or add a DQMH module. BTW, if there are features missing or people would like to add similar scripting tools to their existing architectures, please talk to us, we might be able to make this happen for you. We didn't think about adding global messages, we will give it some thought, although I believe this would go against our goal of keeping DQMH modules as stand alone modules to reduce coupling between modules. We realized we were not covering 100% of the use cases for "Request and Wait for Reply" events. We went for the template that would answer 80% of the cases with a very short timeout. In the future we will have a blog post with some of the alternatives we have for this type of event. We even hesitated to include this type of event, because of the potential for deadlock. This type of event is very rare in our current applications. Some of the comments/feedback we got from the CLA summit was that we should have used a SEQ instead of a notifier, because for large data sets the notifier will result in a data copy and the Queue would not. We decided that the notifier was more readable and again it covered 80% of the usage. If the reply requires large datasets, the argument of the notifier reply could be wrapped in a DVR. This is not always the case, when using the Tools>Delacor> Create New DQMH Event... menu, you will see that there is an option of creating a "Round Trip (Request + Broadcast)". This option creates the Request Event and the Broadcast Event both sharing the same typedef for their argument. In a DQMH module, the Requests can be found as part of the Public API virtual folder in the DQMH Module.lvlib. When finding where these functions are called, we can find what other code is making requests of the module. The Broadcasts can be found as part of the Broadcasts Private folder in the DQMH Module.lvlib. These VIs should only be called by functions within the DQMH Module.lvlib. In our case, we found that keeping these functions separated in this fashion resulted in the best Developer Experience. Especially when dealing with different levels of proficiency. Some of the teams we work with, the architect would create the DQMH and a CLD or CLAD would just call the Public API VIs, they only care about using the Requests. In fact, some of our customers choose to lock the DQMH Module library so the junior developers have access only to the Public API VIs. In a DQMH module the Queue is private to each module and it is used to send messages within the module itself. The Events are used for any external communication handling. This is an interesting idea. It is really hard to draw the line on what is needed for every single application and what is needed only for some applications. We tried to keep the DQMH Project Template to the bare minimum we found ourselves and our customers using in all of their projects. The DQMH Enqueue Message is a polymorphic VI that has the option of enqueing a single message or an array of messages. Also, the DQMH is a Queued Message Handler, not a state machine. Implementing a State Machine with a module that is asynchronous and can receive messages from a lot of different points in the application leads to getting messages in between the state machine states. If a true state machine is needed where none of its states can be interrupted, then we would code that case in the Message Handling Loop to call an actual State Machine. See my blog post on the NI QMH the section on Using a QMH as a State Machine: http://www.walkingthewires.com/2015/05/08/ni-qmh-template/ This is another example of us deciding to keep things to a minimum. We do have a DQMH Configuration Editor module that we use internally and gets modified to fit the needs of every application. So far this module has changed so much depending on the requirements of each customer, that we decided we couldn't include a version generic enough in the DQMH Project Template. Depending on how many people end up using DQMH, we might make modules like this one available in the future. Or maybe other members of the community decide to share their DQMH modules with the rest of the community. For debugging we went with the option of including a Test DQMH Module API.vi with every DQMH Module. It includes a status window that can be used to monitor what is going on with that particular DQMH module. This tester can be used to test the DQMH module or as a sniffer when the main application is running to eavesdrop on the communication for that DQMH module. We kept the Singleton and Cloneable modules separate, because we agree with you that most of the time cloning actors is not needed and we didn't want to burden the 90% of developers with the clone management needed just a few times. We wanted to make it possible to restart a module without having to restart the entire application. The DQMH Module Public API VIs return an error if the module is not running. This can be tested via the Test DQMH Module API.vi, if any of the buttons are pressed before the Start Module is pressed, the error will be shown that the module is not running and the tester will stop. The Test DQMH Module API.vi includes a "Show Block Diagram for Troubleshooting" button, this works both in the Singleton DQMH module and the Cloneable module. In the cloneable module, the developer can choose to send the request to All clones or to an individual clone at a time. This is one of my favorite features. One that I thought at the beginning it was not needed, because my workaround of holding the CTRL and double clicking kind of worked, but if you have a chance, give this button a try… this is another feature that makes me smile every time I use it and prove that having a team to review your decisions leads (hopefully) to a better developer experience for all. Even longer now with all my replies I appreciate you taking the time to take a look at the DQMH toolkit. I am looking forward to meeting up with you next week and talking more about this. Happy wiring, Fab

Hi LAVA friends, We are pleased to announce that the Delacor Queued Message Handler (DQMH) is now available via the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286 You can read about the thought process behind DQMH at our blog post: Ours is not better than yours (or YAF=Yet Another Framework) at WalkingTheWires.com The DQMH is based on the NI QMH Project Template. The DQMH expands on the NI QMH by providing safe, event-based message handling and scripting tools to encourage same style between different developers in the same project and improve efficiency. The DQMH is ideal for applications where multiple modules must run in parallel, possibly at different rates, while communicating with each other. The DQMH can also be used for applications that have a single module, where the developer would benefit from having a Tester with the capability of eavesdropping on the different DQMH events and messages. The DQMH integrates with TestStand since all development and troubleshooting can take place under LabVIEW, while calling the public API VIs as individual steps in the TestStand sequence. The tester can eavesdrop during the execution of the TestStand sequence. This is specially useful when the LabVIEW code is written during the research and development or prototyping phase, because the same code can be called by TestStand in production or manufacturing sequences without any changes. The DQMH uses LVOOP for some internal functions, but developers need not be familiar with LVOOP to use or understand this architecture. Try it out and let's us know what you think. Fab and the Delacor team.