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) 😉

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.

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:

bit.ly/DelacorQMH