Opinions wanted: LabView-based controller?
 

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.

Re: Opinions wanted: LabView-based controller?
 

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

Re: Opinions wanted: LabView-based controller?
 

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.

Re: Opinions wanted: LabView-based controller?
 

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

Planning, Training, and Support Critical
 

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.

Re: Opinions wanted: LabView-based controller?
 

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

Re: Planning, Training, and Support Critical
 

Sorry to hear this.

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.

Please refer to my previous post.

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.

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.

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 think everyone is on edge waiting to see what's coming down the line. :cool:

-Danny

Re: Opinions wanted: LabView-based controller?
 

You seem to be in a position to answer the question with an informed opinion. Why not go ahead and do so?

Re: Planning, Training, and Support Critical
 

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.

Re: Planning, Training, and Support Critical
 

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

Re: Opinions wanted: LabView-based controller?
 

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. :ahh: 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

Re: Opinions wanted: LabView-based controller?
 

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

Re: Opinions wanted: LabView-based controller?
 

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.

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

Re: Opinions wanted: LabView-based controller?
 

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

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

Re: Planning, Training, and Support Critical
 

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

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

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.