Vous êtes sur la page 1sur 34

Advanced LabVIEW

for FTC
By Mike Turner
reydelsol4@hotmail.com
Software Mentor, Green Machine, 4318

If you only write down one


slide. This is that slide.
1. Use enumerated types more often.
2. Make subVIs/functional global variables for your specialized
functions.
3. State machines can improve your teleop program.
You can Google each of these terms, and the word LabVIEW,
and find all of this online.

Outline
Introduction
Me
FTC
LabVIEW

Building SubVIs
3 parts
Study Templates!
Functional Global Variable

State Machines
Teleop: Main Loop
Parallel processing

Tips toward good design


Default options for viewing LabVIEW
Organization of code

Introduction
Should I listen to Mike?

Introduction - Me
Mike Turner

Work for Johns Hopkins


LabVIEW user since 2000, version 5.0
Developed large-scale software
FLL judge in 2009
FTC software mentor 2010-2014 (Go Green Machine!)

What can you expect today?


1.

2.
3.

None of the advanced topics here will give you a better robot
than other teams.
I have more experience with LabVIEW than with NXT.
The tips here come from my interest in teaching LabVIEW
design patterns. The design patterns here have been
implemented by Green Machine in the past year to vastly
improve our performance.

Introduction - FTC
Green Machine has been using
LabVIEW every year at FTC.
The robots have become more
sophisticated, and complicated, every
year.
2013 - developed computer-assisted
teleop-mode software which
impressed judges and performed very
well.
2014 second place at Worlds

This improvement required 3 wellknown designs of LabVIEW


programming:
Modular Code
State Machines
Parallel Processing

Introduction - LabVIEW
LabVIEW is an integrated development environment (IDE).
LabVIEW uses the graphical programming language,
sometimes called G. LabVIEW is the biggest option out there
for graphical programmingso it is no wonder that everyone
refers to this code as LabVIEW code.
It is the code. These pictures do not symbolically represent
some textual code interpreted in the background.
It is more like C in that you can get down to the bits and
drivers at some level. Its object-oriented programming
follows in the footsteps of C++. There is a run-time engine
akin to the Java virtual machine.
The code follows a data-flow paradigm. One way to look at
classic LabVIEW design is component-oriented design.

Building SubVIs
Youve got a tank, and FTC/Tetrix toolkits make it do all sorts
of things. But the code is getting larger and uglierwe need
a plan

The Importance
Never Forget.

A bigVI
Can you see this?

How about if we zoom in?

Get a little closer

Notice that these are


not the default NXT
VIs!
They have separate
commands, control
individual parts, have
custom inputs, and
their own image/icon!

SubVIs in 3 parts
A VI is a Virtual Instrument. Every block of code you see is
a VI. And you can make your own. Your VIs are considered of
two types: the top-level VI, or a subVI.
SubVIs have 3 parts:
Front Panel:
Block Diagram:
Connector Panel:

defines the interface to the VI (either inputs


or User Interface)
this is where the logic of your code is stored
this defines how your code is called by other
VIs

Make subVIs to compact, and compartmentalize, your code


into useable/readable chunks.
Give them a recognizable icon so that reading the code is
easier later.

SubVIs in 3 parts

When to write a VI?


The quick answer: whenever the code starts to perform more
than one task.
The squishy answer: you learn with experience.
BUTkeep them organized with folders according to module.
Those modules serve to:
Keep your code neatly in one place
Provide VIs to interact with that part of your robot (e.g. Your
robot has an arm, and the arm eventually has 5 functions:
Initialize, Close, Grab Points, Wave, Stop Doing That.)

Add one VI to rule all the functions of your module: a case


structure with an enumerated type to perform the actions.
This is modularity, and encapsulation.

Sub VIs
A quick driver to rule them all

File > New > Virtual Instruments(.vi)

Templates can help you get started on some advanced ideas very quickly.
Study and learn from them!
Use them if you can

Templates!

Functional Global Variable


Does that sound fancy or what? Sowhat is it?
A functional global variable is one of the most common
designs for a VI ever used in LabVIEW. It is effectively a global
variable that prevents race conditions.
As a variable, it will:
Provide global reach
Pass data between parallel loops
Perform special functions on data (if you want)

Can be used as drivers


The functions become the driver actions

Functional Global Variable

Building a State
Machine
Alabama, Alaska, American Samoa, Arizona, Arkansas, California, Colorado, Connecticut, Delaware, District of
Columbia, Florida, Georgia, Guam, Hawaii, Idaho, Illinois, Indiana, Iowa, Kansas, Kentucky, Louisiana, Maine,
Maryland, Massachusetts, Michigan, Minnesota, Mississippi, Missouri, Montana, Nebraska, Nevada, New
Hampshire, New Jersey, New Mexico, New York, North Carolina, North Dakota, Northern Marianas Islands,
Ohio, Oklahoma, Oregon, Pennsylvania, Puerto Rico, Rhode Island, South Carolina, South Dakota, Tennessee,
Texas, Utah, Vermont, Virginia, Virgin Islands, Washington, West Virginia, Wisconsin, Wyoming

State Machine
Powerful concept to lay out the processes your robot will
follow.
Your design session could look like: flow chart on whiteboard
-> state machine on notebook -> code within LabVIEW.
Graphical programming has a neat way to create a State
Machine using all the parts of the functional global variable.
It fits nicely in the teleop loop to handle button presses
It is self documenting (when done right)
Can easily insert new states.

State Machine
This is a pure state machine, from VI Templates within
LabVIEW:

State Machine
This is where you would most likely place a state machine
within your teleop program:

State Machine
This is where you would most likely place a state machine
within your teleop program:

Id recommend placing the case structure for button handling


within the state machine case structure (the one on the right).

Parallel Processing
The right hand doesnt know what the left is doing.
It had better stop

Parallel Processing
This will get tricky.
When you have a state machine managing buttons, the state
machine should change:
When a button is pushed.
When a stop is called.

Parallel loops can run whole routines off to the side at the
push of a button.
Very powerful feature.
MUST stop when the program stops
Else your robot is out of control. Frankensteins lose points.

Parallel Processing

Parallel Processing
Use a parallel process to deploy the ramp.

Note the use of the NXT Flag.


This could also be your own FGV.

Tips toward good


design
They are not really tricks.

Enumerated Types
DO NOT DO NOT DO NOT Do This:

Enumerated Types
Do This:

Tips toward good design


Use labels wherever possible to document your code:
Sequence Structures
Loops
Floating Constants
Except this one

Wire labels

Typedef all of your clusters and enumerated types. That way,


all of your code will get the update everywhere.
When you add new variable inputs to clusters, or new
states/functions to your enumerated types.

Pay attention to color and labels of your icons. Try to make all
those that refer to the same component have a similar look.

Setup Environment
Under Project >> Options, select the following:
Default terminals to Required.
Auto-cleanup sends Controls to the left, and Indicators to the
right.
Choose now whether you will use the auto-tool or the tab button.
FOR THE REST OF YOUR LIFE.

Layout your directory structure according to how youve


mapped out your robot:
All arm code in the Arm directory
All file logging code in the File Logger directory
Your top-level programs floating in the top directory

Storage
How should I backup and save my code?
In the professional world, use some sort of code repository: SVN and
GIT can be used with LabVIEW. There are instructions online to
demonstrate how to compare and merge code within Tortoise SVN.
Repository might be overkill, and difficult to use from multiple
homes. Green Machine used DropBox with a lot of success last year.
Mentors, understand that DropBox is very chatty. It will tell you when
your team is working on code. So you can see when someone has
updated code (yay!), havent touched it in a while (what is my team
doing?), or are cramming until midnight the night before (What is my
team doing?!).

Bring at least two thumb drives to the matches.


1. Should have: the best code set you developed back home, a copy of
every installer and driver you ever EVER downloaded and installed. The
latest code on the robot.
2. Should have: the latest code you are quickly developing in the pits, the
actual code on the robot (these will change quickly), and enough space
to loan to other teams.
3. Ummyou might want a third if you are lending to other teams.

Vous aimerez peut-être aussi