LabVIEW for C/C++/Java Programmers
 

(Long build-up warning, the actual question is at the bottom!)

To start off, the programmers on our team have pretty solid "conventional" coding experience with C/C++/Java. Last year, when we first got our hands on the cRIO and dev tools, we initially sided with C++, but after some frustration, switched over to the LabVIEW environment hoping for smoother sailing.

After a couple weeks of tinkering with it, myself and the other programmer at the time found that we were never "really" able to wrap our heads around it, and the code we managed to produce certainly reflected that (we've successfully used it to scare people, including ourselves). When the competition finally came around, there was a quick rewrite of everything in C++ because it simply didn't work. Needless to say, we had better luck the second time around.

So... clearly we're bad LabVIEW coders :P. Still, I couldn't help but notice how many other teams (ie, the vast majority or FIRST) had little to no problems working with it. So my question is this: has anyone else had trouble "figuring out" LabVIEW when coming from a so-called "conventional" programming background?

(Side note: obviously, had we devoted the time necessary to truly understand it, this problem never would have existed. I'm just asking if others have had similar experiences)

Re: LabVIEW for C/C++/Java Programmers
 

My experience shows that those who have programmed in conventional languages have trouble switching to LabVIEW. I, having done little coding in C++, learned most things for the first time in LabVIEW. This made everything pretty easy. A couple people on our team who had coded in C had trouble relearning how to do things in LabVIEW.

Re: LabVIEW for C/C++/Java Programmers
 

I certainly had a hard time moving from the languages I knew to Labview. But once you know how Labview works, it becomes natural to program in either language.

It really just takes a little time experimenting to become a Labview user

I think the big advantage of Labview is how quickly non-programmers can pick up the concepts

Re: LabVIEW for C/C++/Java Programmers
 

I had no problem programing in LabView, but I was just starting. 2009 was the first year I started programing, I was learning Visual Basic in school and picked up LabView at robotics. My dad picked up LabView fairly easy, and he has been programing for many years (he wants us to use machine code :p) I think the reason we picked it up so easily is because I was just starting and we learned together. I guess it all depends on your experience with LabView.

Re: LabVIEW for C/C++/Java Programmers
 

When we pre-ordered the new control system before the last season (lunacy) I spent about month learning LabVIEW. Didn't have any onsite mentors for it and I didn't read too much of anything in the idea of "how to do LabVIEW". It took a bit to first understand it, but once I got it, it was pretty simple.

-Tanner

Re: LabVIEW for C/C++/Java Programmers
 

The trouble comes when one insists on using that procedural-programming background instead of letting go and opening one's mind to the dataflow paradigm. It took me a couple of days to stop trying to apply what I "knew" about programming, but once I had accepted the way LabVIEW actually works it was smooth sailing.

It's a very Zen-like situation. The less you know, the more you learn. To learn faster, you must first forget the knowledge you already have.

Re: LabVIEW for C/C++/Java Programmers
 

With your permission Tim, could I expand the thread to ask if anyone who started out by learning LabVIEW as a first programming experience later had trouble learning C because they had trouble setting aside the dataflow paradigm? My son has never programmed before, and he is learning LabVIEW as a first experience. I am wondering what unique obstacles (if any) this may create when (if) he later tries to learn C.


~

Re: LabVIEW for C/C++/Java Programmers
 

No objections from me :).

The funny thing I found was that, after some LabVIEW experience with FLL, I didn't think figuring out the "new" FRC version would be much of a problem. I was sure wrong :P.

But... even from that "basic" experience I didn't really have issues learning different languages later on. I think having some experience bossing computers around really helped to that end, actually.

Re: LabVIEW for C/C++/Java Programmers
 

Let's say that you know base-ten numbers. You learn basic arithmetic, multiplication tables, decimals, fractions, all in base-ten. As far as you know, this is the only way to do math and you are on top of it. Go you.

Then a new teacher, say the CS teacher, decides to teach you base-eight numbers. It is weird. Many of the things you know about math are not necessarily correct. Everything is slow, you make many mistakes, and really just want to pretend this never existed.

Next the teacher brings up base-16, even weirder, and then base-2. Finally things start to click and you realize that there is nothing magic about base-ten, all of these are arbitrary, and there are benefits to knowing more than one system.

A similar analogy to Cartesian coordinate system versus spherical, versus cylindrical, ..., also fits. True, a language is more complex than a mathematical convention, but the point is that many times, the second way to solve a problem is more difficult to learn than the first. That doesn't mean that there was an issue with either of them, but it is simply human nature and is a natural process. Once you get over that hump, the benefits of knowing two mean three and four come far easier.

Greg McKaskle

Re: LabVIEW for C/C++/Java Programmers
 

The Key to Successful programming a robot in Labview is to understand the concept of data flow. Many of the text for Labview state that a procedural programming mindset can cause problems, but do not define or give very good examples of exactly what data flow means. There is an opportunity for some one to write a paper on data flow best practices. This would help the FRC community allot. Anyone up to the challenge? The next big thing that could help with the robot programming is a good tutorial on state machines. There are some good college level text on the subject but most students seam to have problems comprehending them. Another opportunity for a white paper. This year our robot code was much more complex than previous years. We had some serious control problems. As the the season progressed and the code evolved, it went from a procedural flavor to data flow and our problems resolved. This happened by experimentation not by design. The question is how to teach these concepts to new Labview programmers.

Re: LabVIEW for C/C++/Java Programmers
 

Wow, great post, you hit the nail on the head. The only thing I would add is a brief but usable explanation of the realtime and multitasking aspects of LabVIEW in the FRC context (LabVIEW FRC Framework). Or perhaps this could be integrated into the main topics you mentioned. From posts I have read this season and from personal experience, that was a big stumbling block for many new FRC LabVIEW users.


~

Re: LabVIEW for C/C++/Java Programmers
 

This is completely true. I took a course in programming languages, at first glance the class seemed simple, we had to learn the basics of different languages and write relatively simple programs. By this point in my Computer Science Curriculum I had little difficulty picking up languages.

The real test came when new paradigms were introduced. (Functional and Logic programming). You have to forget what you know about programming and start again, obviously it is still easier to learn than it was to learn your first language, however it is much harder than learning an additional language that follows the same paradigm.

Comparing it to learning spoken languages, Java to C++ is like French to Spanish, structure is the same, syntax is simmilar. Going from C++ to Labview is like French to German, the structure and approach are completely different.

When moving to a new programming paradigm, it is important to remember to apply the lessons you have learned about how to learn a language, not to apply the lessons about the actual language.

Re: LabVIEW for C/C++/Java Programmers
 

This might sound like an idiotic question, but is there a way to edit labview code with a text editor?

Re: LabVIEW for C/C++/Java Programmers
 

No, you can't edit LabVIEW code with a text editor. There is no underlying text representation to manipulate.

It might be possible to take the "directed graph" which defines a vi and produce a text report containing all its information, but one would need to invent a syntax for it, and making changes to that report and reversing the process would be extraordinarily error-prone.

Re: LabVIEW for C/C++/Java Programmers
 

Ugh...I've learned several text-based languages over the years, but switching to Labview was the hardest one to do. One of the mentors would tease me about how I wrote my labview code with random sequence blocks in it, simply because I wasn't used to having an environment do things for me like race conditions.

I only use it for the dashboard, but it's still taught me some things

Re: LabVIEW for C/C++/Java Programmers
 

I am comfortable with LV ,C/C++ and matlab. Our team chose to stay with C++ for FRC target code but since I always do engineering simulations of our control systems including the pneumatics my language preferences vary.

For engineering analysis, I usually prefer matlab but find the intended users are often unfamiliar with it or don't have matlab installed. Since most of the kids have C capability, several build seasons I used C to write the simulations and used EXCEL to do the graphing.

Recently, I've wrapped LV I/O functions around C programs to extract the utility of both languages for quick simulation. The LV graphics are powerful and the text editing of C beats the somewhat clumsy data flow editing of LV particularly when dealing with logic and simple math. The plus is that most teams have LV working now so the software is portable.

Had our team used LV, I think it would have been easy to build an autonomous mode simulator that used LV embedded target code for the control system and LV for the simulated dynamics and graphics as some teams have done.

Often times hardware availability dictates the use of LV. At the college where I mentor we had an NI DAQ board lying around so we chose to use LV to write the control system for a STM project to aid a nanotech initiative. It took longer since I had to learn LV but like Alan said when you give in to the data flow concept the work flows easier too.

If NI offered up a good cheap virtual space modeling capability I'd use LV more for sure. Maybe they will include more graphics and virtual capability in next year's kit.

Re: LabVIEW for C/C++/Java Programmers
 

I agree, with a heavy background in Java, switching to Labview was a burden, yet I just read the Labview manual once or twice and things started to make sense. I have no clear method to decipher Labview into some other language, other than reading the manual and trial & error.

Re: LabVIEW for C/C++/Java Programmers
 

I have to agree that Gdeaver hit the nail on the head! Procedural versus data flow are different beasts, both to be tamed and put to good use. A good conceptual middle ground is to learn to exploit the benefits of procedural programming in a multi-tasked/multi-threaded environment. Spend some time learning to use things like semaphores, messaging, state programming.

I've been programming as a professional since the early '80s. I have used many different languages. My first exposure to LabView came in the early '90s. At the time I was working for a controls company and we were investigating LabView as a tool for developing User Interfaces (UIs). One of the tasks I was assigned then was to implement a serial protocol using it. Not the best tool for the job. Like has been stated earlier each choice has its strengths and its weaknesses. Look at the strengths and weaknesses of your programming team and pick the environment that fills in the gaps. There are ways to use both LabView and C++ in a PC environment and I hope they expose that capability for FRC in the near future.

On another note, early on in using LabView for FRC my son and I wrote a simple motor simulator VI in LabView. It was a great learning experience and gave us some tools to work out the bugs in our PID routines. Has anyone else used LabView to build up a virtual library of useful FRC components?

Re: LabVIEW for C/C++/Java Programmers
 

Here's my crack on data flow:

LabVIEW Data Flow Explained

Most people who come to LabVIEW from a procedural language like C or C++ have trouble understanding the execution order of the code. The trouble comes from trying to making things happen in a sequence, as in do A then B. LabVIEW code does not have a sequentially defined order like text languages, where the execution goes from line to line. Instead, execution is defined by data flow.

Data Flow

In LabVIEW, any piece of code, either a primitive VI or a user-defined VI, can have input and output terminals. In order to give these terminals a value, data must be "wired" into these terminals from another source, either a UI control, constant, or output terminal. Wires that are connected to inputs must have a value, they cannot be null. The way LabVIEW decides which part of the code to execute depends on what wires have values. Suppose you have two constants wired into a multiply block, and the output of that is wired into a negate block. The negate block cannot execute until it's input wire has a value. Therefore, the multiply block executes first, as it's input wires have values (the constants). After the multiply block has run, the output terminal gives the negate block's input wire a value. Now that all of the inputs to the block have values, the negate block can run.

And that's it. As long as a block or VI's input wires have a value, it can run. Inputs that are not wired and not required have a default value, so as long as the others have values, it can still run. That means that if you have two multiply blocks with constants wired into their inputs and no output from one multiply block goes into an input to the other, the order in which those multiply blocks execute is undefined; for all intents and purposes, they happen at the same time, or in parallel. Now, if you wire the output of one of the multiply blocks to the input of the other, then the first block has to execute first, then the next as it is waiting for a value.

Using Data Flow To Control Execution

Now that data flow has been explained a little, how is it used to control the execution of code? For most operations, nothing else needs to be done. A series of calculations on a number simply execute as the previous calculations complete until it is done. However, some things don't have data dependancies (wires) between each other, yet still must happen in a sequence. Many first time LabVIEW users use the sequence structure to make things happen one after the other. While this can be done, it's generally not the best paradigm to use when solving a problem.

Here's a few alternative things to try:

First, use error clusters to enforce data flow. Most VIs have error in and out terminals that are usually used for error checking. Another way to use them is to wire the error out from one VI to the error in on another VI to make sure the first VI executes before the second.

Secondly, if the VIs don't have error terminals, you could put each segment of code into a sub VI, add error in and out terminals, and wire the error out terminals into the error in terminals to make the VIs execute in order.

Lastly, if your code is too complicated for the other two suggestions, consider a state machine. A state machine executes code based on a state. Once one state is deemed complete, the next state is executed, or any other state depending on the need. State machines consist of a while loop with a case structure inside. An enum in a shift register is used to determine the state. The enum is wired into the case structure and each case has code for each state. To move to another state, simply wire a different value for the enum into the right terminal of the shift register and the next loop will execute it. To make the state machine into a VI that can be called from anywhere, wire a boolean true into the stop condition terminal of the while loop and make sure that nothing is wired into the left side of the enum shift register. Put the code in a sub VI, give it inputs and outputs if needed. The sub VI will remember the values of the shift registers and maintain it's state. Here's a post of mine on how to make a state machine.

If you have any questions or improvements, feel free to post them.

Re: LabVIEW for C/C++/Java Programmers
 

The description about data flow is pretty accurate, but since LV includes some control structures, there are a few additional descriptions that are useful to know about.

A LV program is made of one or more VIs (Virtual Instruments).
A VI is made up of a panel, a diagram, and descriptive info such as the name, icon, and description.
The panel allows the user to view and interact with data.
A diagram contains nodes and wires and is used to describe how the computer interacts with data.
All control flow structures are nodes that contain diagrams.
*Loops are control flow nodes that contain a diagram and run it as many times as specified.
*Cases and other conditional statements execute only one of their diagrams based on the selector input.
*Sequences execute each diagram, one after the other.
*A subVI call is a node that updates the panel and executes the diagram of the VI referenced by the subVI node.

A diagram executes by propagating data already available on wires, followed by executing nodes that do not need any additional inputs. Each and every node on a diagram is executed once and only once as its data becomes available. When all nodes on the diagram are complete, the diagram completes and propagates data to its outputs wires.

Other things worth noting:
Nodes are functions, but they don't necessarily return immediately -- especially when they are I/O related -- and can be used to regulate or signal downstream or owning code.
Wires are special unnamed variables useful for safe parallel programming. The wire guarantees that the variable is only written to one place in the diagram, then it guarantees that each reader receives the same value -- no uninitialized variables and lightweight synchronization between write and reads.
Global and local variables and other state data can introduce race conditions, but all data accesses are atomic. When reading a global, all writes are locked out, etc.
A subVI can be marked as reentrant or not. By default it is not, and it automatically mutexes so that only one caller is in the code at a time. This is particularly useful to protect global resources to avoid race conditions. If marked reentrant, simultaneous callers will proceed in parallel.
Loops are an easy way to execute code in parallel, but without something to slow down their execution, they will run as fast as possible and can starve out parallel tasks.
Many LV operations are polymorphic -- they operate on many datatypes -- and this can allow for very concise syntax.
LV doesn't support recursion, at least not very well.
LV does have the ability to create objects, protect data fields and methods, and do dynamic dispatching, but it is generally treated as an advanced architectural feature. And the objects are not referenced, but have by-value semantics to work well in a parallel language.

These are the sorts of things I usually try to point out to experienced programmers new to LV. I know some of the lingo is technical, but you have to start somewhere.

Greg McKaskle

Re: LabVIEW for C/C++/Java Programmers
 

I often strongly recommend that newcomers to LabVIEW use "Highlight Execution" (the little light bulb on the toolbar) to watch, in slow-motion, the data (and program) flow from VI to VI.

Very useful debugging and educational tool,
Russ