LabVIEW Development Best Practices Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

Introduction to Object Oriented Programming and Hardware Abstraction Layers

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: http://www.ni.com/webcast/3431/en

Topics Covered

  • When should OOP be used
  • How to use a class in a QMH
  • Data encapsulation
  • The mechanics of creating and editing classes
  • The difference between dynamic dispatch and case structures
  • Measurement Strategy Abstraction Layers (MSAL)
  • Hardware Abstraction Layers (HAL)

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.

Elijah Kerry
Chief Product Manager, Software Platform
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Comments
mike_nrao
Member
Member
on

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.

crossrulz
Knight of NI Knight of NI
Knight of NI
on

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Fire
Member
Member
on

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

Elijah_K
Active Participant
Active Participant
on

You can watch a recording of this presentation I recently published here: http://www.ni.com/webcast/3431/en

Elijah Kerry
Chief Product Manager, Software Platform
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
gregorian7
Member
Member
on

Hi,

 

Has anyone got proper version of download file?. 

 

Asking as Demo project is missing all methods.

 

Thanks,

 

Gregorian7

LoCa
NI Employee (retired)
on

The same here 😉

hwilterdink
Member
Member
on

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

Contributors