Re: Curiosity on why most teams choose LabView
 

LabVIEW is easier to learn when you have no programming experience whatsoever- it's more visual and intuitive to use. We have a relatively high turn-over rate with our programmers, and we switched from MPLab and c coding to LabVIEW to facilitate passing on knowledge and teaching rookies.

Re: Curiosity on why most teams choose LabView
 

Considering that the most usefull thing that you could do in auto last year was "drive straight for 5 seconds" and that anything beyond that was gravy, points to the fact that the teams that "had no auto" were probably dealing with more challenging issues than which language to use.

The fact that their robots moved at all in teleop is a good indication that whatever language they used was sufficient for them.

I was a died-in-the-wool C++ programmer untill I learned LabVIEW for Lunacy back in 2008. I wasn't looking forward to it, but I made the switch for two reasons...

1) The language was being used in FTC and FRC, so a programmer I trained in one, was usefull in the other.

2) It seemed that LabVIEW would be more usefull to a wider range of Engineers/Scientists, than say C++ which would be best for a computer science student.

If you're programming an air traffic control simulator, you're not going to use labview, but how many engineers do that sort of programming?

I'm dissapointed that last years, (and maybe this years) FRC game didn't provide more reward for great auto modes, but I didn't see the teams that wanted to use labVIEW to do cool programming being limited by their choice.

Case in point... our FTC robot has a good range of auto modes that we'll be running in Atlanta later this year (for the second time).

I also really like the graphical debugging capabilities of LabVIEW, and I'm not sure I'd like to go back to text based debugging.

Phil.

Re: Curiosity on why most teams choose LabView
 

1075 has always coded our robots in C/C++ (well, since 2004 anyway). I personally use LabVIEW for work, and I have a very love/hate relationship with it. It makes some difficult programming tasks very simple, but makes some simple tasks rather complex, and the whole tendency to create spaghetti really bugs me.

Re: Curiosity on why most teams choose LabView
 

In the interest of keeping things educational and inspirational, I'll continue the hijack just a bit longer to give a response to what makes something a programming language.

A programming language is a mathematical definition that distinguishes valid and invalid user programs, and defines the result of carrying out a sequence of instructions in a user program.

Normally tools such as compilers and runtime environment ,or interpreters are built so that a computer processor can behave according to the language constructs.

As an example, C is a language. gcc is a compiler tool for turning user text sequences into processor specific implementations of the user's C code.

Similarly, G is a graphical language, LabVIEW is a collection of tools for writing VI code or for compiling to a processor specific implementation.

Similarly, JAVA is a language, Squawk JVM is a runtime environment for executing JAVA bytecodes, and NetBeans is a collection of tools that support the JAVA language and allow it to target a specific JVM.

It doesn't actually take much to build a programming language. The math and theory to classify the inherent power of a program running on a processor was done in the '30s. If a language can build a Turing machine, it is capable of solving all computable problems and therefore can write any program, any tool, and is Turing Complete.

Classification of languages is somewhat less well defined. According to http://en.wikipedia.org/wiki/Domain-specific_language Excel and other spreadsheets are usually classified as domain specific. The VBScript which is hosted within Excel is general purpose.

From the computer science perspective, LabVIEW, Java, and C are all general purpose languages, but differ in the paradigms they support.

Other less mathematical definitions you can use to determine the power of a language include ...
Can you write a good game?
Can you write a compiler for your language or another language?
Are people willing to spend their time and money learning and using it?
Can you build a successful FRC robot programmed in that language?

The answer for all three FRC languages to all of these questions is yes.

One of the great things about FRC, IMO, is the exposure to different tools and techniques, different approaches, and different solutions. Opinions are fine and good, but don't let them obscure an opportunity to learn.

Greg McKaskle

Re: Curiosity on why most teams choose LabView
 

What does that have to do with the topic (do you use labview and why)? If you want to fight about what makes a programming language, make another post, please.

Re: Curiosity on why most teams choose LabView
 

I apologize for not reading all 3 pages, but i had to skip some to be able to post this.

Last year I was the only programmer and my mentor had no experience in LabVIEW but we decided to take a chance and use it anyways. I am very glad I got the chance to use it however, we never were able to use it to its full potential, mainly due to time and manpower constraints. we were one of the robots at nationals that didn't do anything in autonomous for the first two matches simply because we couldn't figure it out. We eventually did, but not before I fell prey to death stares from four DANA mentors, three parents, 15 students (and a partridge in a pear tree) because our robot didn't move for two practice matches and the autonomous of the third. Our (more specifically, my) inexperience with the software as it pertains to FRC along with its perceived problems (download speed, learning curve, some other things) led us to change our environment C++ this year, and bring in four new members to the programming team. I felt it would not be the best for me personally, but it is definitely working for the team. Overall I'm glad I got the chance to use LabVIEW for the year, but it just didn't work for the team. I would definitely suggest that teams with programmers who have no experience with coding use LabVIEW. Maybe the team will return to LabVIEW as well next year when it can be seen as more stable by the team.

Re: Curiosity on why most teams choose LabView
 

Ok, I see that you only have three total posts on CD so I will be as gentle as I can. Just to warn you: this post has nothing to do with the thread. Normally I would disengage such converse however I feel that it is important to clear a few things up.

Yes the topic of the thread is "Curiosity on why most teams choose LabView" (not "do you use labview and why" as you posted) First and foremost this is a forum that has been created to help inform individuals and teams about FIRST and robotics in general. Information is shared, discussed, and often times debated. I posted on topic originally. I stated the reasons we as a team use c/c++ vs. Labview. The reasons I stated have become the topic of constructive debate (not an argument) between myself, others, and the boys in blue. While I may not agree with their opinion I do respect it as such. The discussion was not what I consider "off topic" but rather to the heart of it. The reasons people DO NOT choose Labview are just as important as the reasons people DO. Sometimes they are more important, especially to the company that created the software, National Instruments. I suspect my opinion is one that they hear often. I also suspect that they would like to understand it more and educate others who may share my opinion. Since your comment was directed to the people that make Labview I will assume that you are not aware of these things. The world is not always sunshine and gummy bears, people disagree about things. Engineers disgree often. Its how we approach these disagreements that make the difference between argument and constructive debate, productivity and failure. Please consider these things and keep an open mind the next time you decide to become the self appointed thread police.

Re: Curiosity on why most teams choose LabView
 

Our team selected LabView because we had no programming experience and two of our Mentors used it professionally and were able to get us up to speed. Since we were rookies last year when it first came out we jumped on it...

Re: Curiosity on why most teams choose LabView
 

We were a rookie team last year we choose LV beacause it is easy to teach and understand, we looked at Java this year but have decided that we do not have the background and could not find the information needed to teach or program anything in time.

Re: Curiosity on why most teams choose LabView
 

As the de facto programmer for the team i was "strongly encouraged" to use LABView, even though the more technically inclined people on the team have had more experience with Java and RobotC. O.o