Darren's Occasional Nugget 05/18/2007

Reading Jim's post about loop debugging on this LAVA thread reminded me of a similar trick I do with Event Structures.  In my event-based UIs, I always wire the iteration count of the While Loop containing my Event Structure through to the inner border of the Event Structure, like so:
I also deselect the "Use Default if Unwired" option on the output tunnel...that way when I create a new Event case, the VI will be broken, reminding me that I need to wire the iteration wire through on the new case:
Now, the reason I do this little trick is to help when debugging the execution order of events for my event structure.  In my current project, I've got mouse events firing all over the place...Mouse Move, Mouse Enter, Mouse Leave, Mouse Down, Mouse Up, Shortcut Menu Activation, etc.  Sometimes I really need to know the order in which certain events executed...to do this, I can probe these iteration wires within the event cases that interest me, and by comparing the values of the iteration counts, I can easily determine which events fired first.  If the events are firing multiple times and I want a history of their firing order, I can use my home-grown History Probes (see my previous Nugget on this topic).
-D
P.S. - Check out past nuggets here.
Message Edited by Darren on 05-18-2007 10:41 AM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
iteration_wired_through.png ‏1 KB
use_default_if_unwired.png ‏2 KB

Ah - logging. That's always a nice topic .
I always use a simple selfmade library. So I can get rid of breakpoints (most of the time) and still can "debug" code when it is built as an exe.
Here you can find the library and have a look at it.
http://forums.ni.com/ni/board/message?board.id=170&message.id=199742&query.id=144862#M199742
Thomas
Using LV8.0
Don't be afraid to rate a good answer...

Similar Messages

  • Darren's Occasional Nugget 09/21/2007

    Hi all,
    Another one of my favorite LabVIEW 8.5 features is the new "Connector pane terminals default to Required" option in Tools > Options:
    Enabling this option causes any new connection of a control (except error controls) on your connector pane to have the "Required" wiring rule.  Here's a screenshot of this new feature in action:
    When I wired Numeric, Numeric 2, and Numeric 3 to the connector pane, they were all set to Required automatically.  I really appreciate this feature, because I can't even count the number of times I've had to debug a problem in the past where the cause was the simple fact that I had forgotten to wire an input on one of my own VIs. 
    -D
    P.S. - Check out past nuggets here.
    Message Edited by Darren on 09-21-2007 05:38 PM
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman
    Attachments:
    conpane_required.PNG ‏35 KB
    conpane_VI.png ‏29 KB

    Steve.Briggs wrote:
    As soon as I feel caught up with 8.2, that warm, fuzzy feeling is taken away by 8.5
    Steve,
    If I understand you correctly, 8.5 is better than 8.2, I think... I tried both the evaluations.
    - Partha
    LabVIEW - Wires that catch bugs!

  • Darren's Occasional Nugget 05/14/2007

    In this thread response by Craig regarding some subtleties with dynamic event registration, TonP made an unofficial request for a VI Analyzer test that would help detect event registration refnum wires that have been forked, which could cause unexpected behavior if multiple event structures are registered for the events handled by that wire.  Since I absolutely love showcasing the abilities of the VI Analyzer, I figured I would fulfill his request.  Attached below is a VI Analyzer test that will detect any Event Registration Refnum wire on the diagram that has been forked (read the aforementioned thread to learn why this may be a bad idea).  If you have VI Analyzer 1.1 or later, and LabVIEW 8.2 or later, you can use this test by following these instructions:
    1.  Create a subfolder called "VI Analyzer Tests" in your [My Documents]\LabVIEW Data folder.
    2.  Place the attached LLB in that folder.
    3.  When you run the VI Analyzer, you will have a new category of tests called "<User-Specified>", and the "Forked Event Reg Ref Wires" tests should be there.
    Enjoy,
    -D
    P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman
    Attachments:
    Forked Event Reg Ref Wires.llb ‏56 KB

    Darren wrote:
    TonP made an unofficial request for a VI Analyzer test t
    Sorry about that, but I knew you would listen
    Thanks,
    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!

  • Darren's Occasional Nugget 02/14/2007

    Happy Valentine's Day, everybody!  I had an extra minute this morning so I thought I'd whip up a quick nugget...although, since I'm sure candy is on everybody's mind today, perhaps it should be a "nougat"? 
    Anyway, today's nugget pertains to the VI Analyzer.  If you don't have it, you should buy it.  Don't forget that it's included in the NI Developer Suite, so if you have Dev Suite, you already have the VI Analyzer.  One of the cool features I added in VI Analyzer 1.1 (which supports LabVIEW 8.0 and later) is the "Quick Launch" test feature.  The documentation mentions this feature, but to summarize, you can create an analysis VI with the VI Analyzer VIs off the palette, and launch it from the Tools > VI Analyzer > Quick Launch menu to perform a quick analysis on your VI...with this approach, you don't have to actually go through the process of selecting your VI and your tests through the VI Analyzer UI, since this is already done within the Quick Launch VI. 
    But I don't expect you to be interested in this feature just by my words alone...which is why I've written a Quick Launch test for you to try out!  If you have VI Analyzer 1.1, you can do this very easily.  Take the attached VI and drop it in your [LabVIEW]\project\VI Analyzer\Quick Launch folder.  After relaunching LabVIEW, you should have the Tools > VI Analyzer > Quick Launch > Quick Code Check menu option available.  You can select this option on any open VI that is saved to disk.  It will run several (but not all) of the shipping VI Analyzer tests on your VI to check for "gotchas"...you know, things you may not notice in a visual code inspection, but that could cause bugs nonetheless?  An example might be an Increment function where the input wire is also wired under the function to the rest of your diagram, so that it looks like you're using the output of the Increment but really you're using the non-incremented value...the Wires Under Objects and Unused Code tests would both catch this bug.  Anyway, when you try this out, after selecting the "Quick Code Check" menu option, the analysis should take a few seconds, then the VI Analyzer Results Window should come up telling you if there are any test failures...it's just that easy!
    Anyway, if you want to write your own Quick Launch tests, you can use this VI as a starting point...a template is also available at [LabVIEW]\vi.lib\addons\analyzer\_analyzerutils.llb\VIAn Quick Launch VI Template.vit.
    Have fun!
    -D
    P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman
    Attachments:
    Quick Code Check.vi ‏27 KB

    Aldenbach,
    Do you ever get tired of ALWAYS being right.   Is your brother Stephen Hawking?
    Yup, I was not aware there was one more package beyond the professional dev.  Sorry for the post, I should checked more thoroughly than I did ( I did check).  But then again I'm not the sharpest pencil in the drawer.
    Chris Co.
    Attachments:
    License.PNG ‏109 KB

  • Darren's Weekly Nugget 01/16/2007

    Hi all,
    Did you realize that exactly one year ago today, I posted my first weekly nugget?  Well, I've decided one year is a good stopping point...this is going to be my last weekly nugget.  It's been a lot of fun helping you guys out with little tips and tricks I've come across in my 8 years of LabVIEW development (this week I also celebrate my 8th anniversary at NI).  For my final nugget, I just have some simple advice.  One of the coolest things about LabVIEW is the ease with which we can come up with solutions to problems.  On the other hand, there are very complicated approaches to problems that are often warranted, depending on the complexity of the desired application.  I really admire my LabVIEW colleagues who are able to come up with extremely creative, extremely complicated ways to solve problems that I never could have thought of.  However, I think we should always devote a little time in the beginning to trying to discover the *simplest* solution to a problem.  You may come up with some corner cases that your simple solution doesn't cover, but don't forget to weigh the added time and effort you have to put in to address the corner cases, and also don't forget the added risk of new bugs you'll get when implementing the complicated solution.  It may sound kinda silly to mention this as a nugget, but I have definitely seen my share of apps that took a *way* too complicated approach to solve a fairly simple problem, when the most cost-effective, robust solution would have been quite a bit simpler.  Anyway, it's general advice, and some may not agree, but it's served me well so far in my LabVIEW career. 
    So that's all folks.  But don't worry, I'll still be around...
    -D
    P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    We Want Nuggets!! We Want Nuggets!!
    Join the movement...
    Message Edited by altenbach on 01-16-2007 02:08 PM
    LabVIEW Champion . Do more with less code and in less time .
    Attachments:
    arnoldsays.jpg ‏18 KB
    churchsign1.jpg ‏16 KB

  • Darren's Weekly Nugget 01/02/2007

    Happy New Year, everybody!  Today's nugget comes from altenbach, who points out some pretty cool things you can do with the "Advanced editing mode" option on the Format and Precision property page for Numeric controls:
    As you can see, the value in a numeric control can be "redisplayed" in different formats *within the same control*.  Also, descriptive text can be added within the control itself, eliminating the need for extra free labels on the front panel.  In the VI screenshot below, several numeric controls have been formatted in different ways to illustrate the flexibility of format strings for Numeric controls.  The format string used for each control is given as a free label next to the control.  Notice the "Distance" and "Time" controls at the bottom, where the format string is used to give a more easily readable display of the actual value.
    -D
    P.S. - Check out past nuggets here.
    Message Edited by Darren on 01-02-2007 11:21 AM
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman
    Attachments:
    Format_Precision_Prop_Page.png ‏25 KB
    Advanced_Format_Examples.png ‏30 KB

    Ditto all of what Christian wrote!
     (Without this feature, we would probably need to invent a complicated XControl to do the same ) 
    Hmmmm.....
    Do you think that NI may have already implemented controls as XControls (quietly behind the scenes)?
    Look at how the graphs have morphed into composites of picture controls and tables.
    In fact the table itself appears to be an XControl implementation using a picture control. See this thread.
    http://forums.ni.com/ni/board/message?board.id=170&message.id=219597&jump=true
    So this is all rather exciting!
    Not only does it show what can be done with XControls ( Wow!)
    but it also means that LV is being developed in LV,
    And... just maybe....
    The existing libraries of all of LV controls MAY be opened to the user?
    Let me join the others in thanking both Christian adn Darren for "digging up this golden nugget".
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Darren's Occasional Nugget 05/13/2014

    Having the ability to generate PDF files from LabVIEW is a rather common request. I recently discovered a very simple way to generate PDFs from LabVIEW with a quick modification to some existing NI software. First, you must have the following products installed:
    LabVIEW 2009 or later
    LabVIEW Report Generation Toolkit for Microsoft Office 2009 or later
    Microsoft Word 2007 or later
    If you have all of this software, then open vi.lib\addons\_office\_wordsub.llb\Word_Save_Document.vi and make the following modification:
    More specifically, add the ".pdf" case with a value of "17" inside. Now, if you wire the path to a PDF file to the Save Report to File.vi for a Word report, then a PDF file will be generated:
    We will try to get this change into the Report Generation Toolkit in a future version. I realize that this trick doesn't solve all the use cases (like PDF generation on a system without Word installed), but I'm hoping that it can help out some people today.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    UliB wrote:
    I wonder if this tricks works for a Excel report as well.
    Yes, I was able to get it to work with Excel with a similar edit to vi.lib\addons\_office\_exclsub.llb\Excel_Save_Workbook.vi. Some things to keep in mind:
    For Excel 2010 and later, the numeric value inside the ".pdf" case would be 57.
    For Excel 2007, I think you would need to first install the Microsoft Save as PDF or XPS add-in.
    For Excel 2007, I think the numeric value inside the ".pdf" case would be -1.
    I'm not 100% sure about the Excel 2007 scenario, because I didn't have a test machine available to try it out. But for Excel 2010 and later, it definitely works.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

  • Darren's Weekly Nugget 01/08/2007

    Hi all,
    For today's nugget, I want to make everybody aware of the LabVIEW 8.2 Upgrade Issues page.  The purpose of this webpage is to document all bugs and issues that we know about that could cause potential problems when upgrading your applications from LabVIEW 8.0.x to LabVIEW 8.2.  This kind of information has been requested for a while, so we hope that you can use it, along with the LabVIEW Upgrade Notes and LabVIEW Release Notes, to have as many resources as possible when upgrading your applications.  If you encounter an issue while upgrading that is not listed on this page, please make sure to report the problem on the forums, or whatever other support channel you prefer, so we can continue to provide as much helpful upgrade information as possible.
    -D
    P.S. - Check out past nuggets here.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    Just wanted to say that this must be a huge amount of work to maintain, and is a huge step in the right direction.
    Thank you NI!
    Joe Z.

  • Darren's Occasional Nugget 03/25/2014

    I attended the European CLA Summit last week (my first trip outside the USA!). At the summit I gave a presentation that discussed, among other things, the VariantDataType VIs. Among the myriad use cases for these VIs is checking a variant to see if it matches a particular type. For example, we have a VI that ships with LabVIEW that will assess whether or not a variant is an error cluster (for reference, this VI lives in vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Check Type If ErrClust.vi):
    In this VI, we check the variant to see (1) if it is a cluster, (2) if it has three elements, and (3) if those elements are Boolean, I32, and String (in order). I have often recommended this approach for type checking over a simple Variant To Data function call, since Variant To Data will attempt the conversion, even if the types don't match exactly:
    Another great use case for these VIs is programmatically retrieving, at runtime, the names of enum entries as a string array:
    The VariantDataType VIs are great for data type parsing, and these are just two of many use cases that demonstrate the power of this undocumented API. Have you encountered a novel use for the VariantDataType VIs in your applications?
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    Jeff·Þ·Bohrer wrote:
    Tools>>Advanced>>Edit Palatte set...(drink Coffee)
    Right click an open palatte position Insert>>Subpalatte:  
    Check Link to a directory    
    Browse to <LabVIEW> \vi.lib\Utility\VariantDataType
    Select Save
    select Continue
    Whoomp! There it is:
    Cross-Posted to uNuggets Thread since this comes up WAY TOO OFTEN.
    Not needed just install the package in the Package Network made by NI called Hidden Gems in vi.lib as mentioned at the end of the slides posted by Darren.
    Edit:  Thank you by the way for making this a package.  I already have a vi.lib package with many of the things you mentioned in your slides but not all so this is easier.
    Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
    If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

  • Darren's Occasional Nugget 11/07/2013

    The default style for While Loop subdiagram labels changed between LabVIEW 2012 and LabVIEW 2013:
    If you want your While Loop subdiagram label appearance to be consistent across your LabVIEW versions, here are two utilities you can use:
    Quick Drop Keyboard Shortcut - While Loop Subdiagram Label - Download this shortcut from the Quick Drop Enthusiasts group to use in LabVIEW 2012. It will create subdiagram labels on While Loops that match the default appearance of labels created in LabVIEW 2013. Note that this plugin will create a left-justified label...you can change the plugin code if you prefer center or right-justified.
    Convert While Loop Subdiagram Labels Utility VI - Attached below, you can point this VI (saved in LabVIEW 2013) to a folder of VIs and it will bulk-convert all the While Loop subdiagram labels in those VIs to the default LabVIEW 2013 appearance. This utility VI will not change the existing text justification of the labels. Make sure to back up the folder of VIs before running this utility, as it will make changes to your VIs and save them in LabVIEW 2013.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman
    Attachments:
    Convert While Loop Subdiagram Labels.vi ‏32 KB

    This is a good trick. I'm quite fond of property nodes with classes for one simple reason: They separate Public, protected, and private properties in the selection dropdown. This is beneficial for two reasons. 1) When using VIs as accessors, it is much more difficult to determine their access scope visually. 2) When working with a child class, I don't have to go to the project dialog and look in the parent class to determine what accessors it has; they are automatically populated in the property node (with the caveats TST mentioned above on creation of accessors).
    CLA, LabVIEW Versions 2010-2013

  • Darren's Occasional Nugget 04/25/2013

    Did you know there is a VI Analyzer Enthusiasts group on the NI Community? Over the past few weeks, multiple community members have posted custom VI Analyzer tests to this group, and they are all available as links here:
    List of Community VI Analyzer Tests
    Note that you do *not* need the VI Analyzer Toolkit installed to use these tests. Most of them are saved in LabVIEW 2012.
    If you have any of your own custom tests that you'd like to share with the NI Community, please post them to the group!
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    RedAG wrote:
    Correct me if I am wrong, so people can post custom VI's to this forum and download custom VI's from thsi forum, like examples? Or is it a Forum where they check your VI's? That can't be true can it?
    It is a community site.  Not quite the same as a forum.  But it is there for people to share tools that they wrote.  That community site Darren gave is specifically for VI Analyzer tests that people have written.  Darren posted a bunch of his own there.  You can make comments on people's code and ask for changes.  People will make updates if they have the time.
    There are only two ways to tell somebody thanks: Kudos and Marked Solutions
    Unofficial Forum Rules and Guidelines

  • Darren's Occasional Nugget 07/11/2013

    Quick tip...I learned this little tidbit from browsing LAVA today. You can wire a Data Value Reference of a class to a property node and it works:
    Both calls return '123' and no error. Pretty cool!
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    This is a good trick. I'm quite fond of property nodes with classes for one simple reason: They separate Public, protected, and private properties in the selection dropdown. This is beneficial for two reasons. 1) When using VIs as accessors, it is much more difficult to determine their access scope visually. 2) When working with a child class, I don't have to go to the project dialog and look in the parent class to determine what accessors it has; they are automatically populated in the property node (with the caveats TST mentioned above on creation of accessors).
    CLA, LabVIEW Versions 2010-2013

  • Darren's Occasional Nugget 02/27/2012

    This nugget is for all the VI Analyzer fans out there. If you want a detailed log of everything that happens during an analysis session, add the following line to your LabVIEW INI file:
    VIAnalyzerLogging=True
    With this INI token present, the following file will be created whenever you perform an analysis: [LabVIEW Data]\VIAnLog.txt.  And in this file you will find the following information:
    [path to analyzed VI]
    [test name],[pass/fail/error],[analysis time in milliseconds]
    [test name 2]...
    [test name 3]...
    [path to analyzed VI 2]
    This information can be useful if you're interested in which tests are taking the longest to run on your VIs.  And if you're having stability problems, i.e. a crash during analysis, this log file will tell you the last VI analyzed (and test run) before the crash.  Note that I don't do anything fancy with maintaining old copies of the file...if you perform a second analysis, the log file will be overwritten with the new analysis information.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    sbus wrote:
    Thanks much for this 'nugget'. But... I have a gripe.
    I use LOTS of software packages; word processing, PCB layout, schematic capture, compilers, assemblers, debuggers, FPGA tools, etc.  One of the things that differentiates a 'good' piece of software from a 'bad' one is... the documentation.
    You have been handing out options that can be set in the labview.ini file for some time. I appreciate finding out what they are. But (you can see it coming...) - it seems that ALL of the options that can be set in the labview.ini file should be DOCUMENTED and part of the doc set for the LabVIEW environment. My happiness at receiving those settings in small doses is tempered by my feeling ripped off that there's all this stuff that could make my life easier, my use of LabVIEW more efficient, and my time more well-spent, and instead of just presenting me with a platter containing all these things, the get doled out when someone (usually you!) randomly decides to release the information.
    Consider this a plea to National Instruments to DOCUMENT the labview.ini file by going through your code base, finding ALL key/content pairs that can be set, and creating a document that presents and explains each. I feed good patting you on the back when you tell me something that helps me in my work; and bad patting you on the back for providing me with information that should have already been present in the documentation and that might have saved me time and effort had I known it earlier.
    I would guess that NI doesn't want people mucking around in the labview.ini file and use the options dialog instead.
    Bill
    (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.

  • Darren's Occasional Nugget 01/30/2014

    I've posted several nuggets in the past about tokens you can add to your LabVIEW INI file. But during a presentation the other day, somebody asked me where the INI file is located, and I couldn't give a complete answer. Its location is pretty easy to remember on Windows, but what about Mac and Linux? Here's where you can find the LabVIEW INI file (also called the LabVIEW Preferences file) on all three desktop platforms:
    Windows
    LabVIEW [20xx]\LabVIEW.ini
    Mac
    [user 'Library' folder]: Preferences:LabVIEW.app [20xx] Preferences
    Linux
    [user folder or 'root']/natinst/.config/LabVIEW-[20xx]/labview.conf
    If you want to programmatically retrieve the LabVIEW INI file path on your system, you can call the VI I've attached to this post. It works in LabVIEW 8.0 and later on all desktop platforms. I hope this nugget post eventually bubbles up in a google search for "Where is the LabVIEW INI file?".
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman
    Attachments:
    Get LabVIEW Preferences (INI) File Path.vi ‏20 KB

    Darren wrote:
    Windows
    LabVIEW [20xx]\LabVIEW.ini
    Just a reminder that this is machine-wide, and not per user, making things tricky if there are several regular users.
    There are some good ideas ideas to move it to the user hierarchy or even move it to the cloud.
    LabVIEW Champion . Do more with less code and in less time .

  • Darren's Occasional Nugget 05/09/2012

    When I first learned LabVIEW over 13 years ago, one of the things that stuck with me from my LabVIEW Basics course was that LabVIEW does not support creating an array of arrays:
    One way that developers have tried to combat this limitation over the years is to create a 2D array of the appropriate data type, then keep a separate array indicating the column index of the last "real" data value within each row of the array:
    This method works, but requires storing lots of garbage data that you don't need, and it also requires maintaining the separate index array, which can be a headache if you are frequently manipulating the contents of the array.
    The best trick I know of for storing arrays of arrays is to stick an extra cluster in there, like this:
    This technique effectively allows us to store arrays of different lengths within an array.  No more garbage data, and no extra work required to keep track of how many values are in each array.  I have used this technique many times over the years when I need 'array of array' functionality in LabVIEW.  When you are generating the 'array of arrays' on the diagram, you can do so with a Bundle function to add the extra cluster, and likewise use an Unbundle when you need to retrieve one of the nested arrays:
    P.S. - My motivation for posting this nugget is this post on the 'Eureka' thread, in which Ben admirably admits to just now learning the 'array of arrays' trick that I've taken for granted for years.
    Darren Nattinger, CLA
    LabVIEW Artisan and Nugget Penman

    Goodness gracious, those Silver Controls certainly chew up the real estate don't they?  They are the FP equivalent of the terminal icon view IMO.  Here is what the data structure could look like using (1) My totally hackified borderless cluster which lets me invisibly bundle controls on the FP (2) the usual system controls in modern containers.
    I have attached the custom cluster I use, but since I did this via black magic and reverse engineering, caveat bundler.  In other words, you have been warned.  No substitute for simple, clean controls.
    Attachments:
    Borderless Cluster.ctl ‏5 KB

Maybe you are looking for