cRio development language C/C++ vs LabView

[aldaeron]

Hi All,

Hope you are having a great summer. I wanted to get some advice from teams that have used LabView and C/C++ using the WindRiver.

A little background on our team is pertinent. We are a college Robotics Club at the Colorado School of Mines that sponsors an FRC team. In addition to FRC we have other projects of our own that the college students are working on.

I was recently working on a demo using an NXT and was trying to do it in LabView. Perhaps it was the lack of functions (VIs) but I was having a terrible time getting a decent program running. In particular I was having trouble keeping track of the cumulative angle a motor has turned thus far in the program. I downloaded RobotC and was able to be 10,000 times more productive and solve my problem with a single function call. To be fair, I have at least 10 years experience with text based languages and very little with LabView.

I am really trying not to be biased and I do see that LabView is powerful (a coworker at Northrop Grumman build an entire vibration controller and analyzer system using LabView). My concern is that LabView is a less useful skill in the real world generally speaking. Most coding is done in text based languages. LabView is a proprietary system that works on limited hardware. LabView does not work on an Arduino or a PIC or a CUDA device or any other Microcontroller (at least to my knowledge).

We are working on an improved curriculum for our students (high school and college) and my thought is that if we base it in C or C++ that they will learn more useful and transferable skills for later in life. I realize that using C/C++ may be a little more work for FIRST since there are a lot of existing useful VIs for simple things like basic motor control from a joystick. Something tells me someone has some open source code for these on their Team website.

I am very interested to hear opinions and thoughts, especially from teams which have tried both.

Thanks!

Matt

[Alan Anderson]

Originally Posted by aldaeron

My concern is that LabView is a less useful skill in the real world generally speaking. Most coding is done in text based languages.

This is probably true. However, using LabVIEW is not "coding". It is programming. One of LabVIEW's big positives is that it lets non-programmers do very sophisticated programming. I think that makes it a very useful skill in general.

Learning LabVIEW is often a struggle for experienced programmers. Many of them think it's because it's a graphical language instead of a text-based one, but I believe they are mistaken. Instead, what makes LabVIEW so difficult at first is the fact that it's a dataflow language rather than a procedural one. You can't really use typical C-style structured programming techniques effectively; you have to get used to a dataflow "way" of doing things. It doesn't take long, but it can take a Zen-like commitment to emptying your mind in order to make room for the new concepts. When I first needed to learn LabVIEW, I had to concentrate on ignoring what I thought I knew before I could get a good handle on what I needed to know instead.

[EricVanWyk]

Disclaimer: I work for National Instruments, and I am a developer on the LabVIEW Education Edition team.

LabVIEW was the 12th programming language I learned. It is one of 5 that I actively develop in. Bluntly put, there is no single language that is the best choice for all situations. Attempting to identify the language that will provide the most "useful and transferable skills for later in life" requires you to make huge assumptions on what your students will do with their life.

I try to make sure my students understand that tool selection is an important part of every job, and should be re-evaluated frequently. You can use a screwdriver on a nail, but it isn't pretty.


My honest opinion is that LabVIEW is frequently the correct tool choice for engineers, and less frequently is the correct tool choice for computer scientists. I was an R&D electrical engineer in my life before NI, and LV was extremely useful in creating and verifying prototype sensors and actuators.

[Greg McKaskle]

Like Eric, I work for NI on the LV team.

A clarification is that NXT is a very small subset of LV, and in fact there are pretty key language features related to data feedback that aren't present in NXT. That forces you to use variables which makes for pretty awkward expressions in a dataflow language. But still, 10,000 times more productive?

If you think the students are up for it, I encourage you to mix it up. Teach programming concepts by looking at it from different perspectives, different languages. Look at concepts rather than syntax. Look at the the robotic project and see if you can evaluate their success while allowing them to use different tools.

The goal was to build WPILib in different languages, but with similar structure to show to help teams discuss robotics problems and solutions in a more language agnostic way -- to realize that programming computers is way more than understanding syntax rules. Many of the programming languages I used when learning about programming are extinct or rare, but the concepts I learned are still valid. Whichever language you choose, see if you can expose the students to the alternates in some way and foster a compare-and-contrast approach so that all of the tools are seen in a broader light.

Greg McKaskle

[virtuald]

There's another alternative -- you can do it in python too. Python is such a fun language to code in, AND useful + easy to teach to kids too. Lots you can do with it.