Blog

Creating a mOOnster: Practical Adaptions of LabVIEW Object Oriented

Creating a mOOnster: Practical Adaptions of LabVIEW Object Oriented

For DMC's 2014 Fed Ex Day, I spent time working on adapting the SEA Monster into a LabVIEW Object Oriented (LVOOP) format. DMC has, for many years, been developing a state machine architecture, in LabVIEW, well suited for industrial applications. By providing developers a framework of States, Events, and Actions, DMC has been able to deliver high quality solutions with minimized overhead of project configuration. Known by many at DMC as the SEA Monster, the DMC state machine is the culmination of a number of engineering minds working to streamline the application development process in LabVIEW.

Over the last couple of years LVOOP has grown in popularity amongst advanced developers. For all the reasons object oriented programming is now ubiquitous among modern programming environments, LVOOP offers developers extensibility and reuse that is not native accessible in standard VI constructs. A number of members of the NI developer’s community have worked closely in partnership with NI R&D to begin to develop and test LVOOP frameworks that can approach common LabVIEW application design challenges with LVOOP solutions. The result of this effort has been realized by the introduction of the Actor Framework. Now a native part of the LabVIEW install, the Actor Framework has been maturing as a code base into powerful base layer for advanced LabVIEW applications.

In approaching the problem of converting traditional state machine ideas into an LVOOP context, I have to consider a number of things, most notably the “state-ness” of objects. One significant hurdle in LVOOP, when compared to other languages, is LVOOP does not native support by reference object design patterns. While there are options that include the use of Data Value References (DVRs), or methods that produce single element queues, there are a number of dangers to these implementations that can result in static types (loss of override), and/or deadlocked execution. The Actor Framework was created to take these development challenges head on, and implements a queue based communications structure with corresponding object hierarchy to directly address LVOOP environment constraints.

That said, the Actor Framework presented the opportunity to source a community developed set of code, and extend its functionality to help shape the future DMC SEA mOOnster. The FedEx day project was all about developing a tangible example of executing State, Events, and Actions in the LVOOP context. Below, is a synopsis of the items addressed by this development effort:

What is a mOOnster?

•    A mOOnster is a LabVIEW Object Oriented incarnation of the ideas behind the DMC State Machine
•    The SEA mOOnster aims to preserve the development understanding of States, Events, and Actions; however, the architecture looks to develop and extend LabVIEW community resources
•    While LabVIEW OO is still at early adoption in its life cycle, there are many benefits to LVOOP programming that may improve the day to day lives of DMC engineers, and quality of delivered solutions

Creating easier reuse…

•    One fundamental part of OO concepts is code reuse. The SEA mOOnster is taking advantage of a newly developed LabVIEW architecture called the Actor Framework
•    Actors (aka. Queue Driven State Machines) can be inherited from and extended in a number of ways.
•    The Actor framework also provides, an out of the box queue/messaging system for communicating between processes.
•    Actors allow for loose coupling between components, as well as streamlined multi-threaded communications.


As of 5-1-2014…

•    As of this Fedex day, I created a proof of concept mOOnster.
•    It contains:
•    A baseline Engine class for state machine processing
•    A base class for State, to define event and action logic with context
•    A base class for Events, with abstract methods for extending event processing
•    A base class for Actions, utilizing Actor framework functions to implement true priority
•    A Global Message (local) broker was implemented to reflect point to point or group broadcast capability
•    State transition actions can be configured (On Enter/On Exit)


What does this look like?

•    A development project is under way, the intention is that all new SMs are created by inheriting and extending, instead of template copying. 

Learn more about DMC's LabVIEW programming services.

Comments

There are currently no comments, be the first to post one.

Post a comment

Name (required)

Email (required)

CAPTCHA image
Enter the code shown above:

Related Blog Posts