Best equivalent of an if else statement in labVIEW?

[Disappointed_]

Yeah, I made the mistake of planning everything out with traditional tools in mind, thinking I could just apply them... oh well, onwards and upwards.

However, this tutorial might be appealing...

Thanks!

[JÞB]

Strange enough.   NI once proposed to add an "if then else" structure to LabVIEW.  There were so many better ways too effect the same things in dataflow languages without enforcing sequential rules from other paradigms.  

Altenbach's idea of a cast to array of booleans is about the easiest to implement.

An auto indexed for loop with a conditional terminal is another direct replacement for the cludge known as if then else.  Yup,  it didn't event fit well in text and needed advancements in compilers to run.  One of the few things interpreted languages did easilly.  But, who uses apple basic anymore.

[Disappointed_]

Hmm.. maybe they should, for me. Haha. 

Altenbach's is a really nice solution that is uncluttered and easy to follow. Often, I find my issue just comes from a lack of knowing where to start, or what each block is for, or what blocks are out there, always the issue when starting something new. But, thanks everyone for your help.

When does the LabVIEW NXG get the FORTRAN module I've been waiting for? 

[RTSLVU]

---

@JÞB wrote:

 But, who uses apple basic anymore.

---

Sure, but life was so much simpler then.

[JÞB]

Next year the goto structure might be available too. 😉

[əʞɐſ]

I would use a case structure with the .. operator and a numeric input to the selector. Easy enough with your simple If-Then-Else as well as fast and reasonably scale-able.  

[JÞB]

OK, I really dislike this question when it comes up.... and it does from time to time.  Every time I really want to come back and give a more thorough response but I get lazy usually because the OP found a way to solve the problem at hand effectively.

But, this time the OP phrased the question exactly as "Best equivalent of an if else statement in LabVIEW?  Now somebody else is going to search and find this thread and before you know it an incomplete answer becomes "Common Knowledge" Then LabVIEW gets blamed for handling the problem domain incorrectly when we users failed to find the truth.

Go ahead and TR;DR now if you feel you have to and the simple approaches work in your use case.

lets review the comment by Dissapointed...

how would I achieve this:

if(n>x){

do something.

}

elseif(v>y){

do something.

}

elseif(v<z){

do something.

}

else{

do something.

}

Note that the compared variables are different. I'm not sure I see an obvious way to do this that doesn't require a bunch of cluttered select functions, though that might be the way.

EDIT: Also, the function should "break" on the first condition that evaluates to true.

He is correct!  That is how an If Then Else works (And why its a lot easier to implement in interpreted languages.)  And why they are so difficult to properly debug  An error in an expression deep inside might NEVER get evaluated except rarely.  For instance "only during leap seconds occurring on a blue moon"  Blue moons are the second full moon in a calendar month.  All leap seconds occur at the last second of a month so, if the moon is full during a leap second it will be a blue moon.  The condition is possible! even though extremely rare today.  Worse, it will become less rare in the future (The Earth's rotational velocity slows due to tidal effects .. Measurably)

A perfect example of an edge case "Else" that will grow in probability over time due to whatever we failed to plan for.  Use that as a guide for thinking about the problem domain...Stuff Changes! We seldom need to evaluate that expression but it sure makes for a heck of an edge case

In fact, If any preceding expression evaluates as true we don't need to evaluate this one at all.  Moreover, we no not need to look-up the leap second table published by the USNO and coordinated through France Based on celestial observations made in Greenwich England if there is not currently a blue moon.  Making sense so far? What happens if communications are interrupted or totally missing on the system we deployed this on?  we can't evaluate the expression as true and therefore drop through the code that should have executed and continue (unless we have REALLY good expressions like the following pseudo code

Else If 

ERROR evaluating <"only during leap seconds occurring on a blue moon">? Return Error : expression result;

...

NASTY PROBLEM....

And then there is the overhead of actually evaluating these expressions.

There is no reason that they could not contain items like:

If large Folder full of XML Documents contains at least 1 Large file with the word "Apples" within 300 words of the exact phrase "Garden of Eden" and the word "Eve" but not "Noah"... Get the idea. I don't want to waste the UI Thread doing a regex search inside DOMUserDefRef.DLL on a large list of documents of "Biblical" proportions unless I absolutely must.  So the expressions need to be evaluated as needed and not all at once before selecting the output instruction.  Most examples in LabVIEW omit this portion of the If Then Else construct.

OK Jeff, you ask, How do you get that when you need it?

Thanks for asking.  I usually avoid directly replacing sequential flow constructs within a data flow environment...

But, its possible even if there is not a "All Inclusive" single solution today.

A search through some other threads and advice brings us to this snippet

This ACTUALLY ships with LabVIEW as an example of parsing an expression in Reverse Polish Notation.  It is conveniently titled "Parse Postfix (RPN) String.vi"  A few quick mods to add support for boolean operations and wire the connector pane is an excellent way to "Roll Your Own" expression parser WITH ERROR.  So we have a place to start.

A few edits to add Boolean operation support an we get something that looks like this

2018 introduced released Type Specialization Structures and the Enforce Datatype vis that can make it a lot easier to maintain that "Compare Anything" vi you write as you need.

Enjoy