Basic Labview Programming Questions

[comphappy]

Originally Posted by RyanCahoon

I don't mean to discourage you if you really want to try it, but you're probably ahead to use the image processing framework included with LabVIEW. Trust me... LabVIEW really isn't the "easy way out" for programming.

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.

[RyanCahoon]

Originally Posted by comphappy

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.

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.

--Ryan

[Greg McKaskle]

Originally Posted by comphappy

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.

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

[Kevin Sevcik]

Originally Posted by comphappy

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.

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.

[comphappy]

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.

[Greg McKaskle]

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

[JBotAlan]

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...

JBot

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?

[Russ Beavis]

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.

Russ

[Greg Needel]

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.

[Greg McKaskle]

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

[Bomberofdoom]

Originally Posted by Greg McKaskle

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.

Kind of like Round Robin?
http://en.wikipedia.org/wiki/Round_robin

Originally Posted by Greg McKaskle

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.

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?

[Greg McKaskle]

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

[Jon236]

Greg,

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!

[Jon236]

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

http://zone.ni.com/reference/en-XX/h...pts/checklist/

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

[PhilBot]

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.

http://zone.ni.com/devzone/cda/tut/p/id/7466

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

Phil.