LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Default of while loop

Hi All,

When I wire a Boolean constant from a Case structure to the Stop button of a WHILE loop, right click on the node on the border of the Case structure, the first option is Use Default if Unwired. 

What is default here and how can I verify it?


Thanks.


hellolv
0 Kudos
Message 1 of 12
(5,931 Views)

The Use Default option only applies to cases where you have nothing wired to the exit tunnel and the default for a Boolean is False. To test this yourself, just create a simple VI like in the attached picture.

Message Edited by Dennis Knutson on 09-29-2006 12:35 PM

0 Kudos
Message 2 of 12
(5,926 Views)
That is the exact reason you'd want to wire every single case.  If it's important enough to be wired to the stop of a loop, then you should know for sure what's going to be coming out of the case tunnel.

To answer your question though, I believe it's false.  Problem is, the default case is more important when case structures are used with say, integers, and you have cases for 1,3,5 and then when it gets a 2, the default will get used.  With a binary input like boolean, the purpose of a default case becomes somewhat moot (which is why it's not specified in the case display bar at the top of the structure).

You cannot supply a default for something that will only ever have two inputs.  It's either one or the other.  This begs the question - why is the "use default if unwired" is available when a case structure is wired as true/false?

Message Edited by Day on 09-29-2006 02:38 PM

0 Kudos
Message 3 of 12
(5,920 Views)

I wouldn't do that.  It is underterministic.  You may not be able to control / stop the while loop.  I'm not sure what the default is or what it could be...  However, imagine the scenario where both cases of the Case Statement would provide an identical value... Let's pick "True" for instance.  You use the default value of "true" for the false case & and "True" for the true case, but select Run while true!

 

Message 4 of 12
(5,919 Views)
"Use default if unwired" is a very useful feature, especially if you have many cases, it is also somewhat dangerous IF you use it without understanding, e.g. just to "fix" a broken run arrow. 😮
 
This feature is even enabled by default for output tunnels in event structures. Here I often have a STOP event where a TRUE is wired to the loop termination terminal. In all other cases I don't want to stop and the feature allows me to not wire an output from these cases, saving me some effort. I know it will be FALSE as desired.
 
An unwired output tunnel gives you the default for that particular datatype (False for boolean, zero for numbers, empty array for any array, etc.) and this is often sufficient.
 
Some examples posted here over the years showed improper use. For example if you don't wire a fileref across all cases and then try to close the file afterwards, it will not close if the fileref gets reset to default in one of the cases. Similarly, if you build an array in one case via a shift register in the big loop and forget to wire across all cases, you'll blank it out back to zero lengh at times.
 
 
Long ago on Info-LabVIEW, I posted some enhancement suggestion about this feature. I still think that could be useful.
Here's the text of my old post:

I would prefer a even more flexible solution: Make a special, usually
hidden case with a name such as "_default outputs_". For example, you
would right-click on the case and select "define default outputs". Now
you see a case that has a different color. Here you can wire away and
define what the output terminals should receive in all the "regular"
cases *if* they are not wired. Only outputs you don't wire here would
receive the default for the data type as we have now. By default, this
case is empty, duplicating the current behavior for unwired outputs.

In your very special case, you would connect the desired input and
output tunnels across, but now the possibilities are truly endless.
Now you also have the opportunity to do math, e.g. insert a [+1],
[-1], etc as often needed. One output tunnel could receive a special
wired constant (1, -100, Inf, NaN, etc.) that would be more suitable
for the particular situation than the default for the data type we
have now. One output tunnel could receive a mathematical result of
multiple input tunnels.

Just some ideas ... (We can dream)
Christian Altenbach

 
 
Message 5 of 12
(5,893 Views)
Sorry to resurrect this ancient thread but I was searching for topics on the Use Default if Unwired function of Case Statements and Event Structures and noticed this post by altenbach

altenbach wrote:
Long ago on Info-LabVIEW, I posted some enhancement suggestion about this feature. I still think that could be useful.
Here's the text of my old post:

...

Did this ever get implemented into a newer version of LabVIEW and if so, which? Also, with particular reference to an Event Structure I am using, how would I create/simulate a pre-determined default value for use when unwired?

 

James



Never say "Oops." Always say "Ah, interesting!"

0 Kudos
Message 6 of 12
(5,444 Views)

James Mamakos wrote:

Did this ever get implemented into a newer version of LabVIEW and if so, which?


No, we don't have this. My plan is to write it up into an idea.

 

(Don't steal the idea and post it yourself, give me a few days!! :D)

 

 

We have a primitive, watered down enhancement with the "linked output tunnels", which is not quite the same. If you want non-standard default values, you're out of luck. You need to wire each instance.

Message Edited by altenbach on 06-29-2009 09:16 AM
0 Kudos
Message 7 of 12
(5,438 Views)

Right-oh. Thank you for that. I'll let you post the idea and in the mean time, i'd best get wiring! 😞

 

Make way for the venerable constant! Smiley Surprised

Message Edited by James Mamakos on 06-29-2009 06:07 PM


Never say "Oops." Always say "Ah, interesting!"

0 Kudos
Message 8 of 12
(5,425 Views)

The idea Altenbach is referring to was eventually posted here.

Not sure why it did get more kudos yet...

Message 9 of 12
(4,183 Views)

Good thing we were all sitting around discussing what happened with that post 5 years ago. 😛

0 Kudos
Message 10 of 12
(4,159 Views)