LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Darren's Weekly Nugget 03/23/2009


@Phillip Brooks wrote:
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...

 


Thanks for the feedback, Phillip.  I have forwarded it on to the Customer Education department.  I agree that there are some legitimate use cases for Use Default if Unwired.

DNatt, NI
Message 11 of 24
(1,729 Views)

Darren wrote:
...

Thanks for the feedback, Phillip.  I have forwarded it on to the Customer Education department.  I agree that there are some legitimate use cases for Use Default if Unwired.


Please forgive me for being so bold but you could you also tell them that "It is OK to use decorations in a diagram (like an arrow to conect a comment to a part of the code)?"

 

and if you are willing to pass that one along then please add...

 

"It is OK to use red comments to document your diagram."

 

I ask because I lost points on both of those issue the first time I passed the CLD.

 

Ben

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

Ben,

 

I forwarded a link to this thread to them, so they'll get your feedback too.

DNatt, NI
Message 13 of 24
(1,721 Views)

Darren wrote:

Ben,

 

I forwarded a link to this thread to them, so they'll get your feedback too.


 

Excellent!

 

Then I will hope the community keeps me honest and voices why any of these ideas should be ignored.

 

Here is another one;

 

"It is OK to invent my own architectures so If I design an app that does not fit into the standard set of designs like "Producer/Consumer", "Master/Slave" I should not loose point for exploiting LabVIEW's power and flexibility."

 

"Name prefixing is no longer required." ... Since libraries implement name mangiling and using "name spaced" VI reduce their potential for re-use elsewhere.

 

Ben

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

Darren wrote:

 

  • 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.


 

Be very careful about this one.  As discussed in this thread, documentation of this is confusing and in some cases incorrect.  It appears that assuming the VI can be found, the above example would actually load the VI into memory in LabVIEW, but not in an EXE.  Even in the case of the diagram disable structure, LabVIEW loads the VIs into memory, which can cause you significant problems when you expect that the code is not loaded into memory (or conversely, that the code is in memory in LabVIEW, but disappers in the EXE)

 

The new feature is very advantageous for broken code, as Darren's example shows.  But any code in the module does apear to load into memory in the development environment.  In the case of the the thread referenced, this was causing code to function improperly in LabVIEW, although the code worked as expected after being compiled into an EXE.

Message Edited by Matthew Kelton on 03-24-2009 01:58 PM
Message 15 of 24
(1,693 Views)

Ben wrote:

 

"It is OK to invent my own architectures so If I design an app that does not fit into the standard set of designs like "Producer/Consumer", "Master/Slave" I should not loose point for exploiting LabVIEW's power and flexibility."

 

"Name prefixing is no longer required." ... Since libraries implement name mangiling and using "name spaced" VI reduce their potential for re-use elsewhere.

 


Well said Ben,

 

A new thread should probably be started to discuss CLD exam improvements as this one is dedicated to this week's nugget. 

🙂

Message 16 of 24
(1,660 Views)

Hi Darren

 

My I say, I have enjoyed reading all you nuggets over the last year or two and the case structure series has been interesting.

 

This may be an out of place location to make this suggestion but I think that this series of nuggests would make a really good entry for the LabVIEW Wiki, it full of stuff we all know (well think we know) but often forget bits of and that would be great place for a quick lookup of the facts.

 

thanks anyway 

 

Dannyt

Danny Thomson AshVire Ltd
0 Kudos
Message 17 of 24
(1,592 Views)

See this post on Darren's blog.

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 18 of 24
(1,506 Views)

I found that "Use default if unwired" is very misleading. Correct me if I am wrong, but my understanding is that 

 

1) in a CASE structure, the "default" is the value wired in the "default" case (if it is wired), otherwise, it is the default value of the particular data type.

 

2) in a Event structure, the default is the default value of the particular data type (very dangerous and useless to use).

 

I would like to suggest to NI an option of "Use input of the default case (or default event for Event structure) if unwired".  Like a CASE structure, a default EVENT needs to be defined in an EVENT structure. If an output terminal is unwired, it would take the data from the default Case/Event of the Case/Event structure. 

 

This would be really handy for cleaning up wiring diagrams.

 

Ian 

     

0 Kudos
Message 19 of 24
(1,315 Views)

Ian Ren wrote:

I found that "Use default if unwired" is very misleading. Correct me if I am wrong, but my understanding is that 

 

1) in a CASE structure, the "default" is the value wired in the "default" case (if it is wired), otherwise, it is the default value of the particular data type.

...

Ian 

     


Smiley Surprised 

 

I just tested it and the case struture return the default of the data type not that value found in the default case.

 

You had me scared for a minute there.

 

 Smiley Wink

 

Ben

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