Showing results for 
Search instead for 
Did you mean: 

NXG - Tips, tricks and traps of if/then and if/then/else structures?

As a text based programmer I am having a hard time adjusting to building complex if/then/else statements and nested if/then else. One issue I am having is it is possible in text based to have an if...then without the else. In LabView you can only do this if you use a case and place your action true case and do not use a tunnel. If you use a tunnel then you have to either define what happens in the false case or select "wire if default".


I guess I am hoping that folks will weigh in here and share tips, tricks and traps for building if/then and if/then/else and nested combinations of if statements. Any tips to share for new users of NXG (Standard LabVIEW tips may also apply).

0 Kudos
Message 1 of 6

I think what you might be having problems with is the way "variables" are translated.


It can be easy to think that a "variable" in text code is equivalent to a control or terminal in LabVIEW.  But that's not how it works.


You need to think of the wire as the variable.  And that each time a wire enters and exits a node, that's changing the value.


So when you use the closest equivalent to the "If" construct, i.e. the case structure, and you want to do "nothing" in one case, then what you need to to is find the wire containing the "unchanged" value of whatever was modified in the "not nothing" case, and wire that straight through.... or create a constant output if that's more appropriate.  Or you can use the "Use default if unwired" option if having a "zero" output from all "nothing" cases is what you want.

0 Kudos
Message 2 of 6

Just as a text based language has an alternative to "if/then/else" called a "select case statement", so to does LabVIEW - the "select case" structure.  Usually you can convert your nested if/then/else stuff into something where you do not need nested case structures.

(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 6

@flycast wrote:

If you use a tunnel then you have to either define what happens in the false case or select "wire if default".


You don't have to specifically use tunnels.  You can use Local Variables.  They are just as effective.  You do have to be careful with them of course.  But if only a single case updates a value, then throw the local variable into that single case.  Unless of course you're running shift registers and everything is getting passed around and you enjoy all your data being crammed into a single cluster that you access. (Pros and cons to this method)


But if you think of the situation you described in text based, what you've done with the tunnel is the following:  ( And I do know you understand all this)


If (THING) {

X = Y


Else { 

X = Z



If you use a Local Variable it will give you

If (THING) {

X = Y


Else {


0 Kudos
Message 4 of 6

Pros and Cons to these Methods.  Comes down to situation.


0 Kudos
Message 5 of 6

Only use locals when really needed. 

Speed is one issue but normally not a problem.

Readability is another.


your second example looks more readable without clicking this way2020-11-10 19_41_59-Lightroom.jpg

greetings from the Netherlands
Message 6 of 6