ni.
com
Using OOP in Measurement Systems
[Link]
Common Problem: Software becomes difficult to
maintain over time
Initial investment in
software architecture,
training and processes
[Link]
Why OOP is an Answer
When you want to build scalable, extensible systems.
Translation: OOP concepts, when used correctly, decrease
the risk and effort required to add functionality to an
existing system. They do this, in part, by:
- Minimizing the scope of changes that have to be
introduced to an existing system to add new functionality
- Restricting access to data to methods that have explicitly
been permitted access
- Making it possible to add and load new behaviors
dynamically that implement existing interfaces
- Enable reuse and extension of pre-existing functionality
[Link]
The journey to OOP starts sooner than you think
Configure
Acquire
Measure
Conceptually, many LabVIEW applications start with a simple,
synchronous set of operations (many times all on a single diagram)
[Link]
Configure
Measure
Acquire
Start Task
Read Samples
Stop Task
Savvy programmers will often use SubVIs to wrap API calls to things
like device drivers or loading configuration from a file
[Link]
Task
Graph
Samples
DAQ Task
Clock
Raw Data
Configure
Acquire
Measure
These SubVIs typically expect certain inputs to do their jobs many
times these inputs are the output of previous operations, or a single
input is shared by multiple VIs in this sequence
[Link]
Measurement System
Task
Graph
Samples
DAQ Task
Clock
Raw Data
Configure
Acquire
Measure
As the application becomes more sophisticated, its common to want
to iterate on certain tasks within a loop..
[Link]
Measurement System
I/O
Graph
Samples
DAQ Task
Raw Data
Clock
Configure
Acquire
or perhaps the entire system
[Link]
Measure
Measurement System
Configure Event Case
Task
Clock
Configure
Eventually, automation requires that we be able to programmatically
control the order of operations and/or restart the system, which
requires a state-machine-like pattern that passes data between states
[Link]
Measurement System
Acquire Event Case
Samples
Raw Data
Acquire
The scope of data these operations has access to can be seen by
examining the shift registers in a loop
[Link]
Measurement System
Measure Event Case
Graph
Measure
[Link]
Measurement System
I/O
Event Case
Cloc
k
Samples
Raw Data
Task
As the functionality grows, so too does the scope of data. Eventually it
becomes helpful to contain all of this data in a cluster, giving us a very
clearly defined data-scope for this process
[Link]
Measurement System
I/O
Event Case
Cloc
k
Samples
Raw Data
I/O
Task
Cloc
k
Task
Configure
The methods within this state machine retrieve the information they
need from the cluster and update values as necessary
[Link]
Measurement System
I/O
Event Case
Cloc
k
Samples
Raw Data
Task
Configure
Unbundling and bundling data can be encapsulated by the VI, giving
the user a clean, simple top-level interface (the type definition)
[Link]
This simple illustration shows how these three operations we started
with now just act upon the data within the cluster
I/O
Cloc
k
Graph
Samples
Raw Data
Task
Configure
Acquire
Measure
These VIs are explicitly coupled to this data
[Link]
A class is basically a cluster
I/O
Cloc
k
Samples
Measurement
Class
Raw Data
Task
Measurement
Data
A class contains data, plus
methods (VIs) that are allowed
to act upon and modify the data.
VIs that do not belong to the class
cannot act upon the data
[Link]
Measurement
Graph
Configure
Acquire
Measure
The object wire can be passed into any VI that has the class on the
connector pane, but only VIs that belong to the class can directly
bundle and/or unbundle the data
[Link]
Class Data Cluster
Class constant
I/O
Cloc
k
Samples
Raw Data
Task
Methods that can act upon
the classs data cluster
Appearance in Project
Configure
Acquire
Measure
These VIs are now owned by the class. They are
transported as a cohesive library of code
[Link]
Demonstration
Creating a New Class
[Link]
Measurement System
I/O
Event Case
Cloc
k
Samples
Raw Data
Task
Configure
Returning to our basic system, this implementation using a clsuter
effectively becomes
[Link]
Measurement System
Case
Measurement
[Link]
Configure
Measurement System
Case
Measurement
Configure
What if you want a different definition of how these methods should act?
In this example, consider the different ways in which a measurement might be implemented
[Link]
Inheritance Allows Descendant Classes to Modify, Extend and
Add Functionality of a Parent
Measurement
Temp
Finite measurement of a
single channel
Strain
Applies stimuli before
acquiring value
These are children of the measurement class
[Link]
Demonstration
Define inheritance and view the class hierarchy diagram
[Link]
Measurement System
Case
Measurement
Configure
What if you want a different definition of how these methods should act?
In this example, consider the different ways in which a measurement might be implemented
[Link]
Acquire is Dynamically Dispatched
Measurement System
Case
Temp
Acquire
Start Task
[Link]
Read Samples
Stop Task
Acquire is Dynamically Dispatched
Measurement System
Case
Strain
Acquire
Start AO Task
Start AI Task
[Link]
Stimulate
Output
Sweep Inputs
Understanding Dynamic Dispatch
Strain
Temp
Acquire
610
2
Resistance
[Link]:
[Link]
[Link]
[Link]:
[Link]
[Link]:
[Link]
Demonstration
Illustrate dynamic dispatch
[Link]
Graph
Configure
Acquire
Measure
Q: Isnt this the same thing as using case structures inside these VIs ?
I/O
Cloc
k
Samples
Raw Data
Task
Configure
Measurement Type
[Link]
Acquire
Measure
Graph
A: Its conceptually similar, but there are extremely
important differences(NO)
To understand the difference, first consider the impact of
introducing a new measurement in the non-OOP example.
3. We probably have to add new elements to
this data cluster
I/O
2. We have to modify all of these VIs
Clo
ck
Samples
Raw
Data
Task
Configure
Measurement Type
1. We have to add a new type to the enum
[Link]
Acquire
Measure
Graph
I/O2
As the scope of the data cluster expands, we are
passing data into large segments of code inside
the cases that should not have access to it. Our
data is not protected
DIO
Trigger
I/O
Clock
Samples
Raw
Data
Task
Configure
Acquire
Measure
Measurement Type
Introducing a new measurements requires
changes within the VIs, as well as the calling code
(sometimes referred to as a framework). This
makes code very costly to maintain and brittle
[Link]
Graph
Sibling Classes Have Unique Data Scope
Data that every measurement
needs to have
Task
I/O
Samples
Measurement
Thermocouple
Bridge Type
excitation
Strain
Temp
Data unique to these specific measurements, plus
exposed data of parent measurement
[Link]
One of the biggest differences: this new
functionality has to be added at edit time.
I/O2
DIO
What if you want to load a new measurement into
your calling system at run-time?
Trigger
I/O
Clock
Samples
Raw
Data
Task
Configure
Acquire
Graph
Measure
Measurement Type
Yes, you can dynamically load the VIs called by these VIs, but you have to
have pre-defined the data they have access to. The data in the cluster wire
cannot be changed at run-time, as the connector pane must match exactly.
[Link]
At edit-time, LabVIEW shows us the wire of the
parent class we have said will be passed along
this wire (in this example: [Link])
Graph
Configure
[Link]
Acquire
Measure
We may pass any child of this class down this wire
at run-time. Dynamically dispatched methods will
execute the copy belonging to the run-time
instance.
Graph
Configure
Acquire
Measure
LabVIEW can load a new child at run-time. The class will bring its methods and
its data cluster into memory when loaded. This makes it possible to add
functionality without modifying calling code. The code to load a child class is
referred to as a Factory.
[Link]
The Basics of an Object Factory
Objects Loaded Into Memory
Generic Measurement
Parent
Location on Disk
Where Measurements
Classes are Stored
[Link]
Children
Group Exercise
About that Graph output what if my measurements output different data types?
Strain
Graph
Temp
Configure
Configure
Acquire
Measure
Acquire
Boolean
Measure
Dynamically dispatched VIs must have the same connector pane. You cannot have a
different data type output on Measure. So how do we solve this problem?
[Link]
Q: How can an instance of the measure method return
information that is appropriate and specific to the measurement
class it belongs to?
Consider the following requirements:
Measure
We have to pass different data-types at-run
time out of the measure method
We always know a specific measurement will
return a certain type of data
We need to be able to display that data to a
user in an appropriate format
We need to pass the data back to a framework
that implements a pre-defined interface for
operations like dispaly, save, etc
Is a variant a valid solution?
We can pass any data-type on a variant wire
How do we know how to display the data on a variant wire to a user?
If we pass the variant to our calling code, how will it know how to save it to
disk or display it to the user?
[Link]
Use a Class Hierarchy
Measurement Result
Defines methods all results
should be able to define, such
as Save, or Display
Strain Result
Temp Result
Resistance Result
Each has a unique private data cluster to store the result of a measurement and
defines how that data is stored or displayed using dynamically dispatched methods
that override the interface defined by the parent Measurement Result
[Link]
General Best-Practice: Dont Use Variants
Variants are typically used when different types of data
have to travel down a single wire. Anytime you feel the
need to do this, consider replacing the wire that would be a
variant with a class hierarchy.
Why? Classes still enforce strict data-types at edit-time,
thereby ensuring no run-time errors. Variants do not, and
therefore increase the likelihood of run-time errors.
[Link]
All measurements will need to use hardware.
Measurement Class
Configure
Acquire
Measure
But Id like to..
run the same measurement class on different
machines, which have different hardware
continue development on a machine with no access
to hardware
be able to add a new device of a certain type without
modifying the measurement
[Link]
A measurement is defined assuming certain
classes of devices are available, but without
knowing exactly which instrument.
Temp
In this example, this measurement strategy uses a DMM. It
assumes an instance of a DMM implements a pre-defined
interface, without knowledge of how that interface is implemented
Configure
Measure
Acquire
DMM
Class
Configure
Current
Source
[Link]
Autozero
Read
DMM
Class
Agilent
34401a
[Link]
PXI-4070
Simulated
DMM
Other measurements may require different classes of hardware, or perhaps multiple
devices (ie: stimulus/response measurements), but we cant change the connector pane
of methods we want to override (like [Link]).
Measurement
Class
Configure
?
[Link]
Acquire
Measure
The objects passed along this wire must all
be children of the same parent class
Measurement
Class
All measurements use an array of hardware
Configure
Acquire
Measure
But different classes of hardware would
definitely not implement the same interface
[Link]
Sample Hardware Class Hierarchy
Hardware
Power Supply
PXI-4110
[Link]
Simulated
DMM
Simulated
34401a
Generator
Scope
PXI 4070
Simulated
PXIe-5185
Simulated
Measurement
Class
Methods can cast hardware objects to specific children at edittime using the to more specific primitive
Configure
Acquire
Measure
DMM
SCOPE
The dark blue wire can be passed into the
interfaces for the specific device classes
[Link]
Demonstration
Use these concepts in a real system
[Link]
Summary of Most Important Concepts
Always be thinking about data scope keep it cohesive and
small
Classes create define data scope and a set of functions that
are allowed access to data
Consider using a class hierarchy to replace a massive data
structure
Dynamic dispatch allows child classes to override a parents
method and reuse others
Dynamic dispatch occurs at run-time, whereas polymorphism
occurs at edit-time
Use parent classes to define the interfaces children should
implement
If you find yourself using a lot of variants, consider a class
hierarchy
And finally, classes are not as big of a leap as you might think
we hope you agree after this presentation!
[Link]
Want to Learn More?
Trained LabVIEW Users reported developing 50% faster and
spending 43% less time on maintenance
The Object-Oriented Design
training course is available Online!
Visit [Link]/training/self-paced to
learn more
Prefer a live instructor?
Find a classroom course near you
at [Link]/training
[Link]
Join the 10,000 + NI Certified Professionals
Validate your skills
and differentiate
yourself from your
peers with NI
certification.
In a worldwide survey, Certified LabVIEW
Developers (CLD) reported:
54% reported improvement in work quality
45% reported improved peer perception
30% got new project opportunities
0%
20%
40%
as a result of NI Certification
Start preparing now at
[Link]/training/certification_prep
[Link]
Email certification@[Link]
To Schedule Your Exam
Looking for More?
Attend a CLA or CLD Summit to:
Network and exchange best practices with other
certified professionals and NI engineers
Participate in highly technical presentations
Get exclusive opportunities to meet with NI
developers
Take the recertification exam for free
Learn more at [Link]/cla-summit
[Link]
You must be certified to attend a Summit.
Email certification@[Link] to register for
an exam near you.
Missed the CLA Summit this year?
Get certified for next year!
The Certified LabVIEW Architect (CLA) Summit brings
together some of the worlds best NI LabVIEW programmers
to discuss architectures, preview new features, and network
with other CLAs and members of NI R&D.
Learn more at [Link]/cla-summit
Email certification@[Link] to register for
an exam near you.
[Link]
Already CLAD Certified?
Youre immediately eligible to take the Certified
LabVIEW Developer exam. Start preparing now!
Join a local user group
Prepare using resources on Developer Zone
[Link]/training/certification_prep
Time yourself during practice exams
Note: CLAD certification must be current to take the CLD
exam
Email certification@[Link] to register for
an exam near you.
[Link]
[Link]
