Java. We all know it and it’s simple and clean.
Bingo.
If I jumped into C++, ignored classes, subroutines, and just tried to write everything out line-by-line, it would be ugly.
Just because you don’t understand or haven’t been taught how to write clean LabView code doesn’t mean it isn’t clean.
One basic rule: If your code gets bigger than one or two screen-widths, you’re getting too complicated and not splitting it up into Sub-VI’s efficiently.
There’s a whole host of other rules, but being that this is a Visual language, if you can’t tell from a glance what it’s doing, you’re probably doing it wrong.
Teams and CSA have been entering software data in the NI Parkway system. As of right now, there are 414 teams that have entered data. 42.5% LabVIEW, 37.4% Java, and 20% C++. See http://www.niparkway.com/frcts/reports
You can enter your data by going to http://niparkway.com, click on help out, choose an event that you are competing at, and then choosing your team.
330 is using Java for the robot, and LabVIEW for the dashboard / vision processing.
I recommend Java as the language to start with in FRC not only because it is the mandated language for the College Board AP Computer Science Class, but most first semester Algorithmic Design courses at major universities start students off with Java.
This. A lot of teams start out in labview, but don’t learn any good practices or put any thought into organization. Then they get bigger and start coding more advanced features, but still have the same coding practices. It just ends up a mess.
That was my team last year, big and complicated code with no thought to organization. We ended up moving to c++ for other reasons, but some of it was making a clean break; allowing our programming team to break out of their bad habits and start thinking about organization.
We are using LABView. But we are also using library’s and sub-directories to maintain organization. We currently have a library for each ‘component’ of the robot stored in its own sub-directory.
Chassis
Shooter
Climbing
Hanging
Intake
User Interface
File IO
Test
Each library is organized in the same manner:
<Library>Open.vi - called from Begin.vi
<Library>Close.vi - called from Finish.vi
<Library>Disable.vi - called from Disable.vi
<Library>ControlLoop.vi - called from Periodic Tasks.vi
Then there are <Library>“specific”.vi’s for library specific actions.
In addition, we are using the “Conditional Disable Symbol” to allow us to selectively include/exclude portions of the code depending on what we are looking to do. For example: our practice bot does not have any physical Intake or Hanging components, so they are disabled. No code related to the Intake or Hanging will execute and no errors are generated because the physical devices are not present.
And the code can be as clean as you want it to be. See attached screen shot.
UserIO.bmp (1.09 MB)
UserIO.bmp (1.09 MB)
The code I saw was incredibly complicated due to it being for some piece of random hardware. It was pretty messy. But you are correct, it does depend on the programmer and his/her practices. Our code is definitely a mess because nobody bothers to take the time to write it cleanly or clean it up after build season. Splitting projects into Sub-VIs (much like splitting a C++ project into different source and header files) would make things much neater. I think LabVIEW would be a nice thing to know, but I don’t see myself using it for something as relatively simple as the robot code.
Alex Brinister
On team 842 we used to use Labview for our FRC robot but this year we switched to Java. For our autonomous underwater robot though, we use C# with Visual Studio.
C# >= Java
We have used LabView since 2009, but we switched to C++ this year since our lead programmer is more proficient in C++. All of our vision code is also written in C++. #cppforlife
Lol C#. System.IO.FRC.Robot.Controls.NI.CRIO.Motors.Talon.Commands.Speed.CIM.SetPWM()
1675 was:
C: 2005-2008
C++: 2009-2011
Java: 2012-present
I enjoy the fast set-up time for an FRC java environment, plus the kids use Java in AP.
Java and C++ are similar enough to make transition both easy and problematic.
The worst issue I see for a Java programmer using C++ is knowing how/when to use pointers and pointer syntax, but my students coming from Java classes in high school do quite well with the C++ environment.
Team 230 uses C++ and we have for the last 5 years with the cRIO… we used C before that. We basically use C++ because it is syntactically very similar to Java which many of the students are exposed to in programming classes at school. But we go the extra step to C++ because it is somewhat better supported (especially in the earlier years of the cRIO) and our programming mentor (me :D) is more familiar with C++. This makes it more feasible for the mentor to help the students solve their issues instead of scratching their heads.
^ Really… is that really how the C# code would look??? LOL
For the benefit of LV discussion in the thread, our 2012 code directory had >200 files, mostly .vi, .ctl, and .bee
Our 2013 code is a bit slimmer at only ~170 files, with a similar mix. This includes BuzzLib, BeeScript, and a total rewrite of the WPIlib (although the new library is only ~14 files).
That’s about a file per C function, struct, or enum, because that’s exactly what it is. If we wrote code in C, each of the ~10 organizational folders would likely be a single code/header file pair (although each auton would get its own file).
We tend to use a lot of structures and enums, since we only pass data through VI connectors (no globals, no accessor/storage VIs).
Aside from FRC robot code, I prefer clean C code.
Heh probably. C# has classes and subclasses for everything.
And everything is capitalized, even method names 
Otherwise, C# and I are cool.
Don’t get me too excited for C#/.NET support. I’d force our programming team to switch right away. 
using edu.wpi.first.wpilibcsharp.SimpleRobot;
namespace edu.wpi.first.wpilibcsharp.templates
{
public class CSharpRobot : SimpleRobot
{
// no guts no glory
}
}
We use Java, and it looks like a majority of teams do too. Cool, we always thought we were a minority at competitions!
Historically Team 2704 used Labview. Going into the 2012-13 season, the team decided that for the 2012-13 season, they would program the robot in Labview, but a few students would pilot C++.
At any given time, the team has limited FRC robots (usually 0 or 1) to train programmers. Earlier, the team had developed a Labview training program using Mindstorms NXT robots. It was decided to try this route with C++ also.
The team put together a training curriculum using: Mindstorms NXT robots. The training curriculum was hugely successful. All training on the NXT was directly applicable to FRC programming, and the 2012-13 robot was ultimately programmed with C++.
The robot is much more responsive with C++ (we did program with both C++ and Labview).
We have shared the curriculum on www.firstplusplus.com for those looking to learn C++ for FRC. (Note: this is the first iteration of the curriculum. It is still being developed.)
Please check out www.firstplusplus.com and provide feedback.
I had been under the impression that less teams were using Java. (Just based on what I had seen at competitions.) It’s hard to say either way though as either pool would be biased because not every team goes to the Pittsburgh Regional and not FRC programmer is a member of Chief Delphi.
Both of my teams over the years used C++; 562 used it because most of our senior programmers knew it. 3623 has used it because our mentors (myself included) are accustomed to C++.