This post was originally published at Walking the Wires
YAF stands for Yet Another Framework.
I know a large number of LabVIEW developers either have their own templates, or would like to have their own templates. What I want to do is walk you through how we approached ours – because it was driven by some high-level principles we have learned about LabVIEW and also by some specific decisions that relate to our particular customers at Delacor.
My hope is that you will see something here that makes you say “a-ha!” or maybe you will want to just adopt our approach as your own, or maybe you will see something we are doing wrong and tell us, so we can improve our approach.
Why would we create our own template? Well, because that is what CLAs do (picture me here grunting and acting like a strong Architect) 😉
Strong Super CLA
No, seriously. At Delacor, we want to point our customers in the right direction and set them up for success on their own.
Of course they can call us for help with complicated problems or architectural assistance, but the more they can handle by themselves the more valuable our service is to them. That is why we wanted to have a project template our customers would feel comfortable with. We were looking for a project template that NI Support would feel comfortable supporting and recommending due to its familiarity with known shipping templates.
We have repeatedly seen our customers call NI for help with a hardware issue, and AEs don’t do as well if the software architecture is not something they recognize. If our framework looks roughly like something NI ships, it makes it easier for our customers to either help themselves, or get help from NI without having to call us for maintenance. We rather have our customers call us when they have architectural questions or questions specific to their application.
Many of our customers already have a team of LabVIEW developers with different levels of proficiency. We were looking for a project template that was accessible to an entry-level CLD, but was also extensible for more advanced users. We wanted something that would work with TestStand. A spring board that would facilitate testing of different application parts and integrating modules developed by multiple developers with multiple levels of proficiency. We wanted a template that would not require complete understanding of LVOOP so that if we were to add it, LVOOP would have to be just for support and not get in the way of developers who do not feel comfortable with LVOOP yet. The cherry on top was that it would make it easy to support multiple instances of the same module.
There are other templates, frameworks, architectures and spring boards out there which are well recognized by the community. Over the years we have successfully used two starting points: The shipping Project Template for QMH and the project for Private and Public Events that Justin Goeres presented at CLA Summit / NIWeek 2011. After trying these out with different customers, we realized each one covered some of our needs, and we could combine their best features, such as modifying the shipping QMH Project Template to make the internal queue private (see my presentation at CLA Summit Paris). We also realized that there were different roadblocks for our customers. One was the terminology used in the Private/Public events template, and another the number of steps required to add a new Private/Public User Event. Finally we realized that when the application needed to interact with TestStand, for example, lifetime ownership of events becomes an issue that needed to be addressed.
We changed the terminology to something that it is better understood in Actor Oriented design: Requests and Broadcasts.
Reducing Complexity and Learning Curve
When a request is sent by other modules to our module via a public interface VI, our module responds, and any module registered to listen to its broadcast gets notified when a new broadcast is available. This is an asynchronous approach by default, so we also added a type of event called “Request and wait for Reply” for those cases where the communication needs to be synchronous.
We also enlisted the help of a LabVIEW Scripting expert who helped us add scripting Tools for adding/removing the Events, creating new modules, selecting which type of module to use: Singleton or Cloneable.
We created our own Project Template and included a tester and shipping examples.
Finally our Sample project can be integrated with TestStand easily by calling the public API messages as sequence steps in TestStand. This keeps the execution in LabVIEW where you can run sequence steps and troubleshoot without running the entire test sequence.
The DQMH is not perfect. We can not take an existing DQMH Module and just override one of the events or how an event/message is handled. Putting it another way, there is no inheritance. If we make upgrades or changes, you will have to integrate them to your existing modules (although, on that last point, we do have a Validate DQMH tool that could be used in the future to upgrade an existing DQMH module to match the latest version of the package). So, we are not claiming this is the Framework to Rule All Frameworks, but we think it’s pretty darn good :).
And speaking of packages, the DQMH is available via the Tools Network. Go to ni.com/labviewtools, search for dqmh, and give it a try!
Happy wiring,
Fab
More information at: delacor.com/products
Support: ni.com/groups search for delacor.
We have created a series of videos to introduce the DQMH:
Thank you for the comments on the NI forums; I spent some time this weekend playing around with the tools and I really enjoy the flexibility that comes with your “modules”. I do have a comment/question about the documentation: could you include some “best practices?”
Some best practices are already included (like the steps you should take when using the “Remove Event” tool.)
I still have a couple of questions, like:
-When creating a new project, should we rename “My Singleton Module” or simply remove it from the project?
-If we want Application:Main.vi to simply launch all modules (or be significantly different from the default), is it safe to delete the block diagram and just include the launch code?
That’s all I can think of for now. Thank you again for these cool tools, I’m really looking forward to trying it on my next project!
Hi Gregory,
Thanks for the feedback, we like to hear that people find the DQMH flexible and useful.
Regarding your questions:
“When creating a new project, should we rename “My Singleton Module” or simply remove it from the project?”
For DQMH 1.0: You can remove it rom your project and add a new DQMH module via Tools>>Delacor>>Add New DQMH Module…
For DQMH 2.0: (oh oh, am I doing a pre-relase announcement here? maybe 😉 ) We are adding a feature that lets you rename the My Cloneable and My Singleton Modules from the create project wizard. We will also add a new Tools>>Delacor>>Rename DQMH Module… Stay tuned for DQMH 2.0 official release. You can sign up to our DQMH News Letter via http://delacor.com/products/ and we will notify subscribers first.
“-If we want Application:Main.vi to simply launch all modules (or be significantly different from the default), is it safe to delete the block diagram and just include the launch code?”
Absolutely! Like I mentioned in the posts and on the videos, we just had a simple state machine for an Application Main just to show that any code can be used to call the public API functions created in your module.
If you open the shipping example (Help>>Find Examples>>Fundamentals>>Loops and Structures>>DQMH Fundamentals – Thermal chamber.lvproj) you will see three simple stand alone VIs (Thermal Chamber Controller.vi; Thermal Chamber Controller with DUT.vi; Thermal Chamber Controller with Multiple DUTs.vi). All of these VIs call the public API functions for the Thermal Chamber DQMH Module as well as for the Device under test DQMH Module. The beauty of the public API created for your DQMH modules is that they can be used by any level of LabVIEW developers. So you can even call it from code that doesn’t even have an event structure.
“Thank you again for these cool tools, I’m really looking forward to trying it on my next project!”
And we are looking forward to hearing your feedback when you do! 🙂
For reference to others, Gregory is referring to this thread in the NI Forums: http://forums.ni.com/t5/LabVIEW/QMH-Message-Management/td-p/3212813
We also have a group dedicated to Delacor toolkits in the NI communities: https://decibel.ni.com/content/groups/delacor-toolkits
Fab
I enjoy reading your blog posts here and have taken a good in depth look at DQMH now.
What I would like to see is a blog post comparing DQMH to the actor framework. Since NI decided to bundle it into Labview, I don’t think it qualifies as “yet another framework”.
Two things I note it that the Actor Framework seems a bit more complicated than DQMH and therefore may have significantly more overhead. On the other hand, it goes a long way to try to prevent race conditions and block many of the problems of full duplex comms between parents and their children.
What do you think of this idea of writing a comparison piece in “Walking the Wires”?
-Allen
Hi Allen,
DQMH and AF target different audiences, we don’t think a comparison would be appropriate or useful to everyone and worse still, may give an unfair view of one or the other framework. If you have looked at DQMH in depth we would welcome your feedback. We maintain a community page here where you are invited to give feedback and make suggestions for future versions.
Thank you for taking the time to read our blog and for evaluating DQMH.
Chris