Curiosity on why most teams choose LabView

[mswalker]

Our team used LabView last year and probably will this year (we are considering the Java toolkit.) The biggest benefit I saw was the ability to do realtime debugging by sampling the "wires" in Labview to see whether the system was doing what we thought it should. The graphical templates for each of the functions with identified inputs/outputs was also a plus. That helps the learning curve. We thought our autonomous was great. We found Labview capable of doing anything we thought of, partly because we had great help from NI Mentors!

[fritzdejongh]

We chose Labview for our 2009 rookie year after a control system workshop. With Labview, the virtual instruments (controls and indicators) are great, and the debugging is great. These seem to be the "killer apps" for Labview. There didn't seem to be anything comparable for C++. Did we get the wrong impression?

Also, with Labview it's very clear what's going on with parallel processing. You can write C like code blocks if you want for equations. And, you can certainly do hard things with it, for example, camera tracking was available in Labview. I can imagine that for advanced OO programming and AI that Java and C++ are much better, but for FRC I haven't heard of any "killer apps" you especially get with C++, it seems mainly to be a good choice if it's what you already know.

[jmanela]

The real time graphs and charts are invaluable as well. When testing our program, i also use the controls on the front panel, which makes making small adjustments very easy. (You don't have to stop the code, then re-hardcode something in your program and run it again (rinse, wash, and repeat).

[PhilBot]

Considering that the most usefull thing that you could do in auto last year was "drive straight for 5 seconds" and that anything beyond that was gravy, points to the fact that the teams that "had no auto" were probably dealing with more challenging issues than which language to use.

The fact that their robots moved at all in teleop is a good indication that whatever language they used was sufficient for them.

I was a died-in-the-wool C++ programmer untill I learned LabVIEW for Lunacy back in 2008. I wasn't looking forward to it, but I made the switch for two reasons...

1) The language was being used in FTC and FRC, so a programmer I trained in one, was usefull in the other.

2) It seemed that LabVIEW would be more usefull to a wider range of Engineers/Scientists, than say C++ which would be best for a computer science student.

If you're programming an air traffic control simulator, you're not going to use labview, but how many engineers do that sort of programming?

I'm dissapointed that last years, (and maybe this years) FRC game didn't provide more reward for great auto modes, but I didn't see the teams that wanted to use labVIEW to do cool programming being limited by their choice.

Case in point... our FTC robot has a good range of auto modes that we'll be running in Atlanta later this year (for the second time).

I also really like the graphical debugging capabilities of LabVIEW, and I'm not sure I'd like to go back to text based debugging.

Phil.

[Racer26]

1075 has always coded our robots in C/C++ (well, since 2004 anyway). I personally use LabVIEW for work, and I have a very love/hate relationship with it. It makes some difficult programming tasks very simple, but makes some simple tasks rather complex, and the whole tendency to create spaghetti really bugs me.

[Greg McKaskle]

In the interest of keeping things educational and inspirational, I'll continue the hijack just a bit longer to give a response to what makes something a programming language.

A programming language is a mathematical definition that distinguishes valid and invalid user programs, and defines the result of carrying out a sequence of instructions in a user program.

Normally tools such as compilers and runtime environment ,or interpreters are built so that a computer processor can behave according to the language constructs.

As an example, C is a language. gcc is a compiler tool for turning user text sequences into processor specific implementations of the user's C code.

Similarly, G is a graphical language, LabVIEW is a collection of tools for writing VI code or for compiling to a processor specific implementation.

Similarly, JAVA is a language, Squawk JVM is a runtime environment for executing JAVA bytecodes, and NetBeans is a collection of tools that support the JAVA language and allow it to target a specific JVM.

It doesn't actually take much to build a programming language. The math and theory to classify the inherent power of a program running on a processor was done in the '30s. If a language can build a Turing machine, it is capable of solving all computable problems and therefore can write any program, any tool, and is Turing Complete.

Classification of languages is somewhat less well defined. According to http://en.wikipedia.org/wiki/Domain-specific_language Excel and other spreadsheets are usually classified as domain specific. The VBScript which is hosted within Excel is general purpose.

From the computer science perspective, LabVIEW, Java, and C are all general purpose languages, but differ in the paradigms they support.

Other less mathematical definitions you can use to determine the power of a language include ...
Can you write a good game?
Can you write a compiler for your language or another language?
Are people willing to spend their time and money learning and using it?
Can you build a successful FRC robot programmed in that language?

The answer for all three FRC languages to all of these questions is yes.

One of the great things about FRC, IMO, is the exposure to different tools and techniques, different approaches, and different solutions. Opinions are fine and good, but don't let them obscure an opportunity to learn.

Greg McKaskle

[woodn1980]

Originally Posted by Greg McKaskle

In the interest of keeping things educational and inspirational, I'll continue the hijack just a bit longer to give a response to what makes something a programming language.

A programming language is a mathematical definition that distinguishes valid and invalid user programs, and defines the result of carrying out a sequence of instructions in a user program.

Normally tools such as compilers and runtime environment ,or interpreters are built so that a computer processor can behave according to the language constructs.

As an example, C is a language. gcc is a compiler tool for turning user text sequences into processor specific implementations of the user's C code.

Similarly, G is a graphical language, LabVIEW is a collection of tools for writing VI code or for compiling to a processor specific implementation.

Similarly, JAVA is a language, Squawk JVM is a runtime environment for executing JAVA bytecodes, and NetBeans is a collection of tools that support the JAVA language and allow it to target a specific JVM.

It doesn't actually take much to build a programming language. The math and theory to classify the inherent power of a program running on a processor was done in the '30s. If a language can build a Turing machine, it is capable of solving all computable problems and therefore can write any program, any tool, and is Turing Complete.

Classification of languages is somewhat less well defined. According to http://en.wikipedia.org/wiki/Domain-specific_language Excel and other spreadsheets are usually classified as domain specific. The VBScript which is hosted within Excel is general purpose.

From the computer science perspective, LabVIEW, Java, and C are all general purpose languages, but differ in the paradigms they support.

Other less mathematical definitions you can use to determine the power of a language include ...
Can you write a good game?
Can you write a compiler for your language or another language?
Are people willing to spend their time and money learning and using it?
Can you build a successful FRC robot programmed in that language?

The answer for all three FRC languages to all of these questions is yes.

One of the great things about FRC, IMO, is the exposure to different tools and techniques, different approaches, and different solutions. Opinions are fine and good, but don't let them obscure an opportunity to learn.

Greg McKaskle

What does that have to do with the topic (do you use labview and why)? If you want to fight about what makes a programming language, make another post, please.

[Mike Copioli]

Originally Posted by woodn1980

What does that have to do with the topic (do you use labview and why)? If you want to fight about what makes a programming language, make another post, please.

Ok, I see that you only have three total posts on CD so I will be as gentle as I can. Just to warn you: this post has nothing to do with the thread. Normally I would disengage such converse however I feel that it is important to clear a few things up.

Yes the topic of the thread is "Curiosity on why most teams choose LabView" (not "do you use labview and why" as you posted) First and foremost this is a forum that has been created to help inform individuals and teams about FIRST and robotics in general. Information is shared, discussed, and often times debated. I posted on topic originally. I stated the reasons we as a team use c/c++ vs. Labview. The reasons I stated have become the topic of constructive debate (not an argument) between myself, others, and the boys in blue. While I may not agree with their opinion I do respect it as such. The discussion was not what I consider "off topic" but rather to the heart of it. The reasons people DO NOT choose Labview are just as important as the reasons people DO. Sometimes they are more important, especially to the company that created the software, National Instruments. I suspect my opinion is one that they hear often. I also suspect that they would like to understand it more and educate others who may share my opinion. Since your comment was directed to the people that make Labview I will assume that you are not aware of these things. The world is not always sunshine and gummy bears, people disagree about things. Engineers disgree often. Its how we approach these disagreements that make the difference between argument and constructive debate, productivity and failure. Please consider these things and keep an open mind the next time you decide to become the self appointed thread police.

[Burmeister #279]

I apologize for not reading all 3 pages, but i had to skip some to be able to post this.

Last year I was the only programmer and my mentor had no experience in LabVIEW but we decided to take a chance and use it anyways. I am very glad I got the chance to use it however, we never were able to use it to its full potential, mainly due to time and manpower constraints. we were one of the robots at nationals that didn't do anything in autonomous for the first two matches simply because we couldn't figure it out. We eventually did, but not before I fell prey to death stares from four DANA mentors, three parents, 15 students (and a partridge in a pear tree) because our robot didn't move for two practice matches and the autonomous of the third. Our (more specifically, my) inexperience with the software as it pertains to FRC along with its perceived problems (download speed, learning curve, some other things) led us to change our environment C++ this year, and bring in four new members to the programming team. I felt it would not be the best for me personally, but it is definitely working for the team. Overall I'm glad I got the chance to use LabVIEW for the year, but it just didn't work for the team. I would definitely suggest that teams with programmers who have no experience with coding use LabVIEW. Maybe the team will return to LabVIEW as well next year when it can be seen as more stable by the team.

[dariusravenfall]

As the de facto programmer for the team i was "strongly encouraged" to use LABView, even though the more technically inclined people on the team have had more experience with Java and RobotC. O.o