LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Darren's Weekly Nugget 03/23/2009

This nugget is the fifth and final in a series of nuggets on Case structures.  Today I will discuss some miscellaneous tidbits that are helpful to know when using Case structures.

 

Case Structure Miscellany

  • In LabVIEW 8.6, the Linked Input Tunnels feature was added.   This feature allows you to link an output tunnel to an input tunnel of a multi-frame structure (Case Structure, Event Structure, Diagram Disable Structure, etc.).  So when you create a new frame in the structure, the two tunnels are automatically wired together.  Additionally, if you create a new input/output tunnel pair, you can have wires created automatically for every existing frame in the structure. I really like this feature, especially when dealing with structures containing many frames, like state machines or Event structures in UI VIs.
  • Another tunnel feature that's been around a lot longer (since LabVIEW 6.1) is the "Use Default if Unwired" option on output tunnels.  Some people think this is a dangerous option because you're not explicitly setting values for each case, but I find many situations where the option is quite convenient.  Especially since I use an error case structure in most of my VIs, it's very handy to not have to worry about wiring anything in the Error case.
  • Here's something you may not have known...check out this VI:



    There's no trick photography here...that is a missing subVI, but the VI is not broken.  This is because of a change in LabVIEW 8.2, where the contents of unexecuted frames of case structures whose selectors are wired to constants are not compiled.  Keep this in mind when doing things like putting VIs in a case structure that won't execute just to keep the VIs in memory...they may not actually be loaded at all.  There is a VI Analyzer test called Unused Code that will detect places in your code where you have wired constants to case structure selector terminals.
  • You can reorder the frames in a Case structure with three or more cases by right-clicking the case structure frame and choosing Rearrange Cases.  In the resulting dialog, you can drag frame names around in the list to place them in the order of your choosing.
  • When you print the block diagram of a VI, either interactively through File > Print or programatically with the Report Generation VIs, you can choose to include "hidden frames" in your printout so that the contents of all frames of Case structures, Event structures, etc. are included in the printout.

And if you're sick of hearing about Case structures, there will be an all new non-Case structure-related nugget next week!
Message Edited by Darren on 03-23-2009 12:42 PM
Message 1 of 24
(8,549 Views)

Darren wrote:

...

  • Another tunnel feature that's been around a lot longer (since LabVIEW 6.1) is the "Use Default if Unwired" option on output tunnels.  Some people think this is a dangerous option because you're not explicitly setting values for each case, but I find many situations where the option is quite convenient.  Especially since I use an error case structure in most of my VIs, it's very handy to not have to worry about wiring anything in the Error case.
  • ...

Error case are one of the situations where "use default if..." option is generally OK assuming the down stream code handles the error.

 

But "use default if unwired" is bad for State Machines and Event structures if that tunnel is holging a reference.

 

The "BAD" part of using them in Stae Machines or Event structures is that the code will be fine until that one case where someone did not wire the ref across executes and now stuff that seems fine most of the time simply does not work.

 

I speak from experience about the above exception. One of my rookies set the tunnel as a default and at some latter date another rookie added another Event that was only used once in a blue moon. So the app ran fine until "blue moon" time kicked in and now file writes are throwing errors. Start over everything was fine.

 

AS a result if anyone asks me to look into a "weird" problem that only happens every now and then, "Use default.." is on my short list.

 

So....

 

Ask yourself the question "what would happen if this data was bogus?" before setting tunnels to "Use default if ..."

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 24
(8,531 Views)
Ben's comment could also be applied to tunnels in For Loops.  When auto-indexing an input array, the loop executes 0 times when the array is empty.  So, use a shift register in lieu of tunnels when passing a reference (or other data) through the loop, even if the wire is simply a "pass-through".

Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Message 3 of 24
(8,514 Views)

Ben's situation is also mitigated when using Linked Input Tunnels, since new frames will automatically wire-through those tunnels.  I have gotten into the habit (as any LabVIEW 8.6+ user should) of making any state wire an auto-linked tunnel in all my state machines and UI event structures.

0 Kudos
Message 4 of 24
(8,512 Views)

Darren wrote:
...
  • Another tunnel feature that's been around a lot longer (since LabVIEW 6.1) is the "Use Default if Unwired" option on output tunnels.  Some people think this is a dangerous option because you're not explicitly setting values for each case, but I find many situations where the option is quite convenient.  Especially since I use an error case structure in most of my VIs, it's very handy to not have to worry about wiring anything in the Error case.


In the real world, "Use Default if Unwired" is reasonable (see Ben's exceptions); but readers should be aware that you will absolutely lose precious points on the CLD exam if you leave output tunnels "Use Default if Unwired". I've taken the CLD twice, and lost points both times for this. The second time was the difference between passing and failing for me.  After that, I started looking at the various libraries that ship with LabVIEW and found that "Use Default if Unwired" was quite prevelant.

 

If NI can continue to ship code that uses this technique, why are customers dinged for doing the same thing?  Sorry to rant, but this is the reason I won't the CLD again. Maybe if I take it using 8.6 and configure Linked Input Tunnels, I might pass; but I've lost interest in certification at this point...

 


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Message 5 of 24
(8,400 Views)

I think thatthe "Use Default" causes more problems than it solves.  I try to never use this feature but sometimes it creeps in.  I wish there was a setting to turn this feature off.

Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
Message 6 of 24
(8,383 Views)

I use "Use Default" mostly in one case: stop condition boolean for the while loop around an event structure. In most cases the loop shouldn't stop, so the boolean default (False) is fine. For those cases when it should stop (for instance the value change event on the Stop button) I wire it up. Except for this use case I don't use this feature very often.

 

Daniel

 

Message Edited by dan_u on 03-24-2009 01:43 PM
Message 7 of 24
(8,355 Views)

dan_u wrote:

I use "Use Default" mostly in one case: stop condition boolean for the while loop around an event structure. In most cases the loop shouldn't stop, so the boolean default (False) is fine. For those cases when it should stop (for instance the value change event on the Stop button) I wire it up. Except for this use case I don't use this feature very often.

 

Daniel

 

Message Edited by dan_u on 03-24-2009 01:43 PM

Good point!

 

I use it in those cases as well and its much better than those silly constant people used to wire in through the corner for all non-stopping cases.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 8 of 24
(8,351 Views)

Darren wrote:
  • There's no trick photography here...that is a missing subVI, but the VI is not broken.  This is because of a change in LabVIEW 8.2, where the contents of unexecuted frames of case structures whose selectors are wired to constants are not compiled.  Keep this in mind when doing things like putting VIs in a case structure that won't execute just to keep the VIs in memory...they may not actually be loaded at all. 
Message Edited by Darren on 03-23-2009 12:42 PM

 

That's interesting.  I didn't know that one.

 

Thanks Darren!

Message 9 of 24
(8,350 Views)

LOL

 

I have also noticed sometimes new users will use "default if unwired" and it passes something out of the case structure that they are not expecting because they don't know what the default actually is. Something to watch out for.

Message Edited by for(imstuck) on 03-24-2009 08:15 AM
Message Edited by for(imstuck) on 03-24-2009 08:16 AM
Message 10 of 24
(8,332 Views)