Re: Java vs Labview
 

We switched from Java to LabVIEW last year. My experience with Java was something close to an old disaster movie, except without the hero saving the day. There were many reasons why, but mainly it had to do with convoluted code structure and very painful slow debugging. Plus, the simulation and off-robot testing was practically nonexistent.

The switch to LabVIEW was fantastic. It solved so many of the structural and procedural issues we had with development of the robot.

The value of data and feedback cannot be overstated. PID tuning, which we did a lot of, was especially dependent on graphs and quick feedback (pardon the pun).

This concept keeps the horsepower where you need it. We tried to do this as well, but with limited success in our first try. We also used an Arduino for status and "bling" lights, which added another layer of programming for another skill level.

Also, to answer the comment about Java/C++ programming jobs. Yes, there are tons of them out in the world, but not all. Our team's programmer, the one that survived (and thrived) the season, has an internship at a local company that makes industrial process machines which run on LabVIEW, like so many of them do. Lab work? Industrial machinery and processes? LabVIEW.

Just so you know where I am coming from, my background is embedded control hardware with software development in C.

Re: Java vs Labview
 

Programing languages constantly evolve. Safe bet: The one you learn in high school won't be the one you use 10 years from now. Another safe bet. While there are a lot of jobs out there programing in Java, very few involve machine level applications. Good programmers transcend languages. The important focus is organized thinking to be able to break down complex concepts to executable code.

Our team programs in Java. The combination of it being the AP programing language, and available mentors made it the right choice for us. YMMV

Re: Java vs Labview
 

Just a couple of thoughts from the LabVIEW developer. I have been using LabVIEW for 13 years now and it is the main language that I program in.

It is used in the "real world." Mostly for test equipment automation, motion control, and data acquisition. I have used it for simple windows apps, to real time applications (like what is run on the roboRIO), to FPGA based applications.

LabVIEW does use data flow but also has object oriented capabilities. I would check out LabVIEW classes to learn more about this. NI even offers up examples of this that ship with LabVIEW as well as template frameworks such as the actor framework that you can reference.

I am just putting this info out there so people are aware of some of the capabilities it has that may not be known.

Re: Java vs Labview
 

Depends on the employer. Where I work, we place a low value on knowing any particular language, and a high value on being able to conceptualize, learn quickly and pick the right tool for the job.

If I need someone to build a large scale stream processing system, say to process a million messages a minute from deployed IoT devices, LabVIEW experience would be quite useful, no matter how the service was implemented.

Re: Java vs Labview
 

I've already been a part of two switchovers from labview to Java, and both times the team has gained quite a bit.

I could rant about all of the benefits we have received out of it, but many have already been mentioned in this thread.

One thing that hasn't been however, is that you can use both... at the same time. I give credit where it's due: Labview is phenomenal for viewing things. I've found that the graphing on the dashboard has in particular allowed much faster PID tuning.

Thankfully the WPILibraries give us a way to send data between robot code and Labview dashboards. This means you can have Java code running on the robot, and tune PID, and even do vision processing on the dashboard. Best of both worlds.

Re: Java vs Labview
 

I feel like java is more simple and easy to understand because the language in general is really cool. Labview is cool but, i have to go with Java#JAVAISLIFE

Re: Java vs Labview
 

We used to be a Labview team, but we switched to Java for a few reasons.

My top 10 reasons for using Java (in no particular order):

1. As others have mentioned, APCS teaches Java.
2. Java comes pre-installed on most school computers, and eclipse has a portable version of Java if necessary.
3. No license keys, no activations, no 2-hour installations, just pure, open-source bliss.
4. The job market for Java programmers is way bigger than that for LV programmers.
5. Git.
6. The computers could barely handle labview. The code took a solid 15 minutes to compile and deploy.
7. We found that Java has a lower learning curve once you start to use complex data structures. Variables in LV = :ahh:
8. Labview code quickly becomes spaghetti. With command-based programming and robotbuilder, Java is pretty nice.
9. The programming mentor knows Java.
10. Better external library support.

While LV has the advantage of being better for vision processing, there are other solutions that work, too (Roborealm, OpenCV running on RasPi or Jetson, GRIP, etc.). We haven't tried C++ because nobody on the team really knows it well, and the programmers are all trained in Java now already.

Re: Java vs Labview
 

We have used LabVIEW since it was available for FRC. We tried to make the switch to Java this year, but with my limited experience with it coupled with the fact that I was the only mentor for programming, it didn't go so well. We switched back to LabVIEW in the last week of the season this year, and all of the main functions of the robot were done within a day or two.

The thing about LabVIEW is that it is extremely easy to do parallel processing. You can literally open up Periodic Tasks.vi and run several loops in parallel without having to worry about starving the main loop of your code. (This is probably because of my novice experience with Java and written languages in general, but I couldn't figure out how to run control loops in Java to save my life. I was naive enough to write Thread.delay() in my Java code. Silly me.) In LabVIEW it's also easy to sequence commands using Notifiers and Sequence structures to make it really easy on the drivers.

Also, debugging and looking at data from the robot is super easy in LabVIEW as well. You can run the code from Robot Main.vi and then open up any file and see what value is being passed through a wire at any given time using probes. This makes debugging extremely easy. Graphs and Indicators are nice, too.

For programming a robot, LabVIEW is great. It has its cons, such as slow deploy and compile times, but all of the other pros make up for it.

For programming a robot AND learning more real-world coding habits, use Java or C++ (and Python!). Java and C++ compile and deploy quickly and you can still debug pretty easily by publishing variables to the SmartDashboard. You can also print to the roboRIO console and Driver Station. But it isn't as easy as LabVIEW.

Re: Java vs Labview
 

The thing that I dislike most about LabView is the necessity of installing the environment to program. When I'm out and about and thinking about robot code I can sit down and crank out c/c++/java in notepad++ or another text editor. LabVIEW doesn't have a small stand alone equivalent that allows me to program. It wouldn't even need to compile.

Re: Java vs Labview
 

It can be hard to objectively rank programming systems, so here's one way to look at it: in this thread so far the average team winning percentage from a comment that's neutral is 50.7%. The average for a comment that's pro-LabVIEW is 49.9%. The average for a comment that's pro-Java is 60.5%.

From this we can conclude that winning causes a more favorable view of Java.

QED. :)

Re: Java vs Labview
 

In regards to data structures I find making cluster type defs to be easy in LabVIEW and handle all the use cases I ever ran into. I guess I am curious what data type you are looking to use that LabVIEW can't do.

I agree LabVIEW code can look like spaghetti code. That is where good coding structure comes into play to make sure that is avoided so your code is easy to follow. Generally bundling data into cluster type defs and creating subVIs can help with keeping your code clean.

Re: Java vs Labview
 

How did you calculate this data? Just from this seasons record or a total record?

Re: Java vs Labview
 

My team has been doing Labview for the past 5 years and we love it. I find it is much easy to teach kid and the intimidation factor is much lower since all you are doing is drawing lines.

Over the past couple years we have been developing a cheap min Labview robots to help teach the kids. We found that if each kid has there own little robot they learn a lot faster. We also made a youtube series so they can take the robot home and learn to code. So far we have had great success.

We have are min bot release video her if anyone is interested https://www.youtube.com/watch?v=EFmnmp_VHHU

You can find are labview training classes here
https://www.youtube.com/channel/UCAY...mzYIDspSeCM3gw

Re: Java vs Labview
 

Are you still using the roboRIO to run these small robot? Do you make these available for other team to buy? Where would I get one if I did want to buy one?

Re: Java vs Labview
 

Follow the links. You'll eventually wind up at playingwithfusion.com where all is explained.