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

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

[tivomatic]

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. . I have attached the vi.

Thanks.

[Joe Ross]

Originally Posted by tivomatic

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. . I have attached the vi.

Thanks.

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.

[BitTwiddler]

Originally Posted by Joe Ross

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.

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.

[Kevin Sevcik]

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.

[Alan Anderson]

Originally Posted by Kevin Sevcik

But seeing Bubble Sort implemented in Labview seems very very wrong to me.

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.