General LabVIEW questions from a VERY new user

[ctccromer]

This is my first year programming on our Robotics Team and our previous programmer didn't teach me a thing. I do have prior experience in Basic, C++, Java, and my calculator (physics equations OP), but I saw LabVIEW for the first time about a weak ago. I'm trying to work my way through it slowly but surely and am finally making some good progress, so I'm using this thread for any general LabVIEW questions I get as I'm learning the language itself

Also: I'm using a Logitech F310 controller

My first question:
see this pic
I understand the part on the left, however the circled part on the right is still confusing to me.
I understand that the axis 1 (x) and axis 2 (y) relate to the left (i think) analog stick on my controller, and I also realize that in order to control the other (right side?) analog stick on my controller I need to make an axis 3 (x) and axis 4 (y) because the computer counts my entire controller as one big joystick.

HOWEVER, I *don't* understand why the axis wire from Joystick 1 branches off to a 2nd vi -- "Cluster to Array" and what goes on in that part of the branch. Why doesn't it JUST use the axes of the joystick? What cluster is it referring to?

The red circled part is un-edited from the starting code in Teleop.vi in a new cRIO Robot Project

Question 2:
Here is my current understanding of each file in a "cRIO Robot Project" Project file/folder that I made while taking notes. If I'm missing something important (or have a "?"), any extra insight would be really helpful

Team Code file
 
Begin.vi
-Initializes everything to be used later in the project
-Where motors and joysticks are "opened" i.e. initialized
-First .vi file in the project that runs
 
Autonomous Independent.vi
-Defines what happens in the pre-game, while the robot is running a pre-dertimined list of duties
 
Teleop.vi
-Defines what happens in the main and post-game, while the robot is being controlled from the Driver station
 
Test.vi
-?
 
Disabled.vi
-?
 
Vision Processing.vi
-?
-Assuming this is where I put stuff for the auto tracking system and the camera feed.  Anything else?
 
Periodic Tasks.vi
-?
 
Robot Global Data.vi
-?
-Assuming this is where I define global variables?  What separates global data here compared to joysticks and motors I open/initialize in the Begin.vi file and use throughout the project? (that seems pretty "global" to me)
 
Finish.vi
-un-initialize everything, basically the same (but opposite) as Begin.vi
-Where you close motors and joysticks, therefore rendering them disabled
-The last .vi file in the project that runs
 
Robot Main.vi  (NOT part of team code folderr)
-Where you deploy the LabVIEW project as a whole to the cRIO from
-? Any other use ?

[Mark McLeod]

While waiting for the picture to get posted...

See if any of this training stuff helps:

• The Tutorials on the Getting Started window
• The FRC examples from the Getting Started window -> Support ->Find FRC Examples...
• [FRC 2013] FRC Robot Framework Tutorial
• [FRC 2013] Test Mode Tutorial
• other tutorials at: [FRC 2013] Training Material and Resources
• Training stuff I use: http://team358.org/files/programming...2009-/LabVIEW/

Test.vi
- It's run from a special mode, You can use this to test new vi's for sensors or manipulators while avoiding running autonomous or Teleop.
This won't get run during a competition match, so you can leave partially tested code in here.

Disabled.vi
- stuff you want to have happen only while the robot is sitting disabled.

Periodic Tasks.vi
- stuff that runs in the background, like a compressor.

Robot Global Data.vi
- This is only one of the ways to pass information around in a LabVIEW program. There are other more common methods that you are already using, like the wires into a vi and the reference names we use for devices opened in Begin.
A typical example might be when code running in Periodic Tasks needs to pass information to Teleop to make some decision.


Robot Main.vi
-Stitches everything together. We only use it for running in debug mode.
The Run arrow doesn't deploy your program permanently to the robot, only temporarily. That lets you muck around with things, without risking the permanent program on the robot.

[propionate]

I am not 100% sure as to why the axes information is being put into another array, but it looks like unnecessary code to me. I haven't opened up LabVIEW 2013 yet - is this code part of the default project, or did you add it in from a tutorial online?

In regards to the different VI's, the guy above me did a good job. Perhaps a little clarification on Periodic Tasks. There are obviously a lot of functions going on in both autonomous and teleoperated mods, in relation to your robot. For example, you may be shooting frisbees in both modes or using some sensor. Rather than having duplicates of these particular functions in both the teleop and autonomous VI's, it is simpler to have them all in one place. That place is the Periodic Tasks VI, and it's nice because it runs in BOTH autonomous and teleop.

Once again, I haven't looked at the vision processing VI, but typically it just holds the code for getting the video input from the camera and sending it to the driver's station. You can add in vision tracking code here - usually we are given this (basically all the work is done for you) in a separate VI, but I'm not sure where it is. Some teams choose to do their vision tracking on a separate onboard computer, or send the video data to the driver's station and do the vision processing there.

Hope this helps somewhat.

[ctccromer]

Originally Posted by propionate

I am not 100% sure as to why the axes information is being put into another array, but it looks like unnecessary code to me. I haven't opened up LabVIEW 2013 yet - is this code part of the default project, or did you add it in from a tutorial online?

That was the actual code it starts with when you make a new cRIO project. I didn't edit it in any way, just moved some things around, screenshot, and edited in paint.
What is it even putting INTO an array? The axis values? If so, I'll just delete and ignore that part of the provided example code

Once again, I haven't looked at the vision processing VI, but typically it just holds the code for getting the video input from the camera and sending it to the driver's station. You can add in vision tracking code here - usually we are given this (basically all the work is done for you) in a separate VI, but I'm not sure where it is. Some teams choose to do their vision tracking on a separate onboard computer, or send the video data to the driver's station and do the vision processing there.

If there is a vi that already does this (or even has SOME code to get started like all the other vi's) I'd DEFINITELY get that. I'll look around for it

Thanks to both of you guys for the help. Right now I'm just trying to work my way through all of the example code provided by making a new cRIO project. As I slowly come to understand it all, I'm modifying it to fit my situation this year, like changing it from 2 joysticks each with 2 axes, to 1 joystick with 4 axes

Which brings me to my Third question:
When working with the axes of a joystick, how do I change the 3rd and 4th axes to "Axis 3 (x)" and "Axis 4 (y)" instead of the default "Axis 3 (Throttle)" and "Axis 4"? The reason I need to do this is because I'm using the controller linked in the OP, which LabVIEW picks up as ONE joystick, but it has 2 analog sticks, so the left will be Axes 1 and 2, and the right will be Axes 3 and 4.

Question 4:
So I know a cRIO Robot Project is the code you make, deploy to the cRIO, then run on a computer that's in communication with the cRIO.
But what would I need to use a Dashboard Project for? Would that just be for if I wanted to add another feature to the dashboard/driver station windows?

[RufflesRidge]

Originally Posted by ctccromer

That was the actual code it starts with when you make a new cRIO project. I didn't edit it in any way, just moved some things around, screenshot, and edited in paint.
What is it even putting INTO an array? The axis values? If so, I'll just delete and ignore that part of the provided example code

It is putting the axis values of the joystick into a SmartDashboard array which is sent to the dashboard.

If there is a vi that already does this (or even has SOME code to get started like all the other vi's) I'd DEFINITELY get that. I'll look around for it

Documentation on the Vision Processing example is here (I highly recommend reading all of it except the C++/Java code part, don't just skip to the LabVIEW code section): http://wpilib.screenstepslive.com/s/3120/m/8731

Which brings me to my Third question:
When working with the axes of a joystick, how do I change the 3rd and 4th axes to "Axis 3 (x)" and "Axis 4 (y)" instead of the default "Axis 3 (Throttle)" and "Axis 4"? The reason I need to do this is because I'm using the controller linked in the OP, which LabVIEW picks up as ONE joystick, but it has 2 analog sticks, so the left will be Axes 1 and 2, and the right will be Axes 3 and 4.

You can't easily change those labels, but the parenthetical is informative, it doesn't effect program operation. As a note, on many controllers (X-box controllers and at least some Logitech controllers) the second stick is not axis 3 and 4 because of things like the D-pad and/or analog triggers. You may have to experiment here, or put some indicators on the values for all the axes then run your program from your PC to figure out what maps to what

Question 4:
So I know a cRIO Robot Project is the code you make, deploy to the cRIO, then run on a computer that's in communication with the cRIO.
But what would I need to use a Dashboard Project for? Would that just be for if I wanted to add another feature to the dashboard/driver station windows?

Correct, a dashboard project is if you want to create a modified version of the dashboard program that runs on the PC. You cannot modify the Driver Station software.

[ctccromer]

I added the vision processing walkthrough to my favorites already and will look at that as soon as I get our camera up and running (have another thread about that)

And I was not aware about the axis thing. When I tested the buttons (booleans) today, the following parts of the controller did not register:
The left and right analog sticks obviously, the left and right triggers, and the d-pad.
Does it consider the left and right triggers as 1 axis each then?
And what does it consider the 8-way D-pad? My teacher and I were discussing it today and were kind of surprised it didnt show up as any of the 12 buttons. It seems like it would be a button/boolean value rather than a full axis

[Mark McLeod]

The triggers on game controllers are axis.
You can depress them halfway for half power.

[RufflesRidge]

Both directional pads and analog triggers usually show up in strange ways.

Analog triggers are typically mapped to a single axis for both. The axis will read 1 for 1 trigger fully depressed, -1 for the other and 0 for both. Partial depression of a single trigger will read a value between 0 and the extreme (1 or -1). Partial depression of both triggers will read something, or 0 (I recommend not having a control scheme that does this).

D-pads show up in different ways depending on the controller, but also typically map to an axis. This thread has a mapping for the F310 in it: http://www.chiefdelphi.com/forums/sh...ighlight=d-pad

[Greg McKaskle]

Most of the questions seem to have been answered, but as to the incomplete description of the various functions, the diagram of Robot Main contains a large string constant with just such a description.

If you really decide you need to change the name of a cluster element, you cast it to a different cluster. The Cast function looks like forcing a square peg through a round hole. As noted, this is largely a cosmetic thing. Names of elements serve as documentation and little else.

Greg McKaskle

[propionate]

Thank you to RufflesRidge for filling in my gaps. In regards to figuring out the mapping for any kind of controller, the simplest way I have found is to create indicators off of the clusters for the axes/buttons. Then run the program on a cRIO with the driver's station plugged in and the controller plugged into the driver's station. Start pressing analogue sticks and buttons, watching as the values change on your indicators. A quick way to document your joystick controls!

[ctccromer]

I'm trying to set up a program so that I can use one axis to simply turn a CIM motor. I did Open/Close the motor and Set the RefNumRegistry in Begin and Finish, and the attached picture is from Teleop.vi. I can't figure out how to attach the two parts together though

[RufflesRidge]

Try changing your motor Get Output VI to a Set Output VI. That should help with figuring out where to wire in the axis.

[Alan Anderson]

The input terminal on the Motor Set Output function that receives the motor speed value is called Output. That can be confusing if you're not thinking in the same way the writers of the function were.

[ctccromer]

I managed to get our drive system and D-Link wireless router set up! Now I'm moving on to our shooter system, which consists of two wheels (attached to two CIM Motors) and an arm to push the frisbees into the two wheels (we're THINKING a window motor, but not 100% sure yet)

The drive system was pretty easy since it was mostly done for me in the base code, but the shooter I have to do from scratch so I'm a little confused. I attached screenshots of my current begin.vi and teleop.vi. (not finish because that's straight-forward)

How exactly do I attach two CIM motors to the values put out by axis 3?

[Greg McKaskle]

One thing I notice is that you don't necessarily need to enable the safety for spinner motors. If you believe that your code needs to update the motors in order to be safe and in control, then leave the safety on and consider the rate at which you believe you need to update them. Otherwise turn the safety off.

I think the next thing for you to do is to retrieve the motors of the shooter by name, and connect the axis value to the value of both motor refnums.

Greg Mckaskle