Curiosity on why most teams choose LabView

Our team has used C++ on all of our robots ever since with started with Overdrive, and I have always wondered why it seems most teams choose LabView over C++ (Or Java in the case of this year.)

Is it experience? C++ seems daunting? Documentation for C++ isn’t as solid? Forced by Mentors?

I personally encourage all my fellow programmers to do C++ because I think it offers real industry experience, is more useful in the future, and you can develop faster with it. :smiley:


interesting. Our electronics/programming mentor strongly encouraged the team to use LabView for several reasons…among them that he knows something about it, another that he would like to be able to hire young engineers that know something about it (and he knows that it’s used in industry quite a bit). There are other reasons having to do with it’s capabilities too, something about virtual instruments or something :slight_smile:

If you are using C++ you are writing software that offers real industry experience.

If you are using Java you are writing software that offers real industry experience.

If you are using LabVIEW you are writing software that offers real industry experience.

The reason that my team is using LabView as opposed to C++ is because we feel that is is easier to teach the freshmen in a more visual based programing language.

I see no other advantage to it other than that.

I agree. Teaching code to new freshman is challenging, so LabView is easier to use in the long run. Also I remember a few years back, when our robot would not run with the c++ code, and we were up next(this was at a competition), We were saved because we ran LabView code, and that worked perfectly.

Its mostly preference. C++, Java and LabView both provide an enriching learning experience and it will help in the future. It is better to be comfortable with all, but it is not mandatory to use one or the other.

We used C++ last year and will probably use it this year as well because we didn’t have any experience with Labview, but already knew C++ really well. At a control system seminar before the kickoff last weekend, the presenter asked how many teams used C++. We were the only ones. We did try Labview for a couple of days, just to get some exposure to it.


LabView is an easier language to learn than C++, particularly for high school kids. Our mentors use LabView in the real world, so their learning curve is almost zero. NI has a lot of support if you just go and look for it. These three factors push us towards LabView, even though C++ would certainly be a viable option for us.

Labview makes it easy to debut programs. it also has a cleaner, more organized interface.

I wondered the same thing last year and started a thread on the subject myself.
In Atlanta last year, I couldn’t help but wonder what percentage of the (very many) robots that did nothing during autonomous were LabView robots.
I suspect most.

I wondered the same thing last year and started a thread on the subject myself.
In Atlanta last year, I couldn’t help but wonder what percentage of the (very many) robots that did nothing during autonomous were LabView robots.
I suspect most.

I can’t comment on these statistics, but I doubt that a poor autonomous routine has much to do with the tool. Since the urban challenge autonomous vehicle from Virginia Tech was programmed with a fair amount of LV by five MEs and a geologist and placed third, I really doubt that the tool is the issue.

Perhaps it has more to do with the team experience and capabilities.

Greg McKaskle

I didn’t cite any statistics – just personal observation and conjecture. :rolleyes:

And, while it may appear I blamed LabView for robots having no autonomous capabilities, in fact, I attribute the tendency to choose LabView as being most often motivated by lack of software experience and capability.

I think the inexperienced generally perceive LabView as an easy tool for doing easy stuff – which I admit it is – but (I think it is) a fundamentally inadequate tool for doing harder stuff.

I should also point out that 1629’s robot did do something useful during autonomous last year and was a LabView robot.

Sorry if it came off as if I was challenging your statement/observation. My post was trying to offer up some possible reasons.

As for LV being fundamentally inadequate, this is one of the reasons I mentioned the DARPA usage. I can’t claim that LV is the best programming language at any particular task, but I can point out customer successes.

If you want to dig deeper into the elements you feel are inadequate, I’ll participate.

Greg McKaskle

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!

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.

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

Ni hardware, ni software, good fit.
wendy holladay
team 1912

Our team uses Windriver primarily because our team has many students who are programmers. Programmers use programming languages. Labview is written in a programming language. I suspect that it was written in c/c++. If an individual desires to become a developer of products that use micro controllers they must know a programming language. If an individual desires to write desktop software they must learn a programming language. Having said that Labview is a great tool for people who are not programmers or have little knowledge of programming but need to create software that runs on a specific platform and need to do it fast. Gregs example highlights this. I personally enjoy the flexability that programming languages provide. They are universal allowing developers to write software for a variety of processor platforms. Although that the result may be the same, in some cases, whether you are using Labview or c/c++, to argue that one is better than the other is pointless because they are not the same thing.

The other programmer and I who have been around began coding on the IFI controller in C. Last year, with much persuasion on my part, we decided to try LabView.

I was perfectly okay with it, but the other programmer despised it for a number of reasons.

This year was the first year we have truly had new members interested in programming. Though the mentors and I pushed for labview, we decided to leave it up to a vote of the new programming team. For whatever reason, they decided to go with C++ (I attribute some of this to the fact that two of the members are currently in our school’s Computer Science class, which teaches in java, and thus provides text-based experience).

The idea behind the mentors’ and my thinking was that LabView would be easier to teach, easier for them to grasp onto quickly, and more comfortable as many of them use it in their workplace (Medtronic). Luckily one mentor has experience with C++, and the other programmer and I have our previous experience work off of.

Still not sure why the decision to use C++ was made, and we will have to see how it turns out.

That begs the question why Java was not selected if that’s what the students are learning!

Just FYI, LabVIEW is a programming language.