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

Similar Messages

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/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 Weekly Nugget 08/08/2006

As of this morning, LabVIEW 8.20 was officially announced at NI Week 2006. I am going to use the next few Darren's Weekly Nuggets to describe some features I personally added to LabVIEW 8.20. These are the kind of features that (hopefully) make people say, "Whoa, cool!", yet aren't quite big enough to make it as bullet points on marketing material.
For starters, I'll mention the Remove Breakpoints from Hierarchy utility that you will find in the Edit pull-down menu of any open VI. Selecting this menu option will remove any breakpoints you have set in the current VI (i.e., the VI from which you selected Edit > Remove Breakpoints from Hierarchy), along with any breakpoints in the current VI's subVIs. A summary dialog then comes up and indicates how many breakpoints were removed from each VI in the hierarchy.
I've seen this feature request a number of times on the NI Discussion Forums, so I hope the word gets out to everybody who has wanted this feature in the past.
-D
P.S. - Check out past nuggets here.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

hallelujah! thanks to NI for listening! I've been wanting that feature for sometime now.
2006 Ultimate LabVIEW G-eek.

Darren's Weekly Nugget 08/02/2010

Just in time for NI Week, LabVIEW 2010 has released! Over the next several weeks, my weekly nuggets will highlight some of my favorite features in LabVIEW 2010.
Cool LabVIEW 2010 Features Part I: Replace and Insert with Quick Drop
Soon after I released Quick Drop with LabVIEW 8.6, one of the first requests was the ability to do Replace and Insert operations with Quick Drop instead of the palettes. Well, it took a few releases, but we finally got it:
Replace with Quick Drop
Select one or more diagram objects, press Ctrl-Space to bring up Quick Drop, type a palette object name (or a project item if you have one or more LabVIEW projects open), press Ctrl-P, and all the objects you had selected on the diagram will be replaced with the object name you specified in Quick Drop. And yes, it does do the replace "correctly" with Compound Arithmetic...
Insert with Quick Drop
Select one or more diagram wires, press Ctrl-Space to bring up Quick Drop, type a palette object name (or a project item if you have one or more LabVIEW projects open), press Ctrl-I, and a separate instance of the object you specified in Quick Drop will be inserted on each wire. I also included special functionality when Ctrl-Shift-I is pressed. I call this "Smart Insert". With Smart Insert, a *single instance* of the object name you specify will be inserted on multiple wires. As an example, if you select a refnum wire and an error wire, press Ctrl-Space, type "Property Node", and press Ctrl-Shift-I, a *single* property node will be inserted on both the error wire and the refnum wire.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

I would argue that the expected behavior for Ctrl-Space....Select....Ctrl-P for the 1/x function replaced by a Compound Arithmetic should be:
=====>
not what it currently is:
====>
This, BTW, is what the "Replace" menu does, so there is no benefit really in using the Ctrl-HyperSpace projection (at least to me).
And similarly for (-x) and x^2.

Darren's Weekly Nugget 11/08/2010

Cool LabVIEW 2010 Features Part XI: Export Data to Clipboard (or Excel or DIAdem)
I thought I was done with my "Cool LabVIEW 2010 features" series a few weeks ago, but then I stumbled across this one today:
These new Export Data options are available on Waveform Charts, Waveform Graphs, Tables, and Arrays (including constants!). Choosing the Export Data To Excel or Export Data To DIAdem options will launch those apps with a new document containing the data. Choosing Export Data To Clipboard will simply copy the data to the clipboard, at which point you can perform a Paste operation in whatever app you wish (Excel, DIAdem, Notepad, Word, LabVIEW, etc.). Here are a few things I discovered when exploring this new feature:
On Windows, the columns are tab (\t) delimited, and the rows are line feed (\n) delimited. I didn't check other platforms.
When using this feature with the Table control, it works best if you deselect Advanced > Show Selection on the table before exporting. Otherwise, you have to select (i.e. highlight) the data you want to export in the table. It seems to me that most of the time I'd want to export the entire contents of my table.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

mysticfree wrote:
"Export Image" property? DO'H! Of course. In all my searching, I don't know how did I miss that one .... boy, is my face red.
Happens to the best of us!
Promise.
Paul <--Always Learning!!!
sense and simplicity.
Browse my sample VIs?

Darren's Weekly Nugget 06/15/2009

One of my favorite features of LabVIEW 8.6 is Linked Tunnels. I can't believe I haven't written a nugget about these yet! In case you haven't heard, wiring tunnels in multi-frame structures is a lot easier in LabVIEW 8.6:
See those tiny white triangles on outer edges of the string tunnels? Those indicate the input/output tunnels are "linked". There are two equally awesome use cases for linked tunnels:
You are adding a new pass-through wire on an existing case or event
structure that already has a bunch of frames. When you pass the wire
through one of the diagrams, if you right-click the output tunnel you just created and choose Linked Input Tunnel > Create & Wire Unwired Cases
to link the input and output tunnels that bookend that wire, it will
automatically wire up those tunnels in every other frame of the
structure.
You are adding a new frame to an existing case or event structure that already has linked tunnels. When you add the new frame, all linked tunnels will already be wired together on the new diagram.
I like this feature so much, I tried to figure out a way to show it off in my NI Week 2008 keynote demo. But since Tim only gave me 10 seconds to write my VI, I wasn't quite able to squeeze it in.
Message Edited by Darren on 06-15-2009 04:54 PM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Fantastic!
This is a great feature that I was not aware of. Thanks Darren.
Using this feature when creating State Machines or Event Structures will be very useful and highly appreciated.
You should definitely show this during NI Week. This is a feature that has been long awaited.... (by me)
RayR

Darren's Weekly Nugget 08/14/2006

I hope everyone who attended NI Week 2006 had a good time...my favorite part was getting to ride a Segway, which I had always wanted to do. My favorite product demo was probably the Rubik's Cube solver, complete with motion-controlled "robot" hands that actually solved a cube that I had personally mixed up.
Anyway, this week's nugget is part 2 in my "Cool Things Darren Added to LabVIEW 8.20" series of nuggets. I remember thinking a while back that it was a little weird that I could right-click on a control in a Global or Control VI and choose Advanced > Hide Control, but then really have no way to show that control again, other than writing a VI to do it. So in LabVIEW 8.20, you'll notice a new menu option to allow you to do this. Just select Edit > Show Hidden Controls and Indicators in a Global or Control VI, and all hidden controls and indicators will be displayed, along with a summary dialog showing the labels of all controls and indicators that were shown.
The menu option is not available with regular VIs, but you can still use this feature relatively easily on them. Just open [LabVIEW]\project\ShowHidden Core.vi, specify your VI name, and run it, and all hidden controls will be shown.
-D
P.S. - Check out past nuggets here.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Darren wrote:
The menu option is not available with regular VIs, but you can still use this feature relatively easily on them. Just open [LabVIEW]\project\ShowHidden Core.vi, specify your VI name, and run it, and all hidden controls will be shown.
To add this option to the tools menu you can use the attached llb to use it in regular VI.
Just drop it in LV82/project and you will get the "Show hidden controls and indicators ..." in Tools menu
Darren do you have some new way in 8.2 to cusomize the LabVIEW environment? Like /projet to add menu in "tools" menu, /wizard to add in "file" menu. Do you have some nugget on this subject?
Dany
Dany Allard
Attachments:
ShowHidden.llb ‏84 KB

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

Darren's Weekly Nugget 02/09/2009

Shortly after NI Week 2008, I found out that NI employees could take the NI Certification exams. Previously this was not allowed. Once I found out, I took the CLAD, the CLD, then the CLA. Don't worry, I passed them all.
Over the past few weeks, I've posted information on my LabVIEW blog detailing how I prepared for each exam. I recommend checking out my articles before you plan on taking any of the LabVIEW Certification exams:
Preparing for the CLAD
Preparing for the CLD
Preparing for the CLA
-D
P.S. - Check out past nuggets here.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

NIquist wrote:
Just out of curiosity, why would NI not want their employees to be certified in the very products they sell and support???
I'm not certain about this, but I *think* it was simply a manpower issue. Up until recently, they didn't have enough staff to grade exams submitted by both customers and NI employees.
-D
P.S. - I'm glad you like the blog! I have tons of ideas for articles, it's just a matter of finding time to post them. The certification exam prep articles were highly-anticipated though, so I knocked those out first.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Darren's Weekly Nugget 02/27/2006

This week's nugget deals with front panel control references. If you need a control reference on the panel (like when you're sending a control reference into a subVI), you typically drop a Control Reference from the Refnum palette on the front panel, right-click, and choose the appropriate class. Also you sometimes will have to right-click and choose "Include Data Type" when dealing with a control class that may have more than one data type associated with it (like a single-select vs. a multi-select listbox). This gets even more confusing if the data type of the control you're dealing with is not the "normal" data type of that control (an array data type listbox is a good example).
Turns out there's a much easier way to create a class-specific, type-specific control reference on the front panel. Assuming you already have the appropriate control (like our afore-mentioned listbox) on your front panel, just drop a control reference on the front panel, then control-drag the control *into* the control reference. You'll see that the control reference automatically adapts to be of the proper class and data type of the dragged control.
-D
P.S. - Check out past nuggets here.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Aitortxo wrote:
I used to create a reference from control, then right-click and create control, and then cut-paste to the SubVi front panel.
I did it this way as well... Now I have to write a vi to try this out!
Thanks Darren!

Darren's Weekly Nugget 05/04/2009

One of the nifty features of LabVIEW 8.6 was the ability to edit the properties of multiple objects at the same time. Most of the literature on this feature focuses on editing front panel objects, but did you know you can edit the properties of block diagram objects as well?
For most diagram objects, the property list is pretty limited (or nonexistent). For the functions above, the only properties you can change are the adapt to source option on the Output Configuration of the functions, and whether or not the functions' labels are visible. There are other objects (particularly constants) with more useful configuration options. For example, you can change the items in multiple enum and ring constants at the same time. For string constants, you can change several formatting options.
How has the ability to edit properties of multiple objects (either FP or BD) been particularly useful to you LabVIEW 8.6 users out there? And what properties would you like to see be editable on multiple objects that aren't there yet?
Message Edited by Darren on 05-04-2009 04:06 PM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
diagram_select.png ‏2 KB

Thoric wrote:
I created a mock-up of my application's panel (one of them, anyway) that has 48 identical controls within a large tab of an otherwise empty vi. It uses the same type-def for the controls. I tried using multi-property, and it worked with lightening speed! So, on the second tab pane, I created another 48 controls, from a second type-def. I tried multi-property for this new set of 48, and it worked, but slower. I re-selected the first 48 controls, and although it worked again, it was slower still.
So I created a third tab pane (my application has six panes by the way), and another 48 controls. Now it's starting to grind to a halt. Multi-select takes a long time to populate the Properties window, and a good long time to affect any changes too. A disproportionately long time. In fact, as I look at it now, LabVIEW has frozen
I do get trouble with my LabVIEW installation, with things like Quick Drop crashing occasionally, so maybe this slow behaviour won't be seen by others?
(Actually, while I've been writing this and playing with the multi-property tool, LabVIEW has frozen on me three times. I wonder if something more serious is amiss...)
Thoric,
I tried multi-select properties on 48 controls on the UI you gave, and I didn't see any of the slowness you've described (running a 2.4GHz(x4) quad core with 4 GB RAM here). The first launch of the properties page took a few seconds, but each launch after that was very quick. And applying the changes only took a few seconds. I also tried the same operation in the LabVIEW 2009 beta and saw pretty much the same speed.
Also, I've never seen Quick Drop crash. Do you have problems with other applications on your computer besides LabVIEW?
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Darren's Weekly Nugget 06/22/2009

Today's nugget deals with gracefully closing a LabVIEW built EXE window. Most everybody knows the trick of using the Quit LabVIEW function at the end of a built EXE to close its window. In fact, you may have even included some extra logic, like with a Conditional Disable Structure or the App.Kind property, to make sure Quit LabVIEW doesn't run while you're developing and debugging your VI in the LabVIEW editor:
Have you ever noticed, though, that sometimes when you quit a LabVIEW built EXE, you see a brief flicker of the toolbar? This can happen if you have your VI set to have a dialog window appearance (so that there is no toolbar), and you run the Quit LabVIEW function after clicking the "Stop" or "Exit" button that you created on your VI's front panel. In this case, the built EXE, upon going idle, will show a toolbar (with the Run button) for an instant before the panel closes.
To avoid this toolbar flicker, you can make one simple change to the code above:
By calling FP.Close, you are telling LabVIEW to hide the front panel of the VI/EXE first before exiting. This way the extra cleanup that LabVIEW must do can occur without the front panel of the built EXE showing, and we never see the toolbar flicker.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Sebster: Yes, it will work, but you should clear the error before you execute the code. Furthermore you will need to get the reference to the calling VI (or the top level VI).
Darren: Thaks a lot for the hint, the FP.Close was really new to me. Maybe you adress the other side (splash screen while loading) in a further nugget.
Felix
www.aescusoft.de
My latest community nugget on producer/consumer design
My current blog: A journey through uml

Darren's Weekly Nugget 03/30/2009

Here's a quick tip when dealing with path data types. Sometimes we have to deal with paths that have a value of <Not A Path>. A value of <Not A Path> can be formed in many different ways...one way might be if you're trying to build a path with the Build Path function, and you accidentally wire an empty string into the "name or relative path" input. If you want to test how your code handles a value of <Not A Path>, it's not as simple as typing "<Not A Path>" in a path constant or control. You must operate click the little path symbol on the left side of the control/constant and change its value from "Valid Path" to "Not a Path":
If you try to type the text "<Not A Path>" into the path control/constant, LabVIEW treats that value as a relative path to a folder/file named "<Not A Path>", which is *probably* not what you were wanting to check. The Not A Number/Path/Refnum? function is the easiest way to programmatically tell if a path value is truly <Not A Path>.
Message Edited by Darren on 03-30-2009 06:12 PM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
not_a_path.png ‏3 KB

Darren said:
You must operate click the little path symbol on
the left side of the control/constant and change its value from "Valid
Path" to "Not a Path"
As
an integrator, we've gone almost exclusively to system controls to keep
things from, dare I say, "looking like LabVIEW". Any way to do what
you've suggested with the System Path Control? I can get the <Not A
Path> type into the control, but not by copying / pasting. Run the
attached VI. Notice that when you click in the first path control, it
highlights "<Not A Path>".
-Jason
Message Edited by LabBEAN on 03-31-2009 02:05 PM
Certified LabVIEW Architect
Wait for Flag / Set Flag
Separate Views from Implementation for Strict Type Defs
Attachments:
Not A Path -- System.vi ‏6 KB

Darren's Weekly Nugget 01/02/2007

Similar Messages

Maybe you are looking for