Learn how to build scalable, extensible measurement systems using object-oriented programming practices in LabVIEW. This session aims to make OOP approachable for anyone who is already comfortable with basic LabVIEW programming and highlights common use cases for OOP, including creating a custom hardware abstraction layer.
This session will explain how OOP can be used to minimize the scope of changes that have to be introduced to an existing system in order to add new functionality and how the use of classes helps define the relationship of data and the methods that act upon that data.
Recorded presentation here: https://www.ni.com/en/shop/labview/introduction-to-oop-and-hardware-abstraction-layers.html
Topics Covered
Demonstration Setup
The attached demo file requires that the Measurement Utility be installed. Please download and install the latest version of this demonstration from here.
Great presentation! It serves as a nice gentle intro to OOP for intermediate-level LabVIEW developers. The logical progression from showing difficulties with non-OO design through Measurement and Hardware abstration makes a strong case for adopting OO design. I think OOP can be taught without presumed knowledge of QSM, simple state machines, user events, and variants, but the case for it isn't as persuasive.
It seems like a large leap to go from OOP basics to full-blown MVC-style Actor Framework application. Depending on the audience, the AF intro may be better served as a follow-up presentation. But, on the other hand, it does aid in supporting the case for OO design.
The slide progression seems to imply that Actors can by dynamically loaded from disk in a deployed application (combined ideas from slides 65 through 68). To my knowledge, this is quite difficult (border-line impossible); am I wrong?
Looks like slide 40 is a duplicate of 68, and probably unintentially copied there.
I would like to see SMoRES notes have their own slide. (Who coined the term "SMoRES"?)
It would also be nice to springboard from this presentation to more advanced concepts, so an 'Additional resources' slide full of links to related topics would be great.
Michael Lacasse wrote:
I would like to see SMoRES notes have their own slide. (Who coined the term "SMoRES"?)
It was actually Norm's original LabVIEW mentor. There's a presentation floating around somewhere in the communities where Norm gave him credit. I worked with the guy as well. He's no longer doing software. He's in a head position of process improvement.
Hi folks
I also prepared an Introduction to LVOOP, object-oriented programming with LabVIEW.
It is a hands-on tutorial dealing with configuration data in an object oriented manner. It includes talk and manual in german and english language. It was presented during VIP 2012 and 2013. It is puiblished on github, https://github.com/HB-GSI/VIP2012.
Best regards Holger
You can watch a recording of this presentation I recently published here: https://www.ni.com/en/shop/labview/introduction-to-oop-and-hardware-abstraction-layers.html
Hi,
Has anyone got proper version of download file?.
Asking as Demo project is missing all methods.
Thanks,
Gregorian7
The same here 😉
I have some questions regarding slides 39 - 41; I encountered a situation like this in a real-life project, but did not end up using the solution suggested in slide 41.
The situation is that you have unified your measurement hardware into a class heirarchy, but realized that two different pieces of hardware will return different values (e.g. a graph array and a boolean in slide 39). The proposed solution is to create a new Measurement Result.lvclass with methods like Save.vi and Display.vi, and then create a few child classes to override these methods for the different data types. Sensible enough, and I can picture how Save.vi might work, but what about Display.vi? I would want it to output a data type that will then get wired to a front panel indicator, but now I'm back where the problem started--I can't have two different overrides of Display.vi with different connector pane outputs. So then the variant starts to look like the only solution. In my case I didn't output a variant, but realized all my outputs could all be represented as DBL waveforms, which worked well enough for graphing purposes needed at the time.
What am I missing? Does anyone have thoughts on what would be a more OOP solution? Could (should?) Display.vi be a popup window with its own front panel indicators, instead of outputting its data to some higher-level front panel indicator (which is unattractive to me because it seems to quickly proliferate many floating windows)?
Hello Elijah,
after your great introduction to LV OOP I'm really interested in diving deeper into this topic.
Unfortunately I can't get your attached example "Intro to OOP Demonstration.lvproj" working.
I installed the package "EV Battery Test Software 0600318 (NIWeek 18).vipc.zip" as well, but the following elements are still missing.
I'm using LV2019, 32 Bit.
What am I missing?
Thanks in advance
Best regards
Markus
I am a latecomer to this LVOOP tutorial post by Elijah. I would like to read the PDF first but no longer opens in Windows 10 or 11 as the Flash player plugin is no longer available. Question, is the PDF same as the PPTX content? Thanks guys!!
Aldrin