Empty Tunnels on Cases

[Mule]

Mmkay, I'm not very proficient in LabVIEW, so it could simply be that I don't know how to do this.

But let's say I have a T/F case structure. Variable X enters the structure.

On true... Variable X recieves some manipulation and leaves the case structure and goes... somewhere. On false, I want varible X to die. I don't want it to be transmitted to the next case.

In other words, I wish that tunnels did not have to be filled in all cases. They don't have to be filled when using standard "type it out" programming (or at least, I've never had to). In fact in programming I often use the "type it out" version of a case structure to kill off a variable.

[Yair]

The variable can't "die" or disappear, but you can right click the output tunnel and set "Use default if unwired" and this will cause the wire to recieve the default value for it's data type for every case where you didn't wire it.

[Louis Manfredi]

Hi Mule:

I'm not totally sure what you mean by a variable "dying." If a wire comes out of a case structure (or from any other source), it has to have a defined value. Whatever the wire is hooked up to needs to have some value associated with the wire. Much like the a function in a text language always returns a value-- the value might be a default, or a random unkwown, but there is a value.

There are, however a couple of suggestions I can make:

1) If you want, you can right click on the box where the wire leaves the case structure, you can select "Use default if unwired" If a case executes which doesn't have the box wired from inside, the output will be the default value for the variable type. (zero, false, empty string, whatever...) This is ocassionally useful, especially with state machine architectures, for example providing the value to the stop terminal of the loop.

2) If you really don't need a value for wire except in one particular case of a case structure, you should be able to move the code that uses the wire to inside the case structure-- without the wire heading out of the case structure, there is no problem with what happens in other cases.

Hope this helps, Louis

[Mule]

2) If you really don't need a value for wire except in one particular case of a case structure, you should be able to move the code that uses the wire to inside the case structure-- without the wire heading out of the case structure, there is no problem with what happens in other cases.

Hope this helps, Louis

Wow - I thought as soon as I said I was a beginner to LabVIEW that I would get flamed!! It's very refreshing to deal with mature people on a forum!

The problem is that it if has to leave the case structure at -any- time, then I need to have something for my False condition as well...

Hence - my wish is "Let us have empty tunnels on certain cases" - Of course, I honestly have no idea how hard this is to code into LabVIEW. And when I say that I mean... "I have no idea how hard this would be for NI to add to the next release."

But I think it would make many aspects of programming much easier.

Here's another example where it might come in handy

Three structures

A - a T/F case structure

B - a While loop

C - a Whlie loop

Variable X enters loop A

if A is true, route X to loop B

if A is false, route X to loop C

This would require two empty tunnels (one on A.True, and one on A.False), which means it's currently impossible. However, if in a future release it WERE possible, it would make programming easier. At least, in my eyes (for what thats worth).

And thanks again for patience with me and my lack of experience. But it certainly seems like this is an excellent place to share ideas and learn from experienced LabVIEW programmers. Heck I might even stay in touch with this place in the 3 months of school I'll have between internships! =D

[DredPirate]

You could also use a local variables or functional (LV2 Style) globals to pass your data within a case structure to your loops. That way you wouldn't need to send a variable out. And would more closely resemble you line baised equvilant.

[Mule]

You could also use a local variables or functional (LV2 Style) globals to pass your data within a case structure to your loops. That way you wouldn't need to send a variable out. And would more closely resemble you line baised equvilant.

Umm thanks! I honestly don't know exactly what that means, but... I'm going to go look up some terms, find some examples and see if that works out like im talking about. =D

However, to the suggestion - are there specific limitations in LabVIEW itself that say "No you can't do this?" Obvisouly in the current versions there is, but why I wonder. Why must EVERY tunnel be connected in EVERY case. That just doesn't seem flexible to me. Any reasons why not to make the program more flexible?

To paraphrase Dilbert "Our prototype could turn into a monster that anahilates the galaxy" *he goes home* "Apparently I don't know what -worst- means". Hehe...

[Louis Manfredi]

However, to the suggestion - are there specific limitations in LabVIEW itself that say "No you can't do this?" Obvisouly in the current versions there is, but why I wonder. Why must EVERY tunnel be connected in EVERY case. That just doesn't seem flexible to me. Any reasons why not to make the program more flexible?

Hi Mule:

LabView is really quite flexible as it is, but like any programming language, it has a few invariant rules that are necessary for the logical structure of the language.

In the graphical data flow model of programming on which LabView is based, every wire has to have a source for its data in every possible state of the program. Its central to the very core of what the language is. I can't take the time to go into all the details here-- But, for example if a wire doesn't have a source, the language can't even know when to execute the code connected to it.

It works out that this isn't a real burden once you get used to dataflow programming. Spend some time looking at the examples that ship with LabView, and try not to think in terms of using the language in the same way you might use a text based higher level language, or even how you might use assembler for that matter.

As a convenience, you can choose that all unwired cases are set to the default for the data type, but that is simply a shorthand in place of explicitly feeding a default value to the wire's terminal in all the cases where you want the default. Even that shorthand tool is a recent addition to the language and I think you would be surprised how few cases there are where a well-organized LV program will use that capability. (Offhand, about the only place I use it is to feed a boolean value from the case structure to loop stop button of a state machine.)

Best Regards, Louis

[Mule]

Well, this brings me back to my orginal assumption - I guess I just need more experience! =D Luckily, I'm a fairly quick learner, and if this thread is any indicator to the attitudes I'll recieve if I have other questions or comments, than I've certainly come to the right place!

Of course, there is something that is going to be quite difficult. In about a month, I'll be taking a class in JAVA. So, I have a month to set aside my text-based mindset, then 3 months of setting THAT down, and then coming back to work ready to dive into LabVIEW again.

Of course, I'm only a college freshman right now... but I imagine I can expect to be tossed around from platform to platform the rest of my career - no wonder my father (a CCNA) said stay out of any computer field! (Hehe)

Well, thanks for your support and your valuable input on the matter! Although I don't still don't quite understand WHY the tunnels must be filled on everycase, I'm not so stuborn that I won't succomb to the logic of an advanced user =). In fact, I'm sure if you tried to explain it, I wouldn't yet have enough background to properly understand it anyway.

Thanks again, guys!

~Mule

[Louis Manfredi]

Of course, there is something that is going to be quite difficult. In about a month, I'll be taking a class in JAVA. So, I have a month to set aside my text-based mindset, then 3 months of setting THAT down, and then coming back to work ready to dive into LabVIEW again.

Hi Mule:

Don't worry too much about the differences between text langauges and LabView-- At the heart of it all, computers is computers--

The most important aspects of programming in any language are common to all languages--

Be sure and understand, and document, what the user wants before you begin(even if the user is you).

Spend some time understanding what the inputs and outputs should be.

Spend time breaking the project down into logical chunks (subroutines, subvi's, modules, whatever) that each perform a certain task, and that can be easily tested individually before assembly into the whole (That's easier with LV than with most text languages).

Look around to see what tools are available in the language core, in your own past work, or in the work of others which you can apply to the problem to avoid re-inventing the wheel. ('cept of course don't cheat on your homework or steal stuff you haven't the right to use...)

Test and document as you go along. LabView is not self documenting, no computer language is! Once you try to do anything more than the most trivial task, in any language, you need to put some up-front effort into explaning what you're doing. Otherwise you'll be scratching your head trying to remember what the heck you had in mind when you go to modify it a few months down the road- (This happens to me all the time.)

Perhaps most important, remember that computers (almost) always do what you tell them to do, not what you want them to do. Once you accept the idea that its much more likely that problems are caused by differences between what you want and what you told, not by differences between what you told and what the darn thing actually did, debugging gets a lot less time consuming.

At any rate, good luck in the studies, Louis

[Mule]

Thanks.

I read in a recent tutorial (that I believe was linked from this site =D ) something I've always tried to do with my programming, and that is do your absolute best not to Design as you Plan.

However, here's my basic assignment right now: Learn LabVIEW by making a program, and adding features that you don't konw what they do and figure it out, thus increasing your experience.

This seems like a highly illogical approach, and that's what brought me looking here. For example, I had been coding a program that moved a "worm" around a waveform graph (graph manipulation, boolean logic, lots of applicable learning experiences), but eventually it started hogging 97% of the available CPU power (and I'm on Dual Pentium 3.0Ghz's!!). I can't find where the resources are being hogged, but I'm not going to waste your guy's time with the VI because, well you've got better things to do than fix my worms. (That's the wieredest thing I've said today...)

However, since I recieved the suggestion of reviewing the examples that came with LabVIEW, and surfing these forums for new and old relavent materials that I can understand/decypher (don't worry, I won't bump old threads ;-p ), I think I'm absorbing the LabJUICE at least twice as fast as I was before, wading through it on my own. =)

Back I go to work the wires

~~ Mule |