Basic Labview Programming Questions

No it really it not, from what I have been experimenting with for the last 3 months it has been the hard way to program robots. I am finding while signal processing will be a snap and perhaps the vision stuff as well. Effective drive code that may be oh 300 lines of straightforward C is turning into a convoluted mess of lines and VIs. Just creating a toggle variable (need a 1 and then 0 to do a ~) in C is a few simple lines, just try it in Labview it is a mess.

While I am training the rest of the underclassmen who are doing programming labview as it connected with the NXT and RXT stuff that they are already learning, I think I might just be writing this years code in C.

While I am amazed at what LabView can do (really I am), I am also shocked at what it does inefficiently.

CImg should run on the VxWorks stuff I would think, but I am waiting to see what comes out of WPI before I embark on that. We should know soon as the beta teams progress.

Heh not my original intention, but I do understand what you mean. Changing programming paradigms can be an unsettling undertaking. Any language that can automatically implement parallelism without me having to do anything gets some nice remarks in my book though. The overall theme is you trade detailed control for prebuild high-level functionality; same transform that’s been going on since compilers were first invented. To each his/her own. Good luck with your learning.


This isn’t the appropriate thread, but if you want to discuss other ways of doing things in LV, I’m game. It will be a learning experience for many if you are willing to pose the questions.

But I don’t really know what the issue is with the toggle variable. I think you just want a shift register with a negate, so that each loop iteration produces the opposite of the last iteration. You can also do this with a feedback node.

It really shouldn’t take lots of messy C or LV code once you have the hang of the languages. I’m happy to answer LV questions here or on other forums.

Greg McKaskle

I’m assuming this means you wanted to toggle some value from 0 to 1 to 0 only when some other value changes from 1 to 0. If so, the LV code is pretty easy. See the attached picture and VI. I don’t think LabView is necessarily less efficient than C++, but it requires a very different mindset to get efficiency out of it.

Toggle.JPG (8.15 KB)

Toggle.JPG (8.15 KB)

it was not my intention to hijack the thread so sorry for that, some of the words clicked and off I went.

That VI was similar to what I came up with in the end, but it is still much larger then the c code for the same thing. I am just finding that I do a lot more of this type of low level variable manipulation stuff in robotics then I do signal processing, but that my change we will see.

Not to continue the hijack, but the reason that the signal processing may seem cleaner implementation is that they often flip the state storage from the outer diagram into the subVI. As an example, if a filter has state, it is possible to require the caller to be responsible for the state, pass it in, update it, pass it back out, etc. This is totally legal, but since it spills out on the the top diagram, it just ends up looking messier. It also exposes the important state info in a way that it can be mucked with unnecessarily.

To tidy things up a bit, the state is kept within the subVI, which is usually made reentrant so that the states from different calls don’t mix. So, to apply this idea to the Boolean toggle, you make a subVI from the whole thing, one Boolean in, one Boolean out. You have to figure out a name that represents it well, and you end up with something that works well in more complicated diagrams. The only subtle difficulty to this is the initialization.

Greg McKaskle

Continuing to threadjack…

I really have been trying my hardest at this LabVIEW stuff, but I can’t seem to get even the simplest code working. I am not at my laptop at the moment, so I can’t post screenshots, but I tried to make a timed loop add 1 to a variable each second and output it to an indicator. What, exactly, am I doing wrong? “i” gives me the increment; that’s working fine. But this isn’t.

I could go through all the tutorials in the world and still be in the dark…


EDIT: Oh. If I put the indicator inside the loop, things work. But why doesn’t that value get sent out the shift register? Does it when the loop stops?

test vi.PNG

test vi.PNG

The output isn’t updated until the timed loop finishes execution. To help visualize the data flow, I would strongly encourage you to use the “highlight execution” debugging mode (the little lightbulb on the toolbar) to “see” how the program is executed.

“Highlight Execution” mode and wire probing (including the use of graphs) are, IMHO, a VERY useful set of debugging features in LabVIEW. You gotta check 'em out.


This thread is intended for users to post questions on how to do things in labview. Posts in this thread were merged from another thread which changed direction.

I think you are making progress. As with any language, you are starting to get into the details a bit.

Structures such as loops, cases, and sequence structures contain subdiagrams – just like the top level diagram or the diagram in a subVI. The primary difference is that subdiagrams synchronize the inputs and outputs using tunnels and shift registers.

Some basic laws of LV execution.
When a diagram executes, all objects on the diagram execute once honoring dataflow between nodes. Breaking this down a bit, this means that no node can execute again until all other nodes on the same diagram have finished executing. It also means that no nodes will be skipped.

Structures are nodes which own one or more diagrams. Structures generally differ in how they schedule their subdiagram(s). Sequences execute them one after the other. A case structure executes just one of the subdiagrams. And the loops execute the diagram repeatedly, according the loop logic.

Data flow wires have a few laws too.
A wire has exactly one source and one or more data destinations. The job of the wire is to deliver the same value from the source to the destinations.

Getting to the point of your question, when a wire leaves a diagram, via a tunnel, sequence local, or shift register, the wire ends, and on the other side, well, that is another wire.

A node cannot begin executing until all of its inputs have arrived, and it cannot put data on a wire until it has finished executing.

Since, a loop is a node, when it begins execution it latch data from the outside wires to the inside ones. When it finishes, the data on the inner wires will be copies to the outer downstream wires.

Sorry if this is abstract, but these are the LV language’s grammatical rules. And grammatical language discussions tend to be abstract.

Greg McKaskle

Kind of like Round Robin?

So, if I use JBotAlan’s VI, inputs to the VI come from the down-arrow, flow through the VI/Sub-VI in the blue wire. Whatever is TAKEN from the wire (before it is changed later on) gets the data from the wire (the initial input).
If a data is GIVEN to the wire, then this data flows out of the VI and reaches the upwards-arrow, which is the output of the VI.

I’m wrong, right? :o

Kind of like Round Robin?

Sort of. LabVIEW does do scheduling using round robin, but nothing is inherently rescheduled, that is what loops are for. It is also possible for a flat diagram, no loop, to execute things once and they don’t go again.

So, if I …

I think you have the idea, but not the terminology. The VI is the whole loop and everything. The blue box is a loop, a special sort of loop that is capable of all sorts of timing stuff. The down arrow and up arrow are called a shift register. It is a feedback mechanism so that one iteration of a loop can give data to the next iteration. But yes, branching the wire on the left gives the original data, on the right, after the +1 gives the new data.

To relate the original issue to C, If you put a printf() inside of a loop it executes each time the loop does, displaying i. I you place it after the loop, it executes once, displaying the last i. The terminal of an indicator is sort of like calling printf to display data.

Greg McKaskle


I wonder if you and the other LV experts can begin to comment on ‘proper’ LV programming techniques. That is, I have noticed that it is possible to do about anything you want (such as using Global Variables) to make the program work. But some of these methods may lead to code that is difficult to debug.

I want to thank you for all your input and help you are giving the teams!

After asking Greg the question, I found this on the NI site:

It is very useful and I suggest the team programmers go over it thoroughly!

The best 30 minutes I ever spent was going trough JUST the video presentations on this page.

Spend 30 minutes to save yourself 30 hours.

You’ll not remember it all, but you’ll know where to go back to refresh your memory.

That was untill their site went down tonight for some unknown reason :frowning:


I am trying to write a Labview vi that takes a one dimensional numerical array, for example A= 5,4,3,2,1, and sorts the values in ascending order. We do not want to use the sort array operator since the whole purpose is to practice using labview. Although I can write this no problem using Basic, I am having trouble in Labview. :confused: . I have attached the vi.


Sorting (10.4 KB)

Sorting (10.4 KB)

I’ve attached a version that does what I think you want. The main thing you needed was a shift register (or feedback node) to take your changed array and feed it back so it could be operated on. The way you had it, each loop it was always operating on the original array. I must admit that this has been the thing I’ve messed up the most in LabVIEW.

You’ll need another loop of some type to finish sorting. You can also use the array size VI for the input to the count terminal input of the for loop.

Sorting (11.2 KB)

Sorting (11.2 KB)

Taking Mr. Ross’ vi a bit further, I’ve modified it to swap array elements without overwriting the ith array element. Still needs another loop to control the number of passes through the array in order to propagate all of the changes each pass makes.

Sorting (13.2 KB)

Sorting (13.2 KB)

Well that last VI is mostly correct, aside from either a second FOR loop to run it n-1 times, or a while loop that will stop if it didn’t make any swaps in the last run of that inner FOR loop… But seeing Bubble Sort implemented in Labview seems very very wrong to me. There’s a reason NI has VIs like this already made, after all.

I enthusiastically agree. Bubble Sort is a highly procedural algorithm, something which LabVIEW does only grudgingly. I wonder if a Partition Sort would more closely align with LabVIEW’s data-flow nature.

But I think sorting is the kind of operation that should be implemented by people having deep knowledge of the runtime environment, and not used as an exercise in learning how to use a data-driven programming language.