Pros and cons of using Labview?

[tahmid0517]

Hi there. I'm not a programmer and my team doesn't have the strongest of programming teams. There's one programmer who did all our programming this year and he's going to be graduating this year. There's 2 guys left on our programming team, but they're not as dedicated or as experienced as the guy who's graduating. Our team currently uses Java and our programmers are the only ones who know how to program in Java. I was wondering if switching to Labview next year might be a good idea since it seems like it 's a good fit for people with little to no programming experience. For all of you that have experience with Labview, what are the pros and cons are of using Labview. And is it a language that's meant more for inexperienced teams or do successful and experienced teams use it as well ?

If we wanted to get more people on the programming team who have no programming experience, would Labview be a good idea? Next year, only 2 of our members will know Java and next year will be their last year. Or would it be easier for new programmers to just learn Java.

[Sperkowsky]

If you need any help with programming contact me and I'll give you to our programing lead. He's a. Genius with lab view and Java I'm general.

As for my experience with lab view I loved it other then that it take a a decent amount of resources when we restart it. (we have a crappy laptop). We are an inexperienced team but our programming mentor is. Fantastic.

My email is Sperkowsky@gmail.com if you prefer that.

[GeeTwo]

If you are carrying over any Java experience, it's probably best to carry on with it.

3946 has been using Java from the beginning. We selected it because it is the most generally useful of the languages available once people leave FRC. Unless you do virtual instrumentation on NI hardware, odds are that you will never find another use for LabView. Java (and C++) are useful in a wide variety of fields. Of the two, we selected Java because it does have a lot of "safeties" in its implementation of object orientation; troubleshooting a bit of bad pointer arithmetic in C++ can drive experienced programmers nuts. Java and C++ are also friendlier on the mentors' eyes.

[Alan Anderson]

LabVIEW is mostly "a good fit for people with little to no programming experience" because it's harder to learn if you already think you know how to program. Almost everyone starts out learning to program using a procedural language like Java or Python. Some get into object-oriented programming and understand it well. But LabVIEW is different. It's a dataflow language, where the only thing keeping every little piece of the program from running all at once is the availability of the data each piece requires. If the only programming you know is the kind where execution happens in linear fashion down the page of text, LabVIEW is difficult to approach.

LabVIEW is just as easy to learn as any other first programming language. I personally think it's easier to write LabVIEW code, because syntax is enforced by the nature of the data flowing into and out of nodes, and typing errors are essentially nonexistent. I also find that it's easier to read, because you can get a good impression of what a section of code does by glancing at it as a whole rather than having to read the details of each line. But that's my personal experience, not a law of nature.

One big point in favor of LabVIEW is that it's the language used by the company which provides the robot control system.

Another plus for LabVIEW, at least in my experience, is that it's possible to have multiple people looking at the screen while someone edits the code, and everyone is likely to be able to follow along without getting lost. I think it's a very good environment for one or two "master" programmers and a collection of "apprentices".

Graphically drawing a program is perhaps not as quick as typing text if you are a great typist who knows exactly what you are doing. But if you aren't the hypothetical amazing C++ programmer, the power available to you in LabVIEW is likely to let you program as fast as you need to.

When developing or debugging, being able to run a program "interactively" with full access to the data values and any front-panel controls and indicators is a huge bonus for LabVIEW.

The few cons I can think of are:
* Building code takes a lot longer in LabVIEW than in C++ or Java.
* Source code isn't text, so it's not as convenient to discuss it in email or a web forum.
* Version control and file conflict resolution isn't as straightforward for a graphical language as it is for a text-based one.

[Greg McKaskle]

Picking your programming tools and language can be done in many ways.

What I'd recommend you do is to take advantage of the programmer while they are still there. Sit down with them and look at the introductory code with them and let them share their knowledge. You will probably also want to look at the current robot code with them, but ask them to do it in a way that isn't overwhelming.

Then I'd recommend that you open some LabVIEW examples or the initial framework code and use it in the simulator, or try to reprogram this year's robot using it.

If possible, do these tasks with any mentor or teacher who may be helping next year. If there isn't a deadline, other than graduation, you can take your time and explore things a bit. Also, feel free to ask questions on the forum if/when they come up.

Then make a decision based on your findings. Teams are successful with all three languages, and your pro/con question is a good way to start, but ultimately, you and your fellow programmers need to decide what is best for your team.

Greg McKaskle

[MrRoboSteve]

Originally Posted by Alan Anderson

* Building code takes a lot longer in LabVIEW than in C++ or Java.

Sadly, the C++ toolchain might have caught up with LabView in this department in 2015, particularly on full builds.

IMO the most important factor in selecting a language is finding a mentor who is an experienced programmer, who either knows or is willing to learn the language to help you.

There's nothing about any of the three supported languages that makes a better / worse program.

[Ichlieberoboter]

That's been our issue. We are a super small team and our one programmer graduated last year. I am a freshman and I took over as head/only programmer. I used Labview and it wasn't too bad. I got accustomed to it fairly quickly via experimentation and a lot of YouTube.

[Skyehawk]

I was lead programmer on 876 fro three years, Initially I wanted to switch to java, because I have NO use for Labview outside of FRC, but Labview is the far superior language to throw at people who have never coded before. I am a big advocator of the "get your feet wet, ask questions later" method of introducing someone to programming.
As mentioned above it is really difficult to get a syntax error in Labview, the most common problem is forgetting to connect a wire. Labview does have it's pitfalls, such as compilation time, complex data management, etc., but I think the Pros play in its favor for a small team; the ability to follow code easier than a text based language makes it perfect for pretty much everyone. Just remember, on windows, THE SNIPPING TOOL IS YOUR FRIEND.

I wish you luck on any endeavors, whether they be Labview based or not,
-Skye

[Orthofort]

Coming from a team that just switched to Java from LabVIEW, I have experience using both with FRC.

I will flat out say that in your situation, I recommend using LabVIEW. It is, as everyone else has said, far better for those with less experience in programming, and along the same token, there is a lot larger of a support network for LabVIEW for FRC specific support, and in my opinion LabVIEW is better at helping you itself, and the FRC code is much better documented under LabVIEW than Java or C++.

Our team specifically switched to Java because we tend to get more people with experience in programming Java because of our school district, and it worked better for us. The decision should always be made holistically to your specific team, but from what you're saying, I would recommend LabVIEW.

In addition to what everyone else has said, I'd like to add the personal note that if you get a programmer who does have decent experience with a text-based language, it can be difficult bordering on infuriating to switch to LabVIEW, a big reason why we switched. Java and C++ are probably also more applicable to the 'real world' past FRC, but there are jobs out there that do use LabVIEW. We've even had a mentor that used LabVIEW extensively in his job.

One thing I haven't seen others say that I think is a big factor that you might want to consider is that Java and C++ can now utilize RobotBuilder, which is extremely helpful for getting a skeleton of your code, and getting a project started without actually writing anything. You can do a lot of stuff with their command structure that makes it pretty easy to get a working project.

[mman1506]

Usability aside support for Labview in Ontario is almost zero. When we ran into an issue with Labview at Waterloo in 2013 we quickly found out that we were the only ones at our regional who used it. After searching around the only person who was able to provide help was 1114's programmer who had decided to learn all of the FRC languages for fun.

We switched away from Labview in 2014 and we have never looked back. From my experience using both I've found that Java is much easier to teach to students without a programming background.

[alex.lew]

Originally Posted by Alan Anderson

One big point in favor of LabVIEW is that it's the language used by the company which provides the robot control system.

Another plus for LabVIEW, at least in my experience, is that it's possible to have multiple people looking at the screen while someone edits the code, and everyone is likely to be able to follow along without getting lost. I think it's a very good environment for one or two "master" programmers and a collection of "apprentices".

...

When developing or debugging, being able to run a program "interactively" with full access to the data values and any front-panel controls and indicators is a huge bonus for LabVIEW.

Agree with both of these points. 1912 switched to LV from C++ for the first reason. We only wanted to contact 1 supplier for our (inevitable) controls problems. Haven't looked back since, the support from NI is outstanding.

Additionally, several mentors use LV everyday at work, Stennis Space Center. They've even coordinated "LabVIEW for FRC Mentors" workshops. So there are definitely applications for LV in the workplace.

The fact that you can have an indicator for, say, encoder values is extremely helpful. In 2012 and 2013, we ran a PID loop for our shooter wheel. Tuning the PID loop would have taken a lot longer without indicators.

Before this season, I believe LabVIEW was the only option that had a FIRST-provided simulator. I'm not sure what the feedback for FRCSim has been this year, but the LV simulator was incredibly useful for having new students play around with. We beta-tested that feature several season ago and instantly loved it - especially now that the simulator is the current game field.

[BitTwiddler]

While I am a big advocate of LabView, especially for teaching to beginning programmers I do have a couple of issues with it.

1. It will eat your computer's resources alive. Everywhere you look you see LV's big fat footprint. Plan on dedicating a machine just for LabView programming.

2. It is proprietary and it is not cheap. Once your license expires you'll have to pony up some serious money to continue to use it. It will never replace Java or C++ in popularity because of this one issue.

These two issues are the biggest cons in my book.

[aeastet]

Originally Posted by BitTwiddler

While I am a big advocate of LabView, especially for teaching to beginning programmers I do have a couple of issues with it.

1. It will eat your computer's resources alive. Everywhere you look you see LV's big fat footprint. Plan on dedicating a machine just for LabView programming.

2. It is proprietary and it is not cheap. Once your license expires you'll have to pony up some serious money to continue to use it. It will never replace Java or C++ in popularity because of this one issue.

These two issues are the biggest cons in my book.

OK let me start by saying that I use LabVIEW every day in my job. I have been using LabVIEW to program for over 15 years now. So I would like to address this question from someone that started using LabVIEW as a beginner and is now a very competent programmer.

LabVIEW is great to start with. The troubleshooting and program analysis is outstanding. You can see the flow of the program what is executing and what numbers you are getting everywhere. The problem with Labview is that it is so easy to get started that most people never learn the proper way to program using LabVIEW. You can get yourself into trouble quickly with resource management and race or chance conditions if you are not careful and follow proper programming techniques.

In the quote above I would say that I have extremely complicated programs running on many different systems. They do not use many resources for the computer that they are running after the install. The only resource that will need space is the instillation of the software itself. If the computer resources are maxed out then you are probably doing something wrong with the code.

The second comment about being expensive is true. It does cost a lot of money for LabVIEW. If you use it everyday, like I do, then it will save a lot of time with development. Things that you would have to code in C++ and Java are already done for you so you are paying for that. I do program in C++ as well so I have that side of programming. Learning C++ helped me understand some of what is going on inside of LabVIEW. If I bought tool kits for C++ or Java that did everything that LabVIEW can do for you out of the box then it would be expensive too.

You will hit limitations with LabVIEW. I have never hit one with programming our robot. We have done Vision and many of the more complex tasks that are required of a really good team and I have never maxed out the performance of the roboRIO. If you learn to do it right then you will not have problems with LabVIEW. It is easy to show someone what you are doing. I have taught many students to program with LabVIEW over the years (fifth year as a mentor)and if you asked them I think they would tell you that reusable code that I can do with LabVIEW makes their lives easier. Teaching them about state machines and producer consumer loops, data flow and to minimize the use of local variables.

If you ever need help with LabVIEW you just let me know. I would be happy to help.

Tim

[wt200999]

Originally Posted by BitTwiddler

2. It is proprietary and it is not cheap. Once your license expires you'll have to pony up some serious money to continue to use it. It will never replace Java or C++ in popularity because of this one issue.

Originally Posted by aeastet

The second comment about being expensive is true. It does cost a lot of money for LabVIEW.

The price outside of commercial use has been one of my main issues with LabVIEW, however as of quite recently NI released a Home Edition of LabVIEW 2014 for $50! While yes this is quite a bit more than a free C/C++ or Java environment, its a huge step in the right direction for making it affordable for hobbyists.

[aeastet]

Another thing that was said here was that it was hard to get help with LabVIEW. I would ask you to find s forum where you get help faster than this forum. You post your code and someone will help right away. Code snippits are your friend.

http://forums.ni.com/t5/LabVIEW/bd-p/170

I have been a part of this forum for many years now. Most of the time the response is immediate. You can post your code and get help. Almost everyone is a volunteer that programs with LabVIEW for a living.