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 These two variables have their borders filled in. That shows that they are configured to be read from. The others are set up to have data written into them. The picture of a globe shows that it is a global variable The color of a variable denotes the type of data that it contains. Orange means numeric.

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.

Block diagram Front Panel Connector Panel + = Bring the VI components Together

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

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. Math Example- the Quadratic Equation

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. Boolean Logic and Case Structures

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 , while a member of team 1234 would put

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 the actual Begin.vi as it comes. Right now it opens a joystick, the camera, and a motor pair for later use. This is an example of how you open a motor and a input, but everything you plan to use must be opened here.

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?