Opinions wanted: LabView-based controller?

[Dave Flowerday]

Many of you probably saw the rumor that was posted in another thread that the new RC was to be an NI device that is programmed using LabView. The poster later recanted that statement, but it brings up an interesting topic.

I know there are already several other threads on the new RC, but I'd like to discuss something more specific in this thread. I am curious about how would you here on CD would feel about an RC that required the use of LabView to program it. I have a strong opinion on this subject myself, but I won't go in to that right now. I would, however, like to know how the rest of the FIRST community would feel about that option (well, at least how the "people-who-post-on-CD" community feels anyway).

Tell us what you think the pros and cons are, tell us why you like or dislike the idea. Tell us if you have first-hand experience with LabView or if you're basing your opinions on second-hand information or just what you think you know about it (it's OK if you don't have experience with it, but I think it's important to note what your opinions are based on).

Anyway, I hope this might generate some interesting conversation.

[Alan Anderson]

My opinion: Bleah. That's a sticking-out-tongue bleah, not a shrugging-shoulders one.

LabView is useful, powerful, and appropriate in some contexts. In my opinion, a project with thousands of programmers creating thousands of individual programs with many shared features is not one of those contexts. Learning the LabView "style" of programming does not carry over well to other development environments (and vice versa).

If FRC were to start providing LabView-based robot control systems, I think the pool of helpful programming mentors would shrink drastically. Even with experienced programmers standing by to help, it's a lot easier to do text-based support on a forum like Chief Delphi than it would be to try to assist someone having problems with a graphical programming language that hides details behind separate layers of views.

(I have programmed using LabView, and I use LabView-developed systems regularly.)

[jtdowney]

I have never used LabView for development, however in my opinion a move away from C would be a big mistake. The biggest pro of using C is that it is the one language you will find in almost every technical industry and University engineering program.

[Qbranch]

I have experience in LabVIEW... for better or worse. I guess i'll just start out with some pro's cons for the language itself:

Pros: Insane amount of conenctivity options, rapid software prototyping, many built in Signal Processing filters and functions, little learning curve for very basic operations, graphical, great quick easy operator control pannels, easy integration of multiple high complexity sensing systems, C code snippets can be used, LabVIEW vi's can be compiled to ANSI standard dll's, can handle and optimize-compile for multiprocessor/multicore and 64bit processors, can compile to FPGAs, compatible with SolidWorks CosmosMOTION in-pc design mechatronics/programming full simulation system (run your code in a purely virtual full physical simulation environment)

Cons: MEMORY INEFFICIENT (all variables passed by value), LabVIEW code runs at decent speed but isn't the most efficient, code nearly impossible to document, debug difficult, code appears extremely complex, some fundamental features missing (ex, poor array functions), no zoom on editor (it sounds trivial but just try 'writing' code for a while), complex functions have large learning curve, debug sometimes difficult.

Now that's just LabVIEW.... NI hardware is AMAZING! I usually avoid labview but for some functions speed is not a huge issue, and the picture (code) you make isn't way too hard to read, then i sometimes use it favoring speed of development over execution efficiency and algorithmic power.

NI has a gigantic array of hardware... all of which is expensive for FIRST robot type price ranges and probably overkill... but wow... the thought of having a PXI chassis on a robot with an XPe computer card.... whoooo hoo. For those of you who arent familiar, you really should check out NI's hardware products... I've experience with their M-cards (PXI I/O cards), NI-Motion cards (fantastic performance! but $$$$$$), CAN-interface cards, Vision systems (check out VBAI) and others.... all of them have performed with exemplary performance.

So, in my opinion, would it be cool to have a PXI or something of the sort NI hardware based controller? ABSOLUTELY! (provided we got hefty discounts)

Would I like to see LabVIEW show up on a FIRST controller? Not so much... I don't mind if its an option, but I'd still like to be able to write C, even if the C code runs within an NI framework... as long as the C code you can write is not in any way restricted (i.e. can still run arrays and such)

What do you all think....

-q

[Mark Pierce]

I'd much prefer to stick with text based programming for the same reasons already mentioned by others. I can see some benefits to the Labview environment and done right it can work.

However, getting it "done right" can be tricky. My FIRST Labview experiences have not made a good impression. This applies to both trying to get the Camera code working a couple of years ago and trying to do a data acquisition project last year. I'll admit to not doing much of the tutorials, but a lot of my concerns really aren't covered in the ones I did try.

1. Installation instructions have been poor or missing, even with correct instructions it takes a long time to install. We usually have four classroom computers plus at least two mentor or loaner laptops.
2. Sample applications have been buggy and cumbersome. (Think version 1 of CMUCam application)
3. The environment likes to start up device drivers for devices when you start the system. I still get occassional error messages from some LV process while shutting down my laptop.
4. LabView also likes to go out to the network when you start it. When I'm programming for FIRST, I hardly ever have a network connection. I think I eventually figured out how to turn this off.
5. LabView (or at least the applications I've tried) seem to require a lot nicer laptop than the hand-me-down school laptops we've used.

I'm sure we can work with it, but as I've said elsewhere, the sooner we know what we're working with the better. This would be a major change, not just a rehashing the current code. Labview based development will call for an entire new set of training resources. The demo at Kettering made it look more promising than I would have thought, but the details are key to making it work.

[Danny Diaz]

Originally Posted by Mark Pierce

My FIRST Labview experiences have not made a good impression.

Sorry to hear this.

Installation instructions have been poor or missing, even with correct instructions it takes a long time to install. We usually have four classroom computers plus at least two mentor or loaner laptops.

Yup. There's a lot of code and we support more hardware than anything else you've ever installed on your computer. It's the nature of the beast.

Sample applications have been buggy and cumbersome. (Think version 1 of CMUCam application)

Please refer to my previous post.

The environment likes to start up device drivers for devices when you start the system. I still get occassional error messages from some LV process while shutting down my laptop.

Because Windows is, well, Windows, there are a lot of services we have to install in order to be able to support the plug-and-play nature of some of our devices.

LabView also likes to go out to the network when you start it. When I'm programming for FIRST, I hardly ever have a network connection. I think I eventually figured out how to turn this off.

Never heard of this. There is no reason LabVIEW needs to go to the network, it does not call home unless you ask it to during the initial licensing phase. It does create sockets and interact with the networking stack in your computer for its own internal processing (so your Windows Firewall may bark), but there's no reason for it to go to the internet or scan a network.

LabView (or at least the applications I've tried) seem to require a lot nicer laptop than the hand-me-down school laptops we've used.

For running LabVIEW applications on the laptop, yeah, you're right. But you would never use straight-up LabVIEW on an embedded target, you'd use one of our flavors of LabVIEW Real-Time.

I'm sure we can work with it, but as I've said elsewhere, the sooner we know what we're working with the better. This would be a major change, not just a rehashing the current code. Labview based development will call for an entire new set of training resources. The demo at Kettering made it look more promising than I would have thought, but the details are key to making it work.

I think everyone is on edge waiting to see what's coming down the line.

-Danny

[Dave Flowerday]

Originally Posted by Danny Diaz

There's a lot of code and we support more hardware than anything else you've ever installed on your computer. It's the nature of the beast.

Please refer to my previous post.

Personally I'll bet it's more like "It's the nature of the design decisions that were made." I've seen and worked on very complicated software, and I refuse to accept that software which is big and complicated by definition must be buggy.

On the other hand, if it is true that big, complicated things like LabView are inherently buggy then I'd cite that as a good reason not to use it.

[Danny Diaz]

Originally Posted by Dave Flowerday

Personally I'll bet it's more like "It's the nature of the design decisions that were made." I've seen and worked on very complicated software, and I refuse to accept that software which is big and complicated by definition must be buggy.

I'm sorry, you must be mistaken. My 2 statements you quoted were not in any way related. In your quote, you quoted two of my replies. In the first reply I was referring to the "taking a lot of time to install" when I spoke of the nature of the beast. In my second reply (about the buggy software) I was referring to my longer post where I spoke about the problems with the application in question. After reading both posts I have made to this thread (previous to this one) I'm sure you will realize the misunderstanding.

-Danny

[JBotAlan]

While a LabVIEW-based controller would run fine, there are teams out there programming on a 350MHz laptop with a 6GB hard drive with 128MB of RAM. Try installing, let alone running, LabVIEW on that. And LabVIEW does NOT need to install any service on my machine (a good program does not rely on them), or start anything up at startup, yet it was trying to start at least 3 processes (which I promptly disabled) at startup.

I also find that documentation on LabVIEW is extremely sparse. For C, there are *tons* of tutorials. Not so for LabVIEW. Mostly because it is so expensive.

At least before today, the MCC18 compiler could be run on any system, even Linux, through WINE. I'm 99.99% sure LabVIEW won't so as well in an emulator. What about alternate OS programmers?

I'm tired of proprietary software. I'd like to see IFI or whoever designs the new controller to *completely* open-source the whole thing. Schematics, master code, compiler, IDE, etc. That would be really nice.

If LabVIEW was quite a bit less beefy, then maybe I might go for it. However, I think that many programmers would be disabled by LabVIEW--it wouldn't install on their systems, or would crash. It's fine for industries that can afford new computers, but we are not such an industry.

It's not that I'm trying to put down LabVIEW; I believe it has applications in other areas (signal processing and simulation are two areas that come to mind) but I don't see it as suitable for FIRST.

Maybe I'm just biased by all of the nice open-source projects I've seen, but that's my 2 cents on this topic.

JBot

[Adam Y.]

# Installation instructions have been poor or missing, even with correct instructions it takes a long time to install. We usually have four classroom computers plus at least two mentor or loaner laptops.

That is right. I don't remember how long it specifically takes to install LabView but there a significant amount of other programs that you install in a full installation. I also don't remember needing instructions though.

At least before today, the MCC18 compiler could be run on any system, even Linux, through WINE. I'm 99.99% sure LabVIEW won't so as well in an emulator. What about alternate OS programmers?

Labview can be run on all systems. In fact it would be a step up from running an emulator. It stems from the fact that LabView was originally designed on a Mac.

I'm tired of proprietary software. I'd like to see IFI or whoever designs the new controller to *completely* open-source the whole thing. Schematics, master code, compiler, IDE, etc. That would be really nice.

The problem is that you would be severely limiting your options with such a constraint. There are very little microcontrollers that have open source compilers. I'm all for using LabView if I can be shown it's a good choice for this application. I'm certainly convinced that it's an excellent choice for experimentation and data collection. I can collect data from many different instruments with a minimal amount of effort.

[JBotAlan]

Originally Posted by Adam Y.

That is right. I don't remember how long it specifically takes to install LabView but there a significant amount of other programs that you install in a full installation. I also don't remember needing instructions though.

Labview can be run on all systems. In fact it would be a step up from running an emulator. It stems from the fact that LabView was originally designed on a Mac.

Umm...FIRST shipped the WINDOWS version of LabVIEW. AFAIK the other OS versions have to be ordered separately and are separate licenses. Those licenses are not cheap.

The problem is that you would be severely limiting your options with such a constraint. There are very little microcontrollers that have open source compilers. I'm all for using LabView if I can be shown it's a good choice for this application. I'm certainly convinced that it's an excellent choice for experimentation and data collection.

I am fairly convinced it is not a good choice for the reasons I outlined in the post you responded to.

It would be fun to experiment, but when all is said and done, I am much happier coding in C.

JBot

[Danny Diaz]

Originally Posted by JBotAlan

Umm...FIRST shipped the WINDOWS version of LabVIEW. AFAIK the other OS versions have to be ordered separately and are separate licenses. Those licenses are not cheap.

Yeah, you're right, if you walked to your local sales office and tried to pick up a copy of LabVIEW it'd cost you several thousand dollars. However, National Instruments feels FIRST teams shouldn't pay a penny for LabVIEW, and so far that's how we've handled that situation. Teams who want a copy of LabVIEW for Linux or for the Mac merely have to ask for the specific operating system version. We had a thread over in the National Instruments LabVIEW topic in the Technical section where some had asked for the Linux and/or Mac version, and we told 'em where to send the e-mail requests; everyone who asked got their copies, some even got upgrades when the upgrades came out...

It would be fun to experiment, but when all is said and done, I am much happier coding in C.

I'm sure you're not the only one, primarily because that's "what you're most familiar with." I recently had a very "rich" discussion with a group of 7th graders who wanted to program their LEGO Mindstorms robots with Java, and their primary rationale was because "it's what everyone programs in nowadays." So I asked them how rich their library set was, how quickly they could get a program up and running, how easy it was to debug, how extensive it was, and questions like this to try to get them thinking about the things that would be important to consider. Their immediate reaction was one of, "but I KNOW Java, I have used it FOREVER, I don't want to learn a new language!" Those are all good reasons for a 7th grader to stick with when programming a LEGO Mindstorms robot, but is it the best one for an engineering competition such as FRC? I dunno, I'm still on the fence.

-Danny

[Mark Pierce]

Danny, thanks for your replies, It's nice to have your expertise here.

Originally Posted by Danny Diaz

... there are a lot of services we have to install ...

That may be true, but these services should be inactive unless I'm using LabView and should shut down without errors when windows does.

Originally Posted by Danny Diaz

... It does create sockets and interact with the networking stack in your computer for its own internal processing (so your Windows Firewall may bark).

That might very well be what I saw.

Ultimately, the main message that I was trying to convey in my earlier post is that we'll need adequate time, samples, and resources to successfully use whatever controller we go to next. I appreciate the effort that went into the Labview samples we've seen (CMUCam and others) I just remember having a student become more frustrated than inspired trying to get things to work.

I think the LabView RT system has real promise as a controller. I'd rather have a less bulky and complex system to program with, but I am intrigued by the possibilities of the hardware and software.

As to whether this is like what is used in industry, I think the graphical approach is becoming more and more prevalent even where C programming is done. We use UML diagrams for our design documentation and some code generation. We have also looked at other graphical tools as well. Graphical programming has been used for years in factory and lab control applications. Actually, Relay Logic and PLC controls which have been around for decades are actually simple graphical programming environments.

[eugenebrooks]

I mentored robot programming during the pbasic days, including writing state machines with students to handle autonomous operation. It was a breath of fresh air to switch to a C based system, polluted by the requirements of an 8 bit micro-controller as it is, and have the opportunity to teach students to program the robot controller in C. In doing this the students learn something that is applicable to their future college experience.

I can't say that I have spent a lot of time with Labview, but I was not very impressed with the use of labview to do initial work with the CMU camera. We ended up tossing these activities to develop variations of the camera software Kevin Watson provided. I don't see the value in students learning a proprietary programming system that they may never see again.

I have the strong opinion that a conventional C environment should be offered for any future robot controller, and I am not referring here to snippets of C code to be buried in some larger graphical programming environment. It would be great to have a controller along the lines of what Labview runs on, but it is clear that we will not be able to afford to buy these controllers looking at the prices for them. Being able to have controllers to use in development efforts outside of the actual robot is important and the EDU contoller provided by IFI went along way to satisfying this need at cheap prices.

To be blunt, I resonate with Alan here, highly skilled and dedicated programming mentors will drop out of the FIRST FRC program if they are forced to move away from a C programming environment. If this is where FIRST is headed with its new controller, for whatever reason it is headed in this direction, it needs to consider the error of its ways. I would suggest, instead, that a more rational ANSI C programming environment, with a suitable debugger interface be offered. It is perfectly okay to offer something in addition to that, but failing to offer a conventional C environment would be an error. One could add to this a Java environment, or any other additional environment like easy C, etc, even LabView, but these things sould be in addition to and not intending to supplant a conventional C environment.


Eugene

[Mike Martus]

My comments are as a NON programmer, just a teacher of a shop class.....

Easy C has been our savior the last two years. It has done all we asked and it was done by a student........

With no programming engineers (like many teams) and no programming classes in our school district (like many teams) I fear that a choice to move to a platform that is not as easy as Easy C and not to have the choice to do C if we have the expertise on our team will be a major misteak(sp ) for FIRST.

In education I measure the curriculum worth by a comparing of "What is Industry using" standard.

Question? Is Industry - wide scale using Lab view for their development and also are universities using Lab View for teaching programming in their curriculum?

If not them I say it would be a very poor choice to move to this.... my non programmer opinion.