LabView Basics
The Fighting Pi Controls Group
About LabView
• LabView is a highly adaptable programming
GUI (Graphic User Interface)
• LabView compiles the code into machine
instructions, much like the programming
language C
• This language is used extensively throughout a
wide variety of industries
Basics Terms to Know
•
•
•
•
•
•
VI
Wires
Local and Global Variables
Front Panel
Block Diagram
Connector Panel
VIs
When using LabView, you are actually creating
segments of code called VI’s (virtual
instruments). A sub-VI works just like a VI, but
you can use a sub-VI within a VI. VI’s are
composed of three parts, which are the front
panel, the block diagram, and the connector
panel.
Wires
Wires are a
visual
representation
of how different
functions
connect to each
other in the
block diagram.
Wires are color coded. Blue
indicates a constant that is an
integer, orange stands for
numeric values, green stands
for a T/F value, and so on.
Variables
The color of a variable denotes the type of
data that it contains. Orange means
These two
numeric.
variables have
their borders
filled in. That
shows that
they are
configured to
be read from.
The others are
set up to have
The picture
data written
of a globe
into them.
shows that
it is a global
variable
Local Variables
There are two types of variables in LabView.
The purpose of either one is to transfer data
throughout your code. The first is a local
variable, which allows you to read or write to
a control or indicator on the front panel. This
allows you to force a control’s value with the
code, or use an indicator to store data. These
can store all types of data, such as numeric
values, strings, T/F values, or arrays.
Global Variables
A Global variable is identical in function to a
local variable. The difference between them is
where the data is saved. A local variable saves
the data to the front panel of the VI that it’s
in; this makes them only be useable in that VI.
A global variable is saved in a special global
variable VI, and all VIs within the project can
use it.
Front Panel
The front panel of each VI is where you will
actually use the program. This is where you
place all of your controllers (they allow you to
set a value), indicators (they show you the
current value of whatever you wire them to),
and anything else you want in your functional
program. You can add buttons for T/F logic,
and many other graphical options.
A Basic Front Panel
As you can see, you have many
options for how you want your
program to look. You can add
displays, graphs, and much more
here if you so choose. Everything
that is related to your actual
program that you add here
(buttons, indicators, stuff like
that) will create a representation
of the value in the block diagram
Block Diagram
The block diagram is where you write your
actual code. You use wires to connect
different inputs, outputs, functions, and
values. All of the code runs parallel, which
means that it follows the wire left to right.
Because of this, you must be careful not to
read and write to a variable or file without
forcing the code to do so in the order that you
want it to.
A Simple Block Diagram
Here you can
see a very
simple block
diagram
You use wires to connect
inputs to functions to get the
desired outputs
I have the
end result
wired to an
indicator.
This will
allow me to
see the
output in the
front panel
Connector Panel
The connector panel allows you to turn a VI
into a function. This makes it easy to simplify
code. The connector panel has a picture that
you make of the code to represent the
function. You can then add terminals to the
picture to allow you to wire parts of the code
to other Vis.
Bring the VI components Together
Connector Panel
Block diagram
=
+
Front Panel
Math in LabView
I’ve already shown a few examples of basic math
in LabView. All there is to it is to wire inputs and
constant values to a math function, then wire the
output wherever it needs to go. Just remember
that LabView calculates the program left to right
along the wire, and it’s easy. All math functions
are in a tool palette that you can access by right
clicking the bloc diagram (this goes for all
functions, in either the block diagram or the front
panel).
Math Example- the Quadratic Equation
As you can see,
math isn’t too
hard to program
in LabView. Just
make sure to
pay attention to
the places
where a wire
crosses another
wire, because
those jumps can
cause some
confusion.
I branch several wires to stop the program from
having to do the same thing twice. This is more
to make it read easier than anything, but it may
save several computer cycles in complex code.
Boolean Logic and Case Structures
Boolean logic is true/false or on/off logic. This
logic type is invaluable towards the creation of
any complex code. Case structures are a tool that
you use to box in sections of code, then turn that
section on, off, or switch between different
functions with the same input/outputs. They can
be controlled by a Boolean value, or by a numeric
controller with cased designated to various
values.
True/False Case Statement
Here is an example of
using a true/false value to
control a case. Cases are
extremely useful any time
you have to switch
between two different
equations for one
input/output. Both
Boolean logic and case
statements have a near
infinite number of
possible applications
Creating a Robot Build
LabView has a pre-made basic program frame
for use in FIRST Robotics. LabView calls this
the FRC cRIO Robot Project, but I’m
referencing is as a robot build for short. If you
want to create one, the first thing to do is start
LabView. You’ll see a box labeled “New” in
the main window that comes up. Double click
on the option listed as “FRC cRIO Robot
Project.”
Configure the Build to Your Team
Once you double-click
on the said option, this
box will pop up. Go to
cRIO IP addrss, then
enter your team
number where xx.yy is.
For example, I’d make
it say 10.17.18.02,
while a member of
team 1234 would put
10.12.34.02
Robot Build VI Tree
Now you should have a box
similar to this. All of your
robot’s program will be in
one of the VI’s under team
code. I’m going to go over
the vi’s in that list that you’ll
need to make a basic
competition code. One VI
that is seen when you scroll
down further is Robot Main.vi
Robot Main.vi
Robot Main.vi is the first vi that your robot will
run when it boots up. The purpose of this vi is
to run the other vi’s in the proper sequence.
Because it will already be properly configured
for most anything that you will do, I highly
suggest that you don’t mess with the code
here if you don’t know exactly what you are
doing.
Begin.vi
This .vi is where you “open” all motors,
sensors, and control inputs (joysticks and
other such things). Opening one of these
objects in the code creates a RefNum for the
said object. The RefNum is the system that
the cRIO will use to keep track of which object
is connected to which data port, be it through
PWM or any other port. This program will
only run once.
The Basic Begin.vi
This is an example
of how you open
a motor and a
input, but
everything you
plan to use must
be opened here.
This is the actual
Begin.vi as it
comes. Right
now it opens a
joystick, the
camera, and a
motor pair for
later use.
Autonomous Independent.vi
Autonomous Independent (or auton for short)
is the code for the section of the game when
the robot will drive itself. Because of that, any
code here must be independent from driver
control. The basic auton .vi that comes with
FRC LabView gives a good example for how to
set up your auton, but the code is too large for
me to show here while making it easy to
follow. You’ll use the motors that you open in
Begin here as well as Teleop.
Teleop.vi
Teleop.vi is the section of code that runs while
the driver is in control of the robot. Here is
where you will want to use the joysticks that
you opened in begin.vi, along with the motors.
The joysticks output both an x and a y numeric
value, so you’ll need to associate one value
with throttle, then use the value to control a
motor with the set speed motor function.
The Built-in Teleop
Here we have the basic teleop.vi. This code will give you both
forward-back and directional control of your robot.
Disabled.vi
Whenever your robot is on but not in either
auton or teleop it will be in the disabled state.
While you can do whatever you need to here,
personally I recommend that you at least use
this state to reset all variables to whatever
they need to be for the beginning of teleop or
auton. We also make it display the outputs
from all of our sensors for hardware
diagnostic purposes.
Finished.vi
Finished.vi is the last segment of your code
that will run before you shut down your robot.
Here you should close anything that you
opened in begin.vi, as well as save any data
that you might want to save (like camera
images for calibration purposes). In all reality,
you don’t need to close the objects that you
already opened, as powering down your robot
will clear the memory. It is just good practice
to do so, to avoid memory leaks.
Questions?