Marc Dubois is a guest blogger. He is the owner of Harotek that specializes in the development of LabVIEW applications for Augmented Reality and for Ultrasonic Phased Arrays for Non-Destructive Testing (NDT).
Fabiola asked me to contribute to Delacor’s blog about what made me select the DQMH framework over Actor Framework for a specific project. I have struggled over this choice for a few months so I thought maybe such a post can help someone who is currently in the same situation.
A while ago, my default go-to framework (if we can call it a framework) was based on a template that I had developed myself. That framework is simply a variant of the event-based queued-message-handler. At some point, I was asked by a potential customer to quote a project that would be based on the Actor Framework (AF). I had very little experience with AF so I went through the training and I developed a version of an application I had already developed using my own framework. It was a revelation. The scripting component of AF, the simplicity of the block diagram of each actor, and the power of the object-oriented nature of each actor made me an instant fan.
I ended up not getting the contract, but I was hooked to AF. In the meantime, the DQMH framework appeared and it seemed very popular. When I had a quick look at it, at first I was not very impressed. In comparison with AF, block diagrams were much more complex (a minimum of two loops vs. none), not object-oriented, and it does not ship with LabVIEW. However, I was impressed by the documentation, support, testers, and exposure provided by Delacor and Fabiola De la Cueva.
I then had a customer asking me to develop an application that would need to be maintained, expanded, and upgraded in the future by LabVIEW newbies. I had to explain AF to newbies. Even though my explanations might have gone through with some of them, I could see a lot of bewildered eyes.
I had to admit that even for me, if I had not used AF for a few weeks, it would take me a couple of hours to readjust to the framework. This is when I attended Sam Taggart’s excellent webinar “Choosing A Framework”, which was mostly a comparison between AF and DQMH.
I decided that I would give DQMH a second chance. That time I liked it because of its ease to understand, and also because of the testers and of the scripting. I missed the simple block diagrams of AF but I realized that in AF the complexity of the block diagrams is hidden while it is exposed in DQMH. I decided that I would deal with the complexity of the block diagrams in DQMH by adding a third loop, the helper loop. This helper loop would handle most of my code and would receive messages from the Message Handling loop. I then set up the block diagram window so that it shows only my helper loop by default, where most of the code changes occur anyway. It also has the additional advantage to help prevent accidental changes to the basic communication mechanism of the DQMH modules.
I also thought that I missed the object-oriented nature of the AF actors. I realized though that the ability to create abstract actors, which I had used, was interesting in theory but never had been really useful in any of my projects. It made me think of the “Needless Complexity” code smell in Robert C. Martin’s book “Agile Software development”.
I like Sam Taggart’s analogy of AF versus DQMH as a Ferrari versus a Volkswagen. Even though a Ferrari is a higher performance car, you see a lot more cars like a Volkswagen in the streets than cars like a Ferrari. Don’t be mistaken, in the case of AF and DQMH, performance does not mean processing speeds but the potential to extend capabilities in the future and code reuse.
There are a lot of development frameworks for LabVIEW out there. So, as a developer to other developers who have not jumped onto the framework wagon, here are my recommendations based on my own experience in order of importance:
- Pick a framework. Never start a project with an empty project and an empty VI. You sure can develop your own template but see the next points.
- Pick a framework that is scripted and that allows you to easily create new components. You do not want to increase the complexity of an existing component simply because of the hurdle to create a new one.
- Pick a framework that is supported for training, technical help, and future developments. Those are important to make your code sustainable in the near future.
- Realistically evaluate your needs. You definitely want a framework that has more capabilities than what you currently think you need but not by too much. Complexity is a burden. That burden has to be carried around 100% of the time while you extract benefit from it only a fraction of the time. This is a balancing act and you might not get it right 100% of the time.
In my case (one-person development team), my default go-to framework is now DQMH. I consider AF if I see a serious potential need for it in the project requirements. I also try to keep on top of the latest LabVIEW developments in case something or someone can convince me otherwise.
Minor comment on 2: you just need to easily create new components. Scripting is used by both the AF and DQMH to overcome the need for type-specified subVIs for each message; Frameworks that use generic messages don’t need this, and thus have little need for scripting.
I agree. By scripting, I did not specifically mean “VI Scripting” but “any way to create new components other than starting from scratch”. The less work to create a new component, the better.
More food for thoughts on using / creating your own framework, I suggest watching the presentation called “Designing A Framework In LabVIEW_Borrow or Build” available at https://labviewvideo.tecnova.com/
One problem you have is you’ve only looked at two frameworks. Though very different, AF and DQMH are also similar in some ways, so you haven’t fully explored the range of design choices, such as the generic versus type-specific choice. As the developer of “Messenger Library”, I try to study other frameworks, including AF and DQMH, and similar non-LabVIEW systems like Akka and Erlang, in order to better understand the possible trade-offs.