Leaderboard

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 guys; Wanted to share another exciting upcoming tool we will be releasing in the next few months. The Programmable Wireless Stamp is a tiny (but powerful) wireless hardware target we will be able to deploy LabVIEW code to by using the Arduino Compatible Compiler for LabVIEW. Some high level information on the link below. http://www.tsxperts.com/programmablewirelessstamp/ Our goal is to create an easy to use LabVIEW IoT platform that will allow us to quickly and inexpensively create wireless data acquisition systems and IoT applications. We don't have final pricing on it quite yet, but will be sharing that with the community as soon as we do. It is a great time to be an Engineer... Filipe

Hey guys, Thread is old and haven't checked up on it in awhile. I have been buzy refining my Lua-to-LabVIEW binding library which I call GLue now. The major improvements are: The API is now more simple and consistent Added support for both 32bit and 64bit Windows Does not link with the C runtime, reduces external dependencies (was quite a bit of work) Does not link implicitly with the LabVIEW executable/runtime (portable accross LabVIEW versions) Hundreds of unit tests Multiple large industrial applications already developed and running flawlessly for last couple of years A welcome side effect from this effort is the ability to debug embedded Lua scripts remotely via the excellent ZeroBrain Studio. This allows for first-class Lua development & debugging within LabVIEW.