Community Nugget 05/27/2009

On occasion, you may wish to measure the amount of time a certain piece of code takes to execute.
What many people do is something like one of these options:
But this annoying to rewrite every time. If you're good, you probably have a merge VI or use VIs such as the OpenG VIs shown here to save some time on writing this code.
Well, there is a faster way:
The timed sequence has an output terminal which tells you how long it takes to execute. You can simply drop one and select that terminal.
Caveats:
I believe they're only available on Windows and RT.
They take too much space (but then, so does the alternative).
If you're running your code in parallel with other code (which you should not be doing), they might get higher priority, thus skewing the results. I don't know enough about this to give a good answer.
When you drop one, it has terminals on the inside. You have to select to hide them if you don't want them.
For a list of past nuggets, see here.
Try to take over the world!

In the first pic (flat
sequence), the inputs of the substract-prim needs to be swapped (as in
the code using OpenG)
Actually,
in both cases the earlier time is correctly substracted from the later
time. It's just arranged differently (and I agree it can be confusing.
Another reason to do this, although personally I don't time my code very
often, so I don't actually use this).
Sequences always make me nervous...
So I prefer negative times for two reasons:
* Something odd is on my BD
* Rewind the time ASAP before the moment I dropped the sequence
Felix
www.aescusoft.de
My latest community nugget on producer/consumer design
My current blog: A journey through uml

Similar Messages

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

Community Nugget 2-19-2007 "Stacked Sequence Exterminator"

I am sure everyone with even casual familiarity of LabVIEW has run across older (or newer) code that is just peppered with ...
Stacked Sequences from Hell.
Stacked sequences (especially the one's containing sequence locals) are the hallmarks of confusing, unreadable and unmaintainable code. Data flows in all directions (mostly right-to-left), a large percentage of code is hidden at any given time, and it is almost impossible to debug and follow what going on. Often there is clear data dependency (or execution order does not matter), so the sequence serves no purpose. Better programmers don't use stacked sequences at all and even keep flat sequences at a minimum.
Here is an example:
Since the code seems to work "sort of", and trying to rewire things manually will probably lead to accidental errors, we have no choice than to leave things in place...
... or do we???
If we try to right-click on the sequence, we can only remove individual frames, breaking everything in the process. No go! A dead end! Sigh!
But let's not give up just now.... We can easily convert the stacked sequence to a flat sequence, so lets do that as a first step:
At this point, we can remove the flat sequence and all connections remain in place. Now we can just cleanup the elements and wires and everything look much better. Ahhh!!!
In summary:
An easy two-step procedure allows us to exterminate unnecessary stacked sequences without any danger of breaking the code. This method should lower the fear to remove these monstrosities. Try it today!
This is a Community Nugget. If you want to contribute, please sign up here: http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=3379#M3379
Message Edited by altenbach on 02-18-2007 10:43 PM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
SeqToFlat.gif ‏15 KB
SeqStackedA.gif ‏10 KB
CannotRemove.gif ‏12 KB

Tomi,
Aren't you asking for a good reason to use a "bad" construct?
Your suggested code construct would look like this.
After wondering how to make it faster, you would concider this.
But the revised version is not possible with a stacked seq. With a State Diagram you have a lot more flexibility, and you have it now.
Now don't get me started because the next thing you know I will be talking about the SDE* and this thread is about exterminating Stacked Sequences..
Wait, I think I just did.
Ben
* With a State Diagram you have a lot more flexibility, and you have it now. If you use the SDE the graphic documentaiton comes along for the ride.
Message Edited by Ben on 02-19-2007 07:59 PM
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Attachments:
Stacked Seq.JPG ‏20 KB
Stacked Seq Rev1.JPG ‏23 KB

An increase in community nuggets!

Hi Everyone,
On the LabVIEW board I've noticed we've got a number of new community nuggets! I think this is great and I wonder if there's something I can do to help. I was thinking about taking turns linking to the nuggets via the announcements. Thoughts?
Thanks!
Laura

Darin.K wrote:
Kidding aside, if there were any way to make Kudos counts more accessible/sortable/searchable that would go much, much farther in sifting posts than an announcement. If you could search for say a user's posts on the LV board with 4+ Kudos you are bound to find some true nuggets. Trust me, I get that info the hard way and it is worth it. (Enough beating that dead horse, for now).
Ditto that!
Note: Please take off your "moderator-keep-the-hit-count-high" hat for a second.
Speaking from ove tens years of watching this forum...
The high post count and traffic is both a curse and a blessing. The high traffic keeps it interesting and lively. There are many very insightful posts that buble up to beat back the question flow. But with the flood of info it can be challenging to sepearte the floatsum from the jetsum (I'll bet that I had to spell at lest one of those words wrong).
Similar to a bear swiping at salmon as they swim past, the good or bad can be picked out one by one as they pass by.
So as long as I stand on the bank and keep my eye on the information flow, I can goolbe up even the smallest nuggets.
But trying to catch-up!
I used to be able to do it back in the early days of the forums but not anymore. Too much info too fast and there are precious few clues to even attempt it.
The best clues end up being the Kudos.
Threads with high Kudos counts either indicate a "golden nugget hidden at the bottom of a pile of fluff"* or the gang has found a worthless thread to exploit. Both of which I want to read.
Another approach still depends on the Kudos and that is to check out who is the Kudos leader for the day or week. if a name shows up that I don't expect I can that person down to see what earned them their new found fame or I look for a frequently flyer with higher than normal counts.
So... getting to the point...
maybe the default should be "weeK' instead of "Month".
Another idea... that would require help from the web-team...
How about a "post of the week" "month" poll where we can nomimate and vote for the top or three posts?
Those polls/and supporting thread could serve as index to the top posts and allow for catch-up when we return to the forum after a period of time.
Ben
* First use of the word Nugget in connection with a choice piece of LV info.
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Darren's Weekly Nugget 11/02/2009

Are you familiar with LabVIEW design patterns? Using a well-known design pattern for your application in LabVIEW can decrease your coding time, and decrease your maintenance time. LabVIEW ships with several design pattern templates that you can access from the File > New... dialog:
Some of the most common patterns include Producer/Consumer, Master/Slave, Queued Message Handler, and of course, the ever-popular State Machine. For more details about standard LabVIEW design patterns, check out this LabVIEW Application Design Patterns presentation. It's a few years old at this point, but still very relevant.
And what about programming with LabVIEW Classes? There are many object-oriented design patterns that are applicable to LabVIEW Class programming. For more information, check out this document on the LabVIEW Community website.
Message Edited by Support on 11-02-2009 12:24 PM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

gchristi1 wrote:
Having said that, I wish the NI people would improve the templates. When I took the CLD exam, I started with a template and spent too much time molding it to look like my template.
Opinion? When you took the exam, was a native template of use to you?
When I took the CLD exam, I did not use any of the shipping templates. What specific changes would you recommend to make the NI templates better?
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Community Nugget Series: Application Development- Installment 1

Installment 1: Code by intention and basic code components
In
this Nugget series we will discuss application development, the
different ways we use to access data and information, develop a GUI that
has Controls, Indicators and other front panel objects accessable from
sub.vi's in multiple ways and explore a software developers approach to
LabVIEW without OO but exposing OO concepts. I'll be starting with
basics and moving to a real-world app designed specifically for Test
Automation. Many of the concepts have wide ranging application but as
this is my first "Nugget" and "Series" I'll chose to speak from my
strengths. I hope you all forgive me.
So lets show how to start: I do it thusly
NOTE:
The vi hasn't even been saved yet! The FP and BD are blank (OK - Use a
template if you want to save time but for this demo I'm starting from
scratch)
This is where software starts, with the end
user(s) firmly in mind! <Sea Story> I grew up as an Electronics
Technician. One day a test instrument rep demo'd a new o'scope with
advanced math functions. We were impressed with the capabitities -
untill it took 5+ minutes to perform the operations. Automate that!
[prompt user "please wait while device X does some math. Ensure
sliptick oil resivour remains above "critical.""]   We called it "Same
Day Display." The instrument MFG did not think about the end uses for
the product when archetecting the system. <
Let's not do that here.
Overall Achietecture: 4 main interlocking Queued P-C loop vi's
defined as: (If I may borrow from a business case to aid visualization)
Corporate Communications ( CC or GUI):
Executive:
Operations:
Accounting:
Each of these loops Consumes exactly 1 Queued loop:
1:
CC is primarrilly an Event Loop. After initialization it responds to FP
events. These events can be caused by direct user action or by
indirect actions when something in the application generates an event
the GUI needs to respond to. It produces the "Executive" Queue and may
generate events. It keeps the user informed and happy.   It is the
primary abstraction layer between the developer and the user. If the
user can do it CC needs to respond - If the developer expects the user
to do something it Must be intuitive or explained by Tip Stips and / or
on screen instructions.
2: Executive is a QSM
(Queued State Machine) it consumes the "Executive" Queue, generates the
"Operations queue, and may generate events for CC. This is the main
abstraction layer between the developer and the application
enviornment. In this demo we will perform "Tests" defined as a sequence
of things do much like the tasks your manager asks you to take to
acomplish an objective. Its the manager scheduling how when and what to
do and has a really great Admin department that knows the business,
what can be done by the Ops dept and has a list of activities that
should be performed to satisfy the customers (yep! sequence files!)
We'll get to those in another nugget in the series!
3:
Operations is another QSM it consumes the "Operations"
Queue, generates the "Accounting" queue, and may generate events for CC
. This is the main abstraction layer between the developer and the
system components or HAL (Hardware Abstraction Layer). All interaction
between the application and other resources (except the file system and
KVM) takes place here. Again- we'll save that for another nugget.
4:
Accounting is another QSM it consumes the "Accounting"
Queue, generates "Executive" queue, and may generate events for CC .
Its job is to let the Executive know what the result of the operations
are so managemant can make an informed desicion on what to do next. And
it files reports in whatever format the Admin assistant's policy says to
do it in.
Each of these four main functions exist in all applications and all LabVIEW code. Here is CC GUI A.vi after saving
the
GUI responds to user clicks of "stop"(Tip Strip Val ="Press to stop
this vi ") and the vi changes state on the next loop iteration.
Executive
functions are encapsulated in the while loop itself Management is
simple: "Unless the last operation was True do the same thing again" (and the constant 10 is our admin assistant!!!! change it and the app behaves different)
Operations
"list of things the vi knows how to do" is limited to Update i, Wait
(n)mSec and (AN,D not then, no data dependancy so we are multitasking!)
read Stop
Accounting is in the condition terminal reporting the value of
stop- and we chose not to report anything- could have reported Array of
Stop, Last i, or any of the values we see either to the FP, any file
whatever! just illustrating a point.
Our requirements a a bit more detailed and we'll get back to the GUI next nugget:GUI FP object encapsulation.
Jeff

F. Schubert wrote:
Thanks for this nugget. The business case model looks interesting. I'm looking forward to see how this will evolve.
As a side note, I always like graphical sketches. So the basic idea of the interaction between the business entities could be drawn using boxes and arrows.
Felix
As ususal you and I are on the same page.
These images ...
and
appear im the documents I posted in this thread where I talked about doing the design first (consistancy).
The high level organizational, interaction diagrams are what I try to sketch up mentally during kick-off meetings. I use a variety of methods to get the information I need for these diagrams depending on what I know going in and the nature of the customer but... I don't let the meeting end until i have a picture tht models a system that meet the neeeds.
The diagrams doc what the customer wants, splits up the work into clean concise chunks, establishes responsibilities, needs, and the chararcter of each. In short they go a long way toward defining the design.
And for those apps you only up-date every three or four years...
There ain't nothing like those diagrams to gt you back into the same frame of mind you where when you designed it.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

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 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 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/03/2009

One helpful LabVIEW feature that add-on developers frequently utilize is the fact that you can place VIs in the [LabVIEW]\project folder to create new entries in the Tools menu. Did you know that you can also place VIs in the [LabVIEW]\help folder to have them appear in the Help menu? Or the even less well-known [LabVIEW]\wizard folder to have them appear in the File menu?
This functionality has been around for a long time, and there are even some private VI Server properties that help you determine the VI from which the menu option was selected. In LabVIEW 2009, I added a VI to vi.lib that will give you this information (it basically just wraps the private properties). Check out [LabVIEW]\vi.lib\VIServer\Menu Launch VI Information.vi. This VI will return the App reference of the owning app for the VI from which the menu item was selected, along with the VI name. You can then wire these items to an Open VI Reference function to gain access to the VI from which the menu item was selected.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

I will reply myself
Checked/works in LabVIEW 8.6:
File and Help - menu: Tools>Options> Menu Shortcuts
There is no such option for Tools menu
And observed behaviour: defined this way shortcut is active only in this session LabVIEW - shortcut disappear after LabVIEW restarting, item in menu still existing
Message Edited by Zbigniew StS on 01-07-2010 03:16 PM
Regards
Mikrobi (Zbigniew St. Sobków)____________________________________________________________
"You can lead a horse to water, but if you can get him to float on his back you've got something."

Darren's Weekly Nugget 08/24/2009

Does it bother you that you have to use values of 0, 1, or 2 to set the disabled state of a control/indicator? It never really bothered me, I guess because I just got used to it. But lots of people think that it should be an enum instead. Well, I don't know how it didn't make it into the Upgrade Notes, but have you seen the Disabled Property in LabVIEW 2009?
So now you don't have to do a number-to-state translation in your head whenever looking at the Disabled property. Of course, you're also losing a lot of diagram real estate. I'll let you decide if it's worth it or not. As for existing code, your old U8 constants will stick around, and you'll see a coercion dot on the property:
I wouldn't worry about the coercions, they're not hurting anything. I don't plan on going through all my existing apps to change them over, although I will probably start using the enum in new apps.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Once upon a time it was policy of NI to remove as much enums from the IDE as possible, since they all need to be localized for every IDE language, something that was basically not possible, so I wonder how this looks in the french or german version of LabVIEW.
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 Weekly Nugget 08/31/2009

A while back, I wrote a blog post about my preferred Tools > Options settings. Today I'm going to highlight a few of those, and some others, that make my life easier as a LabVIEW programmer. Note that I used LabVIEW 2009 to compose this list, so the organization might be slightly different if you're using an older LabVIEW version:
Front Panel > General > Connector pane terminals default to Required: CHECKED - This option often saves me some debugging time that I used to spend discovering instances where I forgot to wire a new terminal on a subVI I've written.
Block Diagram > General > Auto-insert Feedback Node in cycles: UNCHECKED - Every time I'd see a Feedback Node magically appear in my code while wiring, I didn't want it there. With this option unchecked, Feedback Nodes only appear if I actually drop them.
Block Diagram > Wiring > Enable auto wiring: CHECKED - Gets the wiring right 95% of the time, and I just press the spacebar the other 5% of the time to drop the object without auto wiring.
Controls/Functions Palettes > Loading > Load palettes during launch - Assuming you haven't been hiding under a rock for the past year, you should already know that this is the option you must select if you want Quick Drop to be immediately usable after launching LabVIEW.
Environment > General > Skip Getting Started window on launch: CHECKED - Just saves me some launch time speed that I lost with the Load palettes during launch selection.
Environment > General > Maximum undo steps per VI: 99 - I don't think I've ever gone back 99 steps, but I know I've gone back more than 8 (the old default value) many times, and I've probably gone back more than 30 (the new LabVIEW 2009 default value) a few times too.
Environment > Saving VIs > Enable automatic saving for recovery: CHECKED - This option has really saved me a few times when LabVIEW decided that it just couldn't go on anymore.
Source Control: ENABLED -We use Perforce for source control in LabVIEW R&D, and it's really handy to be able to check in/out my VIs directly from the LabVIEW project window.
Are there any other Tools > Options settings that make your life easier?
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Good nugget Darren.
The very first thing I do when I show up in front of the computer at a client site or installing a fresh version of LabVIEW is to set the Options.
I totally agree that the automatic feedback node should never be set as default. As a matter of fact, it should be removed from the Options list.
Darren wrote:
Block Diagram > Wiring > Enable auto wiring: CHECKED - Gets the wiring right 95% of the time, and I just press the spacebar the other 5% of the time to drop the object without auto wiring.
I've always disabled the auto wiring because of bad experiences with it with LV7.x It was driving me nuts (which became a permanent condition)
I didn't know the trick with the spacebar. Maybe I'll try it again with LV2k9 when I get a chanceto work with it.
Darren wrote:
Controls/Functions Palettes > Loading > Load palettes during launch
- Assuming you haven't been hiding under a rock for the past year, you
should already know that this is the option you must select if you want
Quick Drop to be immediately usable after launching LabVIEW.
Unfortunately, I have been hiding under a rock... A Unix based rock called VxWorks.
I always use the palettes and want them near. I also right click to get the pallette. I do sometime struggle with setting the palettes to my liking.. Although I do recall that we can copy some sort of ini file which will "copy" our settings from one PC to another and make that life easier... I seem to recall tst posting something about it.
Darren wrote:
Environment > Saving VIs > Enable automatic saving for recovery: CHECKED - This option has really saved me a few times when LabVIEW decided that it just couldn't go on anymore.
Very important. It's been useful a few times already.
Darren wrote:
Source Control: ENABLED
-We use Perforce for source control in LabVIEW R&D, and it's really
handy to be able to check in/out my VIs directly from the LabVIEW
project window.
I also use Perforce at the moment... or rather when coding with LabVIEW.

Darren's Weekly Nugget 08/17/2009

Block Diagram Clean Up was one of the premiere features of LabVIEW 8.6. It was a little rough around the edges at that time, but some great improvements have been made in LabVIEW 2009. For example, you can now invoke diagram cleanup on a selected portion of your diagram. If you have diagram objects selected, and you press Ctrl-U (or the cleanup toolbar button), only the selected items will be cleaned up...the rest of your diagram will remain unchanged. Also, diagram cleanup in LabVIEW 2009 is a lot better about keeping your free labels within the same proximity of objects they were near before the cleanup. It's still not perfect, but it's far better than the behavior in LabVIEW 8.6, which was to indiscriminately move all labels to the corner of their owning diagrams.
So if you were not satisfied with diagram cleanup in LabVIEW 8.6, I think you should give it another try in LabVIEW 2009. After all, that's what I'm doing.
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

I used to frequently copy code to a New Untitled VI, do a clean up and paste the code back... But yeah, now its pretty cool...
Message Edited by NitinD on 08-18-2009 12:39 PM

Darren's Weekly Nugget 08/10/2009

The Parallel For Loop is one of my favorite new features of LabVIEW 2009. With most desktop computers containing two or more processors these days, it's nice that LabVIEW already enables us to write parallel code without a second thought. But the Parallel For Loop takes things one step further by allowing us to configure some For Loops to run their iterations in parallel across multiple processors. You can check out the link above for a complete description of the feature, but I figured I'd focus on one specific tip for using the Parallel For Loop that I think needs extra attention. When you run the Parallel For Loop Detector (Tools > Profile > Find Parallelizable Loops...), it will detect all For Loops in your code that could potentially be parallelized. You can run this option from the toolbar of a project to analyze all VIs in the project, or from the toolbar of a VI to analyze just that VI. When you browse the results of this analysis, be careful about nested loops. The Parallel For Loop Detector will detect *any* loop that could be parallelized, but as a general rule, you'll want to avoid parallelizing a loop that resides within another loop that can be parallelized. This is because there is some extra overhead before and after the loop execution that is responsible for setting up the parallel iterations, then combining the results once the iterations are complete. This overhead is negligible for a top-level loop because it only happens once. But for a nested loop, that overhead will occur every time the nested loop runs, and the parallelism overhead may end up taking more execution time than just letting the loop run serially in the first place. So I recommend sticking with parallelizing only top-level loops, or at the very least, benchmarking your code if you decide to parallelize nested loops.
Message Edited by Support on 08-10-2009 02:09 PM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman

Cory K wrote:
But are you saying you can have multiple processors working on a single loop?
I didn't even think that was possible....
YES! If iterations of the loop do not depend on previous values it can be parallelized. Thus it can have one CPU working on the i=0 case and another on the I=1 case if they don't depend on each other. These are not loops executing in parallel, but the frames of the single FOR loop executing in parallel.
It is a good question about unwrapping code in multiple parallel For loops. I can see how the multiple unwrapping could cause problems with the optimization. It is a good question about the general rules for nested loops. For example if a loop of count N is inside a loop of count M what is the time for a large range of N and M in the 4 cases
1. both N and M serial
2. N parallel M serial
3. N serial M Parallel
4. both N and M parallel
For the student,
build a test harness for all 4 cases taking an input integer P and doing some significant calculation in a nested parallel FOR loop.
produce 3 color image plots for N and M from 2 to 2^p by factors of 2, normalize the times for case 2, 3, and 4 to the times from case 1. Plotted as a function of N and M all on the same Z scale for comparison.
Bonus credit, run the code while stepping the number of CPUs used from 1 to 8....

Community Nugget 4/08/2007 Action Engines

Action Engines, What are They?
“An action engine is Ben's term for a functional global which includes extra actions other than just holding the data.”
(tst , 03-13-2007 01:18 PM)
In a nut shell tst has nailed it except for the “Ben’s term” part. I was originally exposed to the term "Action Engine"
by reading the book ""LabVIEW Applications Development A Course on Advanced LabVIEW Programming Techniques*”. But
before I get into details of the Action Engine (AE), I will attempt to clarify some terminology.
Functional Globals
Functional Globals (FG) are VIs that are functionally equivalent to LabVIEW globals. Functional Globals store
information. You can read them or write them and that is it. No fancy stuff. Functional Globals are also referred to as
LV2 globals because LV2 did not have globals but it did support Un-initialized Shift Registers (USRs). The USR is the
entity that stores the information.
USR.jpg
USR’s
Shift Registers (SR) come in two varieties “Initialized” and “un-initialized”. The presence or absence of a wire
feeding the SR from outside the loop distinguishes how LabVIEW will implement the SR. If there is NO wire feeding a
shift register (A), then the SR is not initialized. This is called an “Un-Initialized Shift Register”. The USR variety
is implemented as static buffer that is re-used from call to call. The values written to the USR in and earlier call
persist for access (B) in latter calls**. A Functional Global exploits this behavior by implementing two methods of
interacting with the contents of the USR.
Functional Global.JPG
In the “Write” action (not shown) the value of “Numeric in” is placed in the USR. In the “Read” action the contents of
the USR are returned via Numeric out.
Action Engines
An Action Engine (AE) can be thought of as a machine (Engine) that performs some useful task (action) often on
something (typically but not limited to data in a USR). Functional Globals are very specific type of Action Engine.
They have two actions “Write” and “Read”. They operate on the data stored in the USR either by replacing or using the
contents of the USR. So AE’s are a superset of Functional Globals. In many documents the terms AE and FG are
interchangeable. A recent poll on LAVA has indicated that Functional Global is the most popular term. Since this Nugget
was prompted by answering the question “what is an AE?” in the remainder of this document you will find that I will
generally use the term AE.
Do What to What?
AE design revolves around the ways the shared resource must be accessed manipulated or monitored. In a Functional
Global, the actions “Write” and “Read” are appropriate. That is not necessarily the case for AEs. AEs can have entirely
different set of actions depending on the interaction requirements for the information stored in the USR. A short list
follows.
A Configuration AE could allow for multiple processes to share a single copy of the system configuration (in a USR) by
providing actions like “Set Device ID”, Set Device ON-Line…
A hardware device can be realized as an AE that presents actions appropriate to the physical phenomenon being measured
or controlled.
A DO Port Controller AE could store a reference to the physical device in one SR and the port status in another SR and
have action like: Set Main Motor On”, “E-Stop”, …
An Instrument can be implemented to store the device name and settings with actions like “Set Input ON” “Auto-Scale Y”
and “Get Trace”,…
Screen Stacks can be implemented by using control references in one USR and maintain a screen view stack in another
then implementing actions like “Set Config Screen”, “Set Login Screen”, “Back”…
Users can be managed using an AE with action such as “Add New User” “Set Password”, “Disable User”…
The list goes on and is limited only by our imagination. Here is an example that shows how a running average can be
maintained.
Running_Average_Example.jpg
Running Average Example
The Running Average Example shown above shows how a running average can be maintained using an AE. The AE is
initialized before the While Loop executes. On each iteration of the loop the simulated measurement value (random
number) is used to update the history of all measurements (Add Number(s)) and the mean is calculated (Calc Mean).
Please note that although the buffer of all measurements is affected in every step of this example, the buffer (USR in
the sub-VI) contents are never part of this VI’s diagram. Since the history is stored in the sub-VI, the history can be
acted on from more than one thread as shown below.
Parallel_Loops.jpg
In the parallel Loops Example the history is initialized and then two loops run in parallel with one updating the
history and the other plotting the average. Since the History resides inside the USR of the sub-VI the two while loops
are effectively sharing the same block of memory, the block used to store the USR. The Sub-VI was implemented as shown
in the following sequence of images.
Init.jpg
As was the case with Functional Globals, the actions are implemented as a type def’d enum***** driven case structure.
Appropriate code is present in each case to realize the intended actions. In the “Init” case, contents of “Array in”
are used to initialize the history. In our example above we did not pass an initial array value. Therefore the “Init”
resets the history (cleared the array).
Add Num.JPG
The operation of the AE when the “Add Number(s)” action is called varies depending on its usage. If the caller passes a
non-empty array, it is appended to the array. Alternatively, passing a value via the Numeric in” control, and leaving
the “Array in” un-wired adds a single element to the history. We used the Numeric In input so we were continually
building our history one value at a time.
Calc_Mean.JPG
When the “Calc Mean” action is invoked, the average is calculated and returned.
This Nugget is continued in the next post
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction
Solved!
Go to Solution.

Nugget continued
The Traffic Cop Behind the Scenes
A detail I have not mentioned up until now is that AEs should be implemented as VIs that are not reentrant***. VIs that are not reentrant can only be executing in one context at a time. LabVIEW will ensure that if there is ever a situation were two contexts are attempting to act on the same AE at the same time, LabVIEW will schedule the first and the subsequent will wait until the first call completes. This is similar to a traffic cop preventing more than one vehicle from entering an intersection at the same time. The Traffic Cop is illustrated in the following timing diagram were we look at how the processing of two threads is affected by using a single AE.
Execution_Timeline.JPG
In the figure above the processing time of two processes “P1” and “P2” are illustrated by a red or blue solid arrow respectively. In the parallel loops example shown earlier, P1 could be the “Calc Mean” loop and P2 could be the “Add Number(s)” loop.
t0 - t1
Both processes are executable and run their assigned tasks. Neither process is accessing the AE.
t1 – t2
P2 continues to run while P1 calls the AE. Since the AE is idle it is available to run so P1 continues execution running inside the AE until all work inside the AE completes. The dotted arrow shows that the thread for P1 is executing in the data space allocated for the AE.
t2 –t3
At t2 the AE terminates and both process run as in t0 – t1.
t3 – t4
This time segment is similar to t1 – t2 with P2 running in the AE.
t4 – t5
Similar to t2 – t3 the AE terminates and both process run.
t5 – t6
Similar to t1 – t2. P1 take control of the AE.
t6 - t7
At t6 P2 attempts to call the AE. Since the AE is not idle it is not available to run. P2 is placed in a resource wait state (it is NOT running) waiting for the resource to become available. The dotted horizontal arrow indicates the process is not executing.
t7 –t8
At t7 the call of the AE by P1 that started at t5 completes and P1 continues to execute outside of the AE. When the call by P1 completes the AE becomes available. The process P2 is marked as executable. The scheduler includes P2 in its executable threads and the AE is available. P2 then executes inside the AE until the call completes.
The Beauty of the AE
This behavior of a non-reentrant VI is a wonderful feature we can exploit to eliminate race conditions. Race conditions are the nemesis of many a developer. In hardware this was solved with clocked enabled logic. In LV we solve race conditions with Queues, Semaphores, Rendezvous, Occurrences, and Action Engines!AEs can eliminate race conditions when all operations involving updates of the data stored in the USR are done INSIDE the AE. A very simple illustration of how the encapsulation of USR manipulation is shown in the following set of examples.
Port_With_Global.jpg
This VI is intended to demonstrate how two bits of an eight-bit port can be used to control the running state of two pumps. To illustrate the control process, one pump will be set running at start-up and then every half second the state of both pumps will be toggled to simulate switching of the supply. This example uses globals and fails miserably.
Port_With_Global.jpg
In this example we start out by initializing a global variable so that bit “1” (zero based) is the only bit set in an array of eight bits. This turns on Pump 2 to start. Then the “Port Update” and a “State Change” loops run in parallel. In the “Port Update” loop the state of the port is read from the global and used to update the GUI.
In the “State Change” loop, the port status is read and the first Boolean is inverted before being written back to the global. Similarly for the second Boolean. Since the read of the globals both occur before the subsequent data processing, one of the threads will be processing old data.
Port_With_Action_Engine.jpg
The Action Engine version codes up the same way as the global version but now all of the data manipulation of the port states are encapsulated in the Action Engine “Port Controller”. This encapsulation ensures all operations involving the data in the USR are forced to happen sequentially even though we did not have to implement any code to achieve this affect.
The key point to take away from this example is a shared resource (the port status in the case) when implemented as AEs come with resource contention resolution built in provided that all manipulation of the shared resource takes place inside the AE.
Action Engines to the rescue!
Action Engines are not a replacement for Queues, Rendezvous and the other synchronization techniques. They are typically called for when your design dictates that a single resource must be shared by more than one parallel process and none of the LabVIEW provided techniques are sufficient. They require a design of their own to ensure they work correctly. They also have to be developed and supported.
This Nugget is continued in the next post
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Community Nugget 05/27/2009

Similar Messages

Maybe you are looking for