Re: Java vs Labview
 

LabVIEW for us is crazy easy to prototype ideas in and then graph outputs so we can view them. Graphs mean data and data provides answers to questions and allows us to iterate quickly with code.

We've talked about switching to C/C++ but just don't think it is worth it because we would lose a lot of that ability.

That being said, listen to what Greg said above and if you're going to do it then do it in the offseason or don't do it.

Also of note, we have an entire team dedicated to vision processing and programming in OpenCV/C so we use that as an outlet for those programmers who think LabVIEW is too simplistic for them to learn... though a lot of them come back around to after realizing how powerful it is.

Re: Java vs Labview
 

LabVIEW isn't an obviously useful skill if you intend to pursue a career in programming. But if you just end up needing to do a little bit of programming as part of your engineering job, and especially if you want to write programs to interface with lab instruments, it's good to know.

Re: Java vs Labview
 

Quoting this because it exactly reflects my opinions.

Re: Java vs Labview
 

I still stand with the LV crowd.

From the easy-to-use perspective, LabVIEW seems to be ahead: as mentioned above, the graphs allowed us to tune our PID controllers extremely quickly, and building the dashboard is also quick, as LV works well with graphic UIs.

Java is more applicable to the real world, and isn't that what FIRST is about? Inspiring and teaching kids to be successful in future STEM careers. However, at least for me, once I began starting to learn programming languages (I started with Python, then C++, LV, Java), each new language became very easy to learn. The thing is, it's not the syntax of a language that's hard to learn; it's the general structures of programming that take time to learn. The point is this: once you learn LV, you have set yourself up for success in learning any (or at least most) new programming languages.

Re: Java vs Labview
 

In general, LabView is easier for non-programmers to understand. That's a big plus.

I find LabView to be very straightforward. As long as you are doing fairly simple, straightforward, things, LabView is great. When you get into more complicated stuff, I found that I had to jump through hoops to store variables and loop through conditions. Java is much easier than that.

For example: Here's a proud moment of our code:

https://www.youtube.com/watch?v=roVc581joiA

We're the lower robot on the blue alliance. Our autonomous code lowers the arms, and then drives forward for a certain amount of time, and then the vision program kicks in and it goes toward the goal to try to make a shot.

You could do that all with a filmstrip in LabView. However, that isn't really what the code does. What we found is that we had an issue crossing the moat. Sometimes we got hung up. That was all about wheels and center of mass and all sorts of mechanical things, but we didn't have time to fix that, so we changed the program.

Lower the arms. Drive forward. When done driving forward, check the accelerometer values on the built in tilt sensor. If it appears to be on level ground, transfer to vision control. Otherwise, move backward briefly. Rest, and then gun it. Repeat up to three times.

That conditional loop is very straightforward in a high level language, but harder in labview. You end up with filmstips inside filmstrips, or custom VIs.
It is not awful. It's not incredibly hard, but your code ends up with a bunch of nested diagrams that are not easy to decipher. The java code was just a couple of lines, and worked very smoothly.

And then on top of that, we had a bunch of conditional statements for stability control, adjusting wheel speeds to prevent tipping. Reading and substituting PID values in certain cases, but not in others. Those nested if-thens are easy in Java. The LabView code gets pretty ugly.


Also, source code control is very difficult with LabView. If you have three programmers, you will be better off if you are using Git or SVN to share code, but that doesn't work as well with LabView.

So, my summary is that if you want to use your code to drive the robot and manipulate the actuators, LabView probably works. If you want to start doing fancy computation, move to Java.


Here, I will come to LabView's defense. I have used LabView professionally. I was working on jobs that analyzed noise and vibration signatures. I could use LabView to hook up my microphones, set a digital trigger, read a sound snippet, compute the FFT, and plot the power spectral density, and set a digital output, all in a few minutes of writing code. We used it a lot for prototyping, because it was just so much easier than writing "real" code. It even made it into some production systems when those were straightforward execution paths.

Furthermore, the word "LabView" on a resume screams "engineer" instead of "IT guy". If you are looking for jobs outside of the IT department, having LabView on your resume will raise the flag that this is probably someone comfortable with a voltmeter.

Labview is absolutely useless if you want to develop enterprise-style business systems, but, as you noted, when working with automation, it can be a very useful professional skill.

Re: Java vs Labview
 

I will concede that that is one of the more annoying things with LV. It frustrates me that LabVIEW is so hard to control by versions. I make updates to the code at home on my own computer, and, when I come back, I need to spend time integrating that with the actual standard code on our main programming computer. The backups onto 2 other computers and a flashdrive also get annoying, when, with a text-based language, it is much easier.

Agreed. :)

Re: Java vs Labview
 

What you describe does sound awful, it sounds like you are trying to take LabVIEW and turn it into a sequential language. Just because using the film strip works doesn't mean its the only way you can write your code in LabVIEW. In fact I would say the sequence structure is one of the worst features in LabVIEW and is a relic of older versions and methodologies.

If you want to move to more advanced LabVIEW code, don't use the film strip, especially as your main architecture. What you describes sounds like a perfect fit for a more parallel implementation, and the main auton flow a better fit for a simple state machine structure.

I completely disagree with this premise. LabVIEW is great for any level of sophistication you may find in FIRST. However, to achieve this you must go beyond the basics of LabVIEW.

Re: Java vs Labview
 

Related link on bad LV practices:
http://www.ni.com/newsletter/51735/en/

Note that #1 is overusing these flat sequence structures. To summarize the idea, LV programmers should rely more on data flow down wires rather than explicitly putting in filmstrips.

Re: Java vs Labview
 

Yeah I agree to the most important factor when changing different languages is what your programming team is more familiar with, for example if most of your students took AP Computer Science then you should probably use Java because they will be more comfortable with the language, but if your students are new to the programming field use LABView because its easier to understand and you already have experience in it so you can teach others. If you do decide to switch to Java write some robot code over the summer and test it out so you know during build season next year the team will still have the same features they had before.

Re: Java vs Labview
 

Well, LabVIEW is certainly capable of doing anything any other language is capable of, so it isn't a question of capability.

The thing is that if you have to go beyond the basics of LabVIEW, then you have to learn beyond the basics of LabVIEW, and that tends to chip away at the great benefit of LabVIEW, which is its ease of use and quick learning curve.

Of course that "learning curve" thing is highly variable depending on who is doing the teaching. If you have a good instructor available who knows how to do sophisticated things in LabVIEW, then the students' learning curve gets easier.

Each language has its own set of benefits and disadvantages, so there is no "this is the right way" of doing things. When our team decided to make the change from LabVIEW to Java, one of my great fears was uncaught exceptions turning the robot into a brick. Null pointers and missing break statements have caused very bad things to happen to our robot since we went to Java. We caught most of those in testing, but it did bite us rather hard in one match when a quick change in the pits left us stranded for most of a match one time this season.

Re: Java vs Labview
 

This is another point that I must disagree with. I don't think the basics or ease of use of LabVIEW are its biggest strengths. I don't even think it is that much easier to teach/learn compared to most other text based languages. In some cases early on I think it is tougher, specifically the data flow idea versus the sequential flow of a typical text language. And the requirement to learn beyond the basics is true in any language, I don't know why LabVIEW should be any different.

The biggest benefits for using LabVIEW are that the complex things are easier (and quicker) to do. This is really where the strengths of LabVIEW start coming out, especially in the context of FRC. It is built to allow rapid development of complex systems. NI would be hard pressed to find customers if their only selling point was that the basics are easy.

I agree, and my default recommendations for teams that are unsure on which language to use is to go with what their mentors know. Though for teams who want a challenge, learning more than one of the FRC languages is always a plus.

Re: Java vs Labview
 

Interesting. That's a perspective I haven't heard before, although it might be because of a different ideas of "complex". For doing sophisticated calculations and graphing, I preferred LabVIEW, assuming that what we were doing had a library available, but on the assembly line, the number of possible conditions we had to deal with made those LabVIEW diagrams awfully difficult to deal with.

Professionally, we always used it as a prototyping language, but when we had the real machine control, we used C or C++,or later we would C#, if the requirements would permit it.

It's always possible that I was doing it wrong, but I ended up cursing the mass of wires wandering about my LabVIEW diagrams, whether in FIRST or on my job, and I thought the nested if-thens were much cleaner and easier to understand.

To the original question: Obviously, as you can see from the differences of opinion, there's no right answer. If LabVIEW is working for you, don't fix it. Java and C++ are not "better". They're different.

Re: Java vs Labview
 

Re: Java vs Labview
 

#4 One that I am struggling with.... Is your decision, only for next year, or path for the team moving forward.

We are a labview team, we were a C++ beta team two years ago, as we contemplating the switch to C++, as some programmers had that experience. This was the year the roborio came out, and the beta documentation was tough, it did not make us want to swtich to C++ as we had a history of good Labview features in our back pocket, that would take sometime to get an equivalent built in C++.

But now, (as I understand it) labview is no longer an option at the FTC level, which means for the future, you will be feeding programmers at the FRC level, with primarily JAVA based programming, from FTC.

Re: Java vs Labview
 

So far, I think this thread has yielded a lot of good advice.

In the vein of leaning a tool better, let me comment on the nested if/else code. As you probably noticed, LV doesn't even have an if/else structure. Arguably, it would be easier to learn if it did. But those structures, in any language, lead to a large number of logic errors. So LV doesn't have one, ... skipped it, ... not dope.

Instead, the LV case structure can switch on a number, enum, string, or Boolean type. This allows, and hopefully encourages, you to combine inputs into a single selector taking you to a single diagram of code. In fact, if you follow this to its logical conclusion, you generally wind up making a state machine. State machines are not the beginner's goto tool, but they are taught in the LV basics class. At least I think they are. And for an assembly line control program, or any other mechanism with rigorous state definition, I'd encourage you to start with a state diagram, documenting and naming the states and transitions, and then coding with a state machine.

Similarly, many robot mechanisms would benefit from a state diagram and machine. I have written them many languages, and they are a great technique to learn and will make you a better programmer and engineer.

So, while not hard and fast rules:
Nested case structures are not the answer. The right number of frames for a film strip is one. Variables, you don't need no stinking variables. And custom VIs are the basic building block of all things -- they will provide you with what you need.

But seriously, if you find something hard to do in LV, please ask. Ditto for other languages. FRC should not be just a robot hackathon. Learning to program is way different and way better than learning a language.

Greg McKaskle