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