Java vs Labview

[Jared]

Originally Posted by Arhowk

This only applies for programmers who are inexperienced with computer vision. If you have two programmers with, lets say 3-4 years of experience in java and labview independently, the Java built (if we had a third using C++ he'd trump them all) will be faster and more percise. Note that in WPILibJ, some vision functions were missing and need to be wrapped

I'm not sure I agree. NI Vision for LabVIEW has all the same features and functionality as the C++ version, and the Java version is just a wrapper for the C++ version. The VI's and classes are equivalent between the two. Our 2012 vision code was made with vision assistant for labview, and we used the same vision assistant algorithm for our 2013 java vision system, which worked exactly the same way as the 2012 one. All the vision VI's have classes that can be accessed in C++ and Java that have the same functionality.

[Arhowk]

Originally Posted by Joe Ross

Why do you say that?

Maybe the algorithms are the same, but the raw speed is alot faster. Knowing what algorithms you want to use and simply typing them out is alot faster than dragging them from a box. Imagine typing this response by dragging a list of 100 words from a box into the text area. Personally, I've walked around Kettering and Traverse City and I didn't see a single LV team using a targeting system they built themselves.

As far as C++ over Java, dealing with pointers when handling images is so much nicer than dealing with complex structures.

Originally Posted by Jared

I'm not sure I agree. NI Vision for LabVIEW has all the same features and functionality as the C++ version, and the Java version is just a wrapper for the C++ version. The VI's and classes are equivalent between the two. Our 2012 vision code was made with vision assistant for labview, and we used the same vision assistant algorithm for our 2013 java vision system, which worked exactly the same way as the 2012 one. All the vision VI's have classes that can be accessed in C++ and Java that have the same functionality.

The Java wrapping for the C++ library is incomplete. Take this snippet for example

    //============================================================================
    //  Morphology functions
    //============================================================================
    //IMAQ_FUNC int           IMAQ_STDCALL imaqConvexHull(Image* dest, Image* source, int connectivity8);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqDanielssonDistance(Image* dest, Image* source);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqFillHoles(Image* dest, const Image* source, int connectivity8);
    //IMAQ_FUNC CircleReport* IMAQ_STDCALL imaqFindCircles(Image* dest, Image* source, float minRadius, float maxRadius, int* numCircles);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqLabel2(Image* dest, Image* source, int connectivity8, int* particleCount);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqMorphology(Image* dest, Image* source, MorphologyMethod method, const StructuringElement* structuringElement);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqRejectBorder(Image* dest, Image* source, int connectivity8);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqSegmentation(Image* dest, Image* source);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqSeparation(Image* dest, Image* source, int erosions, const StructuringElement* structuringElement);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqSimpleDistance(Image* dest, Image* source, const StructuringElement* structuringElement);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqSizeFilter(Image* dest, Image* source, int connectivity8, int erosions, SizeType keepSize, const StructuringElement* structuringElement);
    //IMAQ_FUNC int           IMAQ_STDCALL imaqSkeleton(Image* dest, Image* source, SkeletonMethod method);
        
        
    /**
     * Convex hull operation
     */
    private static final BlockingFunction imaqConvexHullFn = NativeLibrary.getDefaultInstance().getBlockingFunction("imaqConvexHull");
    static { imaqConvexHullFn.setTaskExecutor(taskExecutor); }
    
    public static void convexHull(Pointer dest, Pointer source, int connectivity8) throws NIVisionException {
        assertCleanStatus(imaqConvexHullFn.call3(dest.address().toUWord().toPrimitive(),
                                                source.address().toUWord().toPrimitive(),
                                                connectivity8));
    }
    
    /**
     * size filter function
     */
    private static final BlockingFunction imaqSizeFilterFn = NativeLibrary.getDefaultInstance().getBlockingFunction("imaqSizeFilter");
    static { imaqSizeFilterFn.setTaskExecutor(taskExecutor); }
    
    public static void sizeFilter(Pointer dest, Pointer source, boolean connectivity8, int erosions, boolean keepLarger) throws NIVisionException {
        assertCleanStatus(imaqSizeFilterFn.call6(dest.address().toUWord().toPrimitive(),
                                                source.address().toUWord().toPrimitive(),
                                                connectivity8 ? 1 : 0, erosions, keepLarger ? 0 : 1, 0));


    }
    //============================================================================
    //  Logical functions
    //============================================================================
    //IMAQ_FUNC int IMAQ_STDCALL imaqAnd(Image* dest, const Image* sourceA, const Image* sourceB);

~12 functions are API'd out in comments but only two of them are wrapped. For example, ~week ago I needed to rewrite our VP because the LED's from the white line arent close enough together to form a perfect rectangle so I needed to dilate the binary image, but NIVision.java had no dilate wrap.

[Phalanx]

This is a debate that has been going on since we've had a choice of multiple languages to choose from. There really isn't any "right" or "wrong" choice or one being better than the other when it comes to this particular environment. It's matter of preference, skill sets and risk.

Let me share a little of my background so you may understand where I am coming from with my analysis for the choice of language. I'm the Mentor for my Team for both Software and Electronics. I've been a low level ASSEMBLY language programmer my entire career (33 yrs). I personally don't like any OOP(Object Oriented Programming) whether it be JAVA, C++ or Labview.

However, these are the choices we have to work with. So let me share my reasoning for recommending Labview.

#1) Risk - Software stability.
79 Bugs found in C++, 32 still open.
68 Bugs found in JAVA, 21 still open.
24 Bugs found in Labview, 10 still open.

Here’s the link where I obtained that information:
http://firstforge.wpi.edu/sf/go/projects.wpilib/tracker
Hence, Labview is the more reliable and stable platform.

#2) Interoperability
The hardware(CRIO) is designed and manufactured by NI as is Labview.
They are meant to and designed to work together seamlessly.
The JVM is by Oracle, FRC Java Library is a port by WPI, as is C++
(Do correct me if I'm mistaken on the port statement).
As such you now have 2 additional and different software vendors.
Do we all know the expression, too many cooks spoil the soup?
So if there is a bug where is it and who do you ask to correct it?
Is it my code? Is it the Library? Is it the JVM?, or is it the hardware?

My own personal summary.
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE company one vendor to go to for a solution.

I have had this very issue in my professional career with software and hardware products that are "supposed" to work together.
Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.

So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.

I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.

[wt200999]

Originally Posted by Patrick Chiang

LV:
+ Click and drag. How much easier does it get? If you know "line-based programming" before you learn LV though, it can be a nightmare.

LabVIEW tends to get a bad rap for its graphical nature. When the cRIO was first introduced to FRC in 2009 I saw the choice of LabVIEW and C++ the same as I saw the choice between C and EasyC on the old controller. I told myself that 'I'm too good' for drag and drop. It turned out there is a lot more to it than that. LabVIEW has some powerful constructs which do take time to master, and the front panel features make tuning/debugging incredibly quick and easy.

I would actually say that LabVIEW has a steeper learning curve than its text based counter parts in many ways. As in any langauge it is very easy to make bad LabVIEW code. It seems that a lot of people stop learning the language when they have some of the basics down, and we end up seeing massive VIs of untamed wires and flat sequences which become hard/impossible to debug and maintain.

In the end I agree about using the language that you have a mentor/student with a good understanding in. When you have an instructor with a good understanding of how things work, it is easier to teach it, and more importantly prevent big design mistakes early on.

Originally Posted by Arhowk

Maybe the algorithms are the same, but the raw speed is alot faster.

I would be interested in seeing the data behind this claim, or some type of metric. Do you have a side by side comparison of the raw speed for various algorithms? I would assume all three languages would be nearly identical since they all call the same functions. Honestly I would expect Java to be the slowest since it has to run on the JVM level compared to C++/LabVIEW which are both compiled to assembly with many optimizations along the way.

Originally Posted by Arhowk

Knowing what algorithms you want to use and simply typing them out is alot faster than dragging them from a box. Imagine typing this response by dragging a list of 100 words from a box into the text area.

Knowing what functions you want and using Quick Drop I would imagine is close in speed to typing the name out in Java. Also the percent of time spent on actually writing code vs debugging is an important factor.

Originally Posted by Arhowk

Personally, I've walked around Kettering and Traverse City and I didn't see a single LV team using a targeting system they built themselves.

Its all about iterative design. In reality nobody is building a vision system 'themselves'. All of the functions and ideas we are using are built from years of industry and academic research as well as learning from previous years.

Should every team be reinventing the wheel each year? Most teams use the same type of algorithm, which is what the targeting system has been designed for. The example vision code is a good starting point and having a working vision algorithm is a big accomplishment for many teams. We don't all have to dive into OpenCV on a BeagleBone to track the retro reflective tape.

[Arhowk]

Originally Posted by wt200999

I would be interested in seeing the data behind this claim, or some type of metric. Do you have a side by side comparison of the raw speed for various algorithms? I would assume all three languages would be nearly identical since they all call the same functions. Honestly I would expect Java to be the slowest since it has to run on the JVM level compared to C++/LabVIEW which are both compiled to assembly with many optimizations along the way.

That line was meant for writing speed, not execution speed.

Although, I know I have 3 CRIOs on hand to do vision processing, though I don't have any of the development software for LV. I'd be interested to see a speed test too. Guessing the fact that its Java ME and not SE, the order would probably be Labview > C++ > Java (but the times will be remarkably similar, as the C++ and Java vision libraries simply uproot to the LV libraries)

Knowing what functions you want and using Quick Drop I would imagine is close in speed to typing the name out in Java. Also the percent of time spent on actually writing code vs debugging is an important factor.

BinaryImage dilateImage = NIVision.dilate(threshholdImage, 3);

theres only so many functions to use.

Of course, this is an opinionated topic. Even so, I can't imagine doing something like our team's 2014 code in LV. We have 5011* lines spread along 31* files and selecting each of their functions individually is a pain, not to mention that our auton system is a vectorized system of quadruple key-value pairs generated from binary information read from files on the cRIO.

Should every team be reinventing the wheel each year? Most teams use the same type of algorithm, which is what the targeting system has been designed for. The example vision code is a good starting point and having a working vision algorithm is a big accomplishment for many teams. We don't all have to dive into OpenCV on a BeagleBone to track the retro reflective tape.

Petoskey Paladins won an award for an OpenCV Raspberry PI :O no idea what a BeagleBone is

I agree that not every team should be doing what the Paladins did but spoonfeeding the entire code to the programmer doesn't really teach him anything.

E/ Here's a snippet of code that took me a half hour to write in Java (few more to tune) and wouldn't even dare writing in LV

        public void execute()
        {
            if(!init){
                loopTimer.start();
                loopTimer.reset();
                init = true;
            }
            if(finished) return;
            SmartDashboard.putNumber("loopTimer", loopTimer.get());
            int numOfRunningCommands = 0; //Used to make sure that it still has commands to be run and doesn't loop forever
            long nestedIfs = 0;
            long nestedIfFalse = 0;
            long nestedIfTrue = 0;
            long nestedPauseStop = 0;
            long nestedPause = 0;
            
            Enumeration runningCommandsIteration = storageVector.elements(); //List of objects in the storage hashtable
            Structure nextCommand; //Temporary storage for the next object in the hash
            while(runningCommandsIteration.hasMoreElements()){ 
                nextCommand = (Structure)(runningCommandsIteration.nextElement()); //Retrieves the next element Object and typecasts it to TimedCommnad
                
                if(nextCommand.conditionalStatus != 0)
                {
                    Conditional cond = (Conditional)nextCommand.command;
                    switch(nextCommand.conditionalStatus)
                    {
                        case Structure.conditionalPause:
                            nestedPause++;
                            break;
                            
                        case Structure.conditionalEndPause:
                            if(nestedPauseStop >> (nestedPause - 1) == 1)
                            {
                                loopTimer.stop();
                                loopTimerStopped = true;
                                return;
                            }else{
                                nestedPause--;
                                nestedPauseStop = nestedPauseStop &~ (1 << nestedPause);
                                if(loopTimerStopped && nestedPauseStop == 0)
                                {
                                    loopTimer.start();
                                    loopTimerStopped = false;
                                }
                            }
                            break;
                            
                        case Structure.conditionalWhile:
                            if(nestedIfFalse == 0 //No nested if false?
                                    && !nextCommand.finished //Not finished?
                                    && nextCommand.start < loopTimer.get()  //Time is proper?
                                    && !cond.shouldRun(file)){ //Run the command. If it pauses, than pause everything else.
                                numOfRunningCommands++;
                                nestedPauseStop = nestedPauseStop | (1 << (nestedPause-1));
                            }else if(!nextCommand.finished && //Else if it should've run but didnt the command returned false
                                    nextCommand.start < loopTimer.get()){ //so disable the while.
                                
                                nextCommand.finished = true;
                            }else{
                            }
                            break;
                        case Structure.conditionalIf:
                            if(!cond.shouldRun(file))
                            {
                                nestedIfFalse = nestedIfFalse | (1 << nestedIfs);
                            }else{
                                nestedIfTrue = nestedIfTrue | (1 << nestedIfs);
                            }
                            
                            nestedIfs++;
                            break;
                            
                        case Structure.conditionalEndIf:
                            nestedIfFalse = nestedIfFalse &~ (1 << (nestedIfs - 1)); //removes the bit from nestedIfFalse
                            nestedIfTrue = nestedIfTrue &~ (1 << (nestedIfs - 1));
                            
                            nestedIfs--;
                            break;
                            
                        case Structure.conditionalElse:
                            /*if(nestedIfFalse >> (nestedIfs - 1) == 1)
                            {
                                nestedIfFalse = nestedIfFalse &~ (1 << (nestedIfs - 1));
                            }else{
                                nestedIfFalse = nestedIfFalse | (1 << (nestedIfs-1));
                            }*/
                            break;
                            
                        case Structure.conditionalElseIf:
                            if(nestedIfTrue >> (nestedIfs - 1) == 0){ ///making sure that another else wasn't returned.
                                if(nestedIfFalse >> (nestedIfs - 1) == 1)
                                {
                                    if(cond.shouldRun(file))
                                    {
                                        nestedIfFalse = nestedIfFalse &~ (1 << (nestedIfs - 1));
                                        nestedIfTrue = nestedIfTrue | (1 << (nestedIfs - 1));
                                    }
                                }else if(nestedIfFalse >> (nestedIfs - 1) == 0){
                                    nestedIfFalse = nestedIfFalse | (1 << (nestedIfs-1));
                                }
                            }else{
                                nestedIfFalse = nestedIfFalse | (1 << (nestedIfs-1));
                            }
                            
                            break;
                            
                        default:
                            System.out.println("[AUTON] Conditional type passed that does not exist. O.O");
                    }
                    
                }else if(nestedIfFalse == 0 //no false if statements
                        && loopTimer.get() < nextCommand.timeout + nextCommand.start){ //within time frame
                    
                    if(loopTimer.get() > nextCommand.start){ //if the command should be running,
                        if(nextCommand.command == null)
                        {
                            System.out.println("[AUTON] Null Command Passed! Woops. How'd that happen? Report to Jake");
                        }else{
                            nextCommand.command.execute(file);
                            numOfRunningCommands += 1;
                        }
                        nextCommand.hasStarted = true;
                    }else{ //else, the command would be running but it hasn't met its start point so the tcg should still run because it hasnt run that command yet
                        numOfRunningCommands += 1;
                    }
                    
                }else if(nextCommand.hasStarted && !nextCommand.hasRunFinale && nextCommand.timeout + nextCommand.start < loopTimer.get()){
                    nextCommand.hasRunFinale = true;
                    if(nextCommand.command != null)
                    {
                        nextCommand.command.end();
                    }
                }
                    
            }
            if(numOfRunningCommands == 0)
            {
                finished = true; //If theres no commands left, exit
            }
        }

E/ Just noticed your signature. Of course you cant diss LV when you're getting paid to write it!

[Greg McKaskle]

Imagine typing this response by dragging a list of 100 words from a box into the text area.

I can imagine it, but that isn't really the same task. Procedural languages require you to name variables. Wires are not named. For loops and case statements are one drag for numerous lines of code. The editors are different. The languages are different.

The first year of FRC I watched a C++ programmer with print statements streaming by at a million miles per hour. I started helping and they kept adding print statements and waving the target around. We eventually hooked the camera up to LabVIEW, probed the image, saw that the camera wasn't focused, that the C++ programmer was holding the target way too close to the camera, and that they needed to modify the color threshold.

The tools are different and that is a good thing. FRC is all about exploring and learning new approaches. I don't use LV for all projects and I don't use C/C++ for all projects. Make your own choice, but please don't misrepresent.

Greg McKaskle

[Arhowk]

Originally Posted by Greg McKaskle

The first year of FRC I watched a C++ programmer with print statements streaming by at a million miles per hour. I started helping and they kept adding print statements and waving the target around. We eventually hooked the camera up to LabVIEW, probed the image, saw that the camera wasn't focused, that the C++ programmer was holding the target way too close to the camera, and that they needed to modify the color threshold.

... If you're binary image is returning dark you should probably throw out some test images on the different threshholding stages to make sure they're all behaving properly. The problem at hand here wasn't C++'s lack of proper probing techniques for vision processing (not familiar with C++ NIVision but im assuming its basically like Java) but rather the programmer's infamiliarity with proper computer vision debugging techniques. Those images could have been probed with BinaryImage.write

The tools are different and that is a good thing. FRC is all about exploring and learning new approaches. I don't use LV for all projects and I don't use C/C++ for all projects. Make your own choice, but please don't misrepresent.

Greg McKaskle

I can understand what you mean, but my main point is that if you're promoting the usage of LV as a language "used in industry," it seems misleading to someone who has no idea of the difference between languages. If you're planning on going into the industry with skills in programming, there are more diverse work options when you're working with a more well-known language. As i stated before, if you just want to learn programming as an introduction trade into engineering or just to try new things and have mentors that are comfortable with LV, than go ahead.

(Note that i edited that past post about four times before you posted)

[FrankJ]

If you do machine level programing in the real world, it is likely not to be Java. Plant automation is generally done with languages proprietary to the hardware used in the plant. A lot of times it is a combination of structured text, ladder logic, & function blocks. They all have their strengths. If you end up with a career in automation, you will eventually learn to use them all.

[geomapguy]

Originally Posted by FrankJ

If you do machine level programing in the real world, it is likely not to be Java. Plant automation is generally done with languages proprietary to the hardware used in the plant. A lot of times it is a combination of structured text, ladder logic, & function blocks. They all have their strengths. If you end up with a career in automation, you will eventually learn to use them all.

Some of our programming mentors have noted that learning languages becomes easier as you learn more (well given they have documented APIs)

[SoftwareBug2.0]

Originally Posted by Phalanx

This is a debate that has been going on since we've had a choice of multiple languages to choose from. There really isn't any "right" or "wrong" choice or one being better than the other when it comes to this particular environment. It's matter of preference, skill sets and risk.

Let me share a little of my background so you may understand where I am coming from with my analysis for the choice of language. I'm the Mentor for my Team for both Software and Electronics. I've been a low level ASSEMBLY language programmer my entire career (33 yrs). I personally don't like any OOP(Object Oriented Programming) whether it be JAVA, C++ or Labview.

However, these are the choices we have to work with. So let me share my reasoning for recommending Labview.

#1) Risk - Software stability.
79 Bugs found in C++, 32 still open.
68 Bugs found in JAVA, 21 still open.
24 Bugs found in Labview, 10 still open.

Here’s the link where I obtained that information:
http://firstforge.wpi.edu/sf/go/projects.wpilib/tracker
Hence, Labview is the more reliable and stable platform.

#2) Interoperability
The hardware(CRIO) is designed and manufactured by NI as is Labview.
They are meant to and designed to work together seamlessly.
The JVM is by Oracle, FRC Java Library is a port by WPI, as is C++
(Do correct me if I'm mistake on the port statement).
As such you now have 2 additional and different software vendors.
Do we all know the expression, too many cooks spoil the soup?
So if there is a bug where is it and who do you ask to correct it?
Is it my code? Is it the Library? Is it the JVM?, or is it the hardware?

My own personal summary.
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE company one vendor to go to for a solution.

I have had this very issue in my professional career with software and hardware products that are "supposed" to work together. Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.

So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.

I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.

There is something to this analysis. If you want to "color inside the lines" and have the best vendor support you should use whatever the vendor would have the most incentive to make work right. And that is Labview.

But the quality of support offered does not need to be the deciding factor. Last year, my team used C++ and had some issues. This year we're still using C++ but we've basically junked WPIlib and gone our own way. And life is beautiful now.

[Greg McKaskle]

E/ Just noticed your signature. Of course you cant diss LV when you're getting paid to write it!

Oh, I diss it plenty, but then we go about trying to improve it.

The story about the professional C++ programmer trying to do image processing was simply a counter example. She was fast at typing code. She could add print statements super fast. But they weren't the correct tool. By the way, the probe in LV is where you right-click on a wire, choose probe, and a window opens to show you the live image at that point in the processing chain. The program keeps running, you can move the target, focus the camera, tweak the panel values, add an additional probe, etc. It isn't a language feature, but an IDE feature because NI and LV sell tools to do this sort of thing. We also used to sell a C/Basic IDE and compiler, but that is now simply a library that plugs into MSVC.

but my main point is that if you're promoting the usage of LV as a language "used in industry," it seems misleading to someone who has no idea of the difference between languages. If you're planning on going into the industry with skills in programming, there are more diverse work options when you're working with a more well-known language.

The "used in industry" or "most popular" judgements don't carry much weight with me either. I think it is better to identify a strategy for evaluating the tools on a realistic task. Evaluate, choose, use and become proficient.

New task? Rinse and repeat. There is overhead in learning a new tool, and overhead in using the wrong tool for the job. Find the balance.

The evaluation period can involve asking for popularity or opinions, but that only gets you so far. If we substitute music for robots, which instrument would you learn? Is it a waste of time to learn how to play an instrument that isn't popular? Learning musical notation, theory, and lingo are valuable whether you learn the violin or piano, but neither will work well in a marching band.

and wouldn't even dare writing in LV

I think the topic here is productivity, not typing speed. The ability to progress from a problem statement to a reliable solution is common to much of engineering, industry, and life. LV's initial adoption was actually in instrument control. Composing and parsing packed arbitrary streams from oscilloscopes, DMMs, signal generators, scales, power supplies, etc. Programs would then be written to setup, evaluate, and sequence the instruments to automate repetitive testing. It is not that different from what you posted. So others have dared, succeeded, and their code has been running for decades.

As for the performance of the vision code:
By design, NIVision is divided into an inner library of kernel functions and outer rings of language wrappers. 98% of the processing time will be spent in the same code regardless of which language you choose. There will be some differences in allocation overhead and your own logic as to which operations to perform.

Back to the original topic. My goal is to get teams to learn a bit more about programming, computers, measurements, and control. And that means everyone on the team, not just the programmers. I kinda hope that all the robots don't look the same. I kinda wish they were more automated and more autonomous. I don't work in marketing or sales, so this popularity contest isn't really that exciting to me. I see amazing robots programmed in all three languages. And all the time I get to see kids gain confidence as circumstances require that they become the team programmer at the event and make the robot do stuff they didn't think they knew how to do.

Greg McKaskle

[Chadfrom308]

We have tried C++ from 2012-2013 and we used labview in 2011 and this year.

From my experience (and I should note that I know Java, Labview, and a little of C (Enough to get my arduino running cool things)) C++ is harder to change and debug than labview. With labview, if we need to see why something isn't running right, we just probe and run in RAM and we can find the problem in minutes. C++ always seems to take longer for our team.

It is also easier to follow the flow in labview, especially if it isn't a tangle. C++ isn't something I could figure out.

And in terms of speed: Your teleop loop is running at 50ms. As long as it runs that speed, I dont see an issue. We even have periodic tasks running at 10ms for some loops.

TL;DR: Labview is easier for our team and we get the same performance.

[mathking]

Almost every time I get in to a discussion about which language to use for FRC, someone starts talking about which language will yield faster programs. And the truth is that, compiled on to the cRIO there is not a "this language is faster than that language" rule.

It is true that in general if you write a program to run on your computer that a C++ application will run faster than a Java application. (Even this is a general principle and not a rule.) Because the Java application is compiled to Java byte code and run on the JVM. But when you compile Java into an application to run on a specific platform this is no longer a general principle. For example, I once used xCode to write some simple OS X native applications. I wrote the same applications in C++ and compiled them into OS X native applications. And which version was faster depended on what exactly I was doing.

For example, LabView is really good for integrating sensors and C++ is not natively friendly to event driven programming so the code is often not as natural to develop. Language choices always have tradeoffs, and it is more the exception than the rule that there is a clear "best" choice absent other constraints. If someone tells you that they use C++ (or any of the other choices) because "it is an industry standard" or "because it is faster" or my favorite "because it is better" (rather than "because it is better at a and b, which we do a lot") they probably have not made a well-informed decision.

A friend with a lot of C++ and LabView experience, who has programmed in Java quite a bit the last few years said that he would pick based on what the programming team has experience with. But absent that, he would say the more sensors you have, the more it makes sense to use LabView. He also said the bigger the overall code base, the more it makes sense to use C++ or Java. And in spite of his vast experience with C++ he nudged his team toward Java.

My own programming experience started with Fortran punch cards, then typed Fortran. Then I moved to Apple I Basic. At one point I was writing C and C++ large number processing algorithms for sensors and communication systems. I have used assembly. I also ventured into Pascal for while. I have taught C++ and Java. The past couple of years I have also taught MatLab. I used to be very resistant to OOP. I have come to believe that the larger the program, the stronger the case for OOP. I used to think that pointers we way better than the cumbersome structures used in Java. Then I started debugging big programs written in Java and I said "Wow, this takes a lot less time than it used to." I still use C for a lot of tasks. Lately I have seen a number of cool education-oriented tools with compiled Java (not the JVM) on machine level systems that run continuously and I think "The garbage collector alone is reason to use Java." I would be very willing to consider switching languages if we used RobotC (and its debugging tools). Again, my point is the same as a number of others. There is no best choice. Just make an informed choice and know that a well written program in any of the three language choices is probably going to run a lot better than a poorly written one in a supposedly better language.

[Patrick Chiang]

Originally Posted by Arhowk

This only applies for programmers who are inexperienced with computer vision. If you have two programmers with, lets say 3-4 years of experience in java and labview independently, the Java built (if we had a third using C++ he'd trump them all) will be faster and more percise. Note that in WPILibJ, some vision functions were missing and need to be wrapped

Not my experience. (And I know Java and C++ way more than LV.) Testing and debugging vision in Java or C++ has been a pain. It's a visual thing, so it makes sense a visual language does it better. The real time debugging features are pretty convenient too.

Originally Posted by Phalanx

#1) Risk - Software stability.
79 Bugs found in C++, 32 still open.
68 Bugs found in JAVA, 21 still open.
24 Bugs found in Labview, 10 still open.

Here’s the link where I obtained that information:
http://firstforge.wpi.edu/sf/go/projects.wpilib/tracker
Hence, Labview is the more reliable and stable platform.

Comparing number of bugs reported on a single bug tracker is a pretty poor metric. It could be there are less people using LV, or maybe the opposite is true. It could be people using LV are reporting their bugs elsewhere. It could be because the Java and C++ bugs were solved 2 months ago but the people who develop for those libraries received the bug reports on another platform and didn't close them here.

The FIRST tracker may be "official", but I personally don't know anyone who uses it to report bugs. If anything, comparing the number of problem threads on Chief Delphi and replies would be a more comprehensive metric for which tool is more stable.

Originally Posted by Phalanx

#2) Interoperability
The hardware(CRIO) is designed and manufactured by NI as is Labview.
They are meant to and designed to work together seamlessly.
The JVM is by Oracle, FRC Java Library is a port by WPI, as is C++
(Do correct me if I'm mistaken on the port statement).
As such you now have 2 additional and different software vendors.
Do we all know the expression, too many cooks spoil the soup?
So if there is a bug where is it and who do you ask to correct it?
Is it my code? Is it the Library? Is it the JVM?, or is it the hardware?

Hint: It's not the library, it's not the JVM, and it's not the cRIO. In all my 5 or 6 years of using FRC Java, I have personally never had to solve a problem that had to do with the library or the JVM or the cRIO, and I've never had the library behave in a way that is illogical for me. For me and the majority of teams I've helped or talked to at competitions, the library is never the problem.

Does this mean that the library is bugless and completely stable? No, but it's a much smaller problem than people seem to be making it, to the point where it's not a concern for most teams that will be using the common functions of the library.

Originally Posted by Phalanx

My own personal summary.
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE company one vendor to go to for a solution.

I have had this very issue in my professional career with software and hardware products that are "supposed" to work together.
Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.

So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.

I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.

Here's the thing though: FRC is designed to emulate real life engineering where knowing the vendors is important and you need to have fire drills on who to call if something fails, but for most teams, that's just not how it is.
The cRIOs, libraries, JVM...etc are all fairly reliable. The biggest points of failure are usually the wiring on your robot or the code that you wrote. Pointing fingers at vendors is much less helpful than being able to debug and solve your problem immediately, which I'll argue that text based languages are better for.

Originally Posted by wt200999

I would actually say that LabVIEW has a steeper learning curve than its text based counter parts in many ways. As in any langauge it is very easy to make bad LabVIEW code. It seems that a lot of people stop learning the language when they have some of the basics down, and we end up seeing massive VIs of untamed wires and flat sequences which become hard/impossible to debug and maintain.

You can have spaghetti code in any language. It's just more literal "spaghetti" in LV.
I wouldn't say it has a steeper learning curve. For a all the basic functionality on top of a robot (without fancy custom steering code, PID, or vision...etc), you can learn to program in LV before you learn why you should be setting the value of the jags to a double in Java or C++. Unless, of course, you already knew a text based language.

Originally Posted by wt200999

Knowing what functions you want and using Quick Drop I would imagine is close in speed to typing the name out in Java. Also the percent of time spent on actually writing code vs debugging is an important factor.

Not even close. Say we have a robot with 4 jags, and each need to be controlled by a separate joystick. Don't ask why, the team needs it done now. In Java, the project takes 5 seconds to create, I can write up the code required in 30 seconds (conservatively), deploy to the robot in 52 seconds, go get a soda, and be back before the LV project is even fully created.

Comparing the code production time, I'll assume you're fairly fast and don't make mistakes in LV. It takes you at least 2 blocks for each jag, open and set, then you need 2 blocks for each joystick, open and set, then for each you need to specify the port, module, and channel constants, and then wire them all together.
Then, copy and paste 4 times and change each constant. If the whole thing is in a while loop, you also need to clean the broken wires and then rewire each time. Even if each palette you need is already pinned on the side (or using quick drop), I have a hard time seeing anyone do all that in 30 seconds, not to mention LV sometimes needs to open up new files whenever you access new tiles for the first time.

Originally Posted by Greg McKaskle

I can imagine it, but that isn't really the same task. Procedural languages require you to name variables. Wires are not named. For loops and case statements are one drag for numerous lines of code. The editors are different. The languages are different.

Come on, now. There are things that are easier in LabVIEW (like debugging vision as you said), but for loops and case statements are not them. How much does it really take to create a for loop in text code? 2 seconds? Creating and hooking up the constant true/false conditional in LV takes more time, and finding the comparison operator in LV takes time too.
Imagine if you had to do a perfectly reasonable conditional like (a && (b || c) && (d < e + f * g)), the race is over for LV at that point.

[BitTwiddler]

Originally Posted by Greg McKaskle

Oh, I diss it plenty, but then we go about trying to improve it.

Greg McKaskle

Greg,

I'd like to make a suggestion that I think would make editing in LV a little easier.

You see I have this love/hate relationship with the tools pallet. Sometimes I find that the tool auto select feature is very handy and at other times it just drives me nuts. Usually what happens is when I'm simply trying to use the pointer tool to select a vi in order to move or copy it but then milliseconds before I click the mouse I get too close to a terminal and it changes to the wire spool. Now I have to stop what I was trying to do and reach over to the keyboard to hit the escape key to shut off the wiring function. This really disrupts the flow of the work and I hope none of the students hear the comments muttered under my breath. I know I can turn the automatic selection off but then I'm constantly having to manually change tools. There simply has to be a better way of getting the right tool at the right time.

Anyway, one feature I'd like to see is a magnifier/zoom tool to help these 65 year old eyes to better see exactly where the pointer is with respect to the object I'm trying to work on whether it be a vi, a structure or an item on the function pallet. That would really be helpful. Especially on the typical driver station laptop with its dinky 13" screen.

Thanks for your continued support to the teams.

Dave Tanguay