[Danny Diaz]

For those of you who don't know me, I am a LabVIEW developer working for National Instruments on the LabVIEW Floor. Admittedly I do not develop features in the Core of LabVIEW, I am the owner/maintainer/developer of our x86-based RTOS used in LabVIEW Real-Time. Now that this has been said, I'll be frank with my own personal experiences - I use LabVIEW for several of my "personal" projects as well as in-house projects.

Learning LabVIEW from a C and Pascal based background was definitely not the most pleasant experience; I was a Co-Op student at GTRI and my boss threw LabVIEW and some IMAQ hardware on my desk and said, "Use this to track people walking under a camera." In a couple weeks I learned enough LabVIEW code and its syntax to do pretty much anything I wanted, but the hardest part about learning LabVIEW was getting out of the C mindset. I pulled my hair out trying to figure out how to lay down the code blocks in the correct format, tried to figure out what styles of structured programming work for different scenarios, and until I learned to use the tools that were in front of me built into the language I had a difficult time. It's no hidden secret - just like any other language, Dataflow languages like LabVIEW have a completely different "style" of programming and until you've been programming in it for a couple weeks it's going to be somewhat painful to transition.

I would declare myself an expert C programmer, and a proficient LabVIEW programmer. I can do things in LabVIEW in a couple clicks of a mouse that would take me an hour to do in a language such as C. On the flip-side I can perform some specific programming tasks in C in a few minutes that takes me an hour to do in LabVIEW. I can read a C program for an hour and understand everything about it, but I might spend twice as long on a piece of LabVIEW code and still not know all the nuances about it. Reading this you might say, "Well, then, the choice is clear - C is the better environment." I say you can make no such statement - it's impossible to make a qualified comparison between the two languages. And once you are experienced enough to think you can make a comparison, then you will realize there's this thing called LabVIEW Real-Time, and your assumptions about memory, diagrams, and performance just get thrown out the window!

LabVIEW Real-Time, which is what we use on our PXI, cFP, cRIO, and CVS hardware is optimized for the embedded space; what I mean here are targets with very little memory and slow processors. Of course, now that we've got LabVIEW Real-Time SMP we can handle multicore devices and do things that other RTOS systems can only drool at. Would you like to have an entirely dedicated core for a PID loop? Yeah, we can do that. Would you like to have native parallelism (native threading model)? Yeah, done. Would you like to be able to interact with your hardware on a low-level or high-level basis? Yeah, we've been doing it for years.

However, we are definitely in the same boat as C, JAVA, or other "traditional" languages - we're only as powerful as the guy writing the code. Just because you have a .c file or a .VI shouldn't cause you to think any differently about the quality of the engine being used to compile it or to run it. I say this because a lot of people had problems with the CMUCam application that was written and provided to teams. That code was written by a FIRST supporter and volunteer who had an extremely good piece of hardware in his hands when he wrote that code. However, he didn't account for the garbage that is sold really cheap these days, and didn't put in the required error detection and correction code that was eventually needed. Plus who would have guessed at the wide range of hardware issues that eventually came into play when dealing with the CMUCam? There's a whole forum on the problems people have had with that hardware when interfacing with LabVIEW, and several more forums on problems with interfacing with C!

Customers who use LabVIEW love LabVIEW for its inherent parallelism - its ability to natively be multi-threaded. That's a powerful tool, but one that you STILL have to understand what you're doing before you do it, even in C. Race conditions, synchronization, scheduling - all things you still have to deal with, even in LabVIEW.

For good or for bad, it's easy to find things you don't like about LabVIEW. It's also easy to find powerful things about LabVIEW that just cannot be done in languages other than LabVIEW. I could talk for hours on the benefits of LabVIEW, specifically relating to FIRST Robotics, and I can even give you some reasons why LabVIEW might not be the right language for FIRST. But unless you hear them all it's near impossible to make the determination that needs to be made eventually, which is the question you're asking - Should LabVIEW be a language that teams use to program their robots?

-Danny