Thursday, October 7, 2010

The Sweet 16: Idea Exchange Entries That Need More Support

I've really been enjoying all the fantastic LabVIEW 2010 features that originated in the Idea Exchange, and I'm also excited about the ones we have planned for LabVIEW 2011.  Last night, I went through the Idea Exchange and read through all the ideas that have more than 10, but less than 100 kudos.  I found 16 that I think would really benefit the LabVIEW environment and increase my productivity, but aren't currently on our roadmap of features because they haven't bubbled up high enough in the rankings.  So if you haven't already, please consider kudoing some or all of the following ideas, so we can push to get them included in LabVIEW 2012:
By the way, I got the idea for this blog post from Aristos Queue, who has already posted his own list of Idea Exchange entries that he'd like to see implemented in a future LabVIEW version.

Thursday, September 23, 2010

LabVIEW Development Tips and Tricks Webcast - Wednesday, October 6th at 11 AM

It's that time of year again...time for me to give a LabVIEW Virtual User Group presentation.  Last year, I presented tips and tricks to help you write faster VIs.  This year, I'm presenting tips and tricks to help you write VIs faster:

NI LabVIEW Virtual User Group: Tips and Tricks to Speed LabVIEW Development

Once again, my co-host will be Todd Sierer.   And yes, this is the same presentation I gave at NI Week 2010. 


And one more thing...I will be monitoring the twitter hash tag #LabVIEWVUG before and after the presentation.  So for those of you on twitter, that's one more way you can discuss the presentation and ask questions.

Tuesday, September 21, 2010

Hey Look, I'm Involved in an iPad Giveaway (Again)

It seems like everybody is winning iPads these days, and I'm helping them do it. First was the LabVIEW Coding Challenge at NI Week 2010. I easily defended my title as the fastest LabVIEW programmer on the planet, and the guy I beat got an iPad. (I wonder if they would have given me the iPad if I had taken a dive? I'm guessing not...)

And now, I'm helping judge the LabVIEW Examples Contest. To enter the contest, you must submit an example for one of the following categories:
  • Data Acquisition
  • File I/O
  • Math/Analysis
  • User Interface Controls
  • Games
  • VI Server/Scripting
You can submit your VIs from October 1st through October 25th. Our judging committee will choose finalists in each category, the LabVIEW community will choose their favorites, then Jeff Kodosky himself will choose the overall winner.

If you have any questions, please post them to the discussion forum on the contest community site here. Good luck!

Wednesday, August 11, 2010

Improvements to Quick Drop Keyboard Shortcuts in LabVIEW 2010

About a year ago, I posted about how you can write your own Quick Drop Keyboard Shortcuts in LabVIEW 2009. Now we've got LabVIEW 2010, and along with it, some enhancements to the Quick Drop Keyboard Shortcut framework. Those enhancements are as follows:
  • Backwards Compatibility - Any shortcuts you wrote in LabVIEW 2009 should port over to LabVIEW 2010 without any issues.

  • Improved Template - The QDKS template is in the same location (resource\dialog\QuickDrop\QuickDrop Plugin Template.vi), but it has many enhancements over the 2009 version:

    • LOTS more documentation describing plugin functionality
    • Code that creates an Undo transaction for your shortcut, along with logic for determining if the transaction needs to be committed (i.e. you changed something) or discarded (you didn't change anything)

  • Shared Shortcut Location - In addition to the LabVIEW-specific plugin folder where you can store your QDKS VIs (resource\dialog\QuickDrop\plugins), there is also now a shared location. If you put any QDKS plugin VIs in [LabVIEW Data]\Quick Drop Plugins, they will be available in all versions of LabVIEW on your machine (2010 and later).

  • More information from Quick Drop - The variant input to your QDKS VI will provide you with the following information:

    • A boolean indicating whether or not Quick Drop was launched from a VI panel or diagram
    • A string indicating the palette object name that was auto-completed in Quick Drop when you launched your shortcut
    • A path indicating the project item path that was auto-completed in Quick Drop when you launched your shortcut

  • Configurable Shortcut Keys - QDKS VIs in LabVIEW 2009 were named for their shortcut keys...for example, the Remove and Rewire shortcut VI was named "r.vi", because its shortcut key was "r". If you wanted to change the shortcut, you needed to rename the VI. In LabVIEW 2010, things are a fair bit more elegant. You can name the shortcut VI whatever you want (for example, I renamed "r.vi" to "Remove and Rewire.vi" in LabVIEW 2010). In its VI description, you can provide a description of the shortcut, along with a default key. This information will be displayed in the "Ctrl-Key Shortcuts" tab of the Quick Drop Shortcuts dialog:























I hope these improvements (along with the inclusion of scripting as a core feature in LabVIEW 2010), will encourage more users to write Quick Drop Keyboard Shortcuts to enhance their LabVIEW editing experience. Don't forget that, in addition to the six shortcuts that ship with LabVIEW 2010, there is also a List of Community Quick Drop Keyboard Shortcuts.

Friday, July 23, 2010

Waiting Until the Last Minute to Decide on NI Week 2010?

If you haven't registered for NI Week 2010 yet, here's a few reasons why you should:
  1. There are three days full of great technical presentations. These are the ones I want to see (including some I'll be presenting). Christina has a list, too.
  2. Lots of LabVIEW programmers will be gunning for me in the LabVIEW Coding Challenge. Maybe *you* can beat my 2-year win streak? ;)
  3. The Tuesday night LAVA/OpenG BBQ!
  4. The Wednesday night conference party!
  5. The fact that, since you're reading this blog, you can use the social media discount code "social2010" when you register for NI Week 2010 to get a discount.
And if the written word isn't enough to convince you, check out my blogger spotlight video on the NI Community page.

Tuesday, July 20, 2010

Changes to the CLA Exam

The Preparing for the CLA post is one of the most highly visited links on my blog, so I figured I should post some updates that I just learned about (thanks to JG's post on LAVA) to the way the CLA exam is now done. Much of the advice I gave in the aforementioned post is no longer valid, so I'd like to highlight some of the new features of the CLA Exam as described on the NI CLA prep website:
  • No more written portion - When I took the CLA exam, it contained a written portion that was 40% of my score. This part of the exam has been removed, which now makes the CLA a 100% practical exam.
  • Customize LabVIEW settings prior to exam start - When I took the exam, I had to spend the first few minutes after the clock started customizing LabVIEW (adding Quick Drop shortcuts, turning off auto wire routing, etc. etc.) before I even read the first question. But now, it seems you can ask your proctor to allow you to customize LabVIEW *before* starting the exam. The following is a direct quote from the new CLA Exam Preparation Guide (page 2) on ni.com: "Please note that you will not receive extra exam time to compensate for non-familiarity with the LabVIEW environment. If you need time to customize the environment, please make arrangements with your proctor to hold off on giving you the exam packet until you are ready to start the exam."
  • Sample Exam Available - There is now a CLA Practice Exam available...this is a great asset in CLA preparation that I highly recommend taking very seriously. There is also an exam solution available.
  • Requirements tracking - 30% of your CLA score is now determined by requirements tracking, the details of which are described in the practice exam and prep guide documents linked above. The exam graders will be using NI Requirements Gateway to verify requirement tracking in your VIs, so make sure you adhere to the [Covers: ] syntax described in the prep guide and sample exam. Note that knowledge of NI Requirements Gateway is *not* a requirement for the CLA.
Looking at the changes, I think they're probably for the best. I personally found the written portion of the CLA when I took it to be relatively easy and straightforward. But I know that written exams are notoriously hard to grade, and there might potentially be language barriers for some test takers. It looks like the test writers are expecting the additional requirements tracking to take roughly the same amount of time as the written portion of the exam, since the sample exam is very similar to the actual exam I took for my CLA, with the addition of the requirements tracking information.

Friday, July 16, 2010

Conclusions - The Diagram Cleanup Experiment

It's been just about a year since I embarked on The Diagram Cleanup Experiment. I attempted to use block diagram cleanup on just about every VI I wrote in LabVIEW 2009 this year. With such heavy use of the feature, I have come to the following conclusions:
  • Use it on moderately-sized diagrams - The majority of the VIs I write fit on one screen, and have relatively low levels of nesting. For these kinds of VIs, it is *way* faster to quickly write the VI, then press Ctrl-U to clean it up. The cleanup results in these cases, although not perfect, are acceptable. The diagrams are readable enough to avoid maintenance headaches down the road.
  • Don't use it on large diagrams - Diagram cleanup still has trouble with large diagrams. For top-level state machines, or similar architecture-level VIs, cleanup does not respect the arrangement of the diagram, which, for these VIs, is crucial to the understanding of the VI. I have decided that it is still best for me to arrange these diagrams myself.
  • Don't use it on heavily-nested diagrams - As I mentioned in my progress report, diagram cleanup completely explodes the diagram if there is heavy structure nesting. It simply can't figure out how to condense space in multiple frames simultaneously. Until it does, I will continue to arrange heavily-nested diagrams myself.
  • Mixed results with Tools > Options settings - I tried several times to tweak the settings in Tools > Options > Block Diagram > Block Diagram Cleanup to see if that would improve the cleanup arrangement, but I couldn't figure out a definitive collection of settings that always worked better. If anyone has any specific suggestions for settings that seem to improve the cleanup layout, let me know.
So what's next? I just posted the following idea on the LabVIEW Idea Exchange:

Tell Block Diagram Cleanup what "Clean" Looks Like

I think the easiest way to get diagram cleanup to arrange VIs to my liking is to show it VIs that I like. :) Please kudo the idea if you agree.

So that's pretty much it. In short--I like the feature, I will continue to use it because it helps me program faster, but it definitely has room for improvement.

Monday, July 12, 2010

My NI Week 2010 Plans

Once again, Christina beat me to the punch and already posted her NI Week 2010 plans. So after each morning's keynote, here's where you might expect me to be. The ones with "***" are the ones I will definitely be attending. All the rest I'm planning to see, but standard NI Week allowable distractions may apply:

Tuesday
  • State Machine vs. State Machine: 10:30, Room 12B.
  • ***LabVIEW Add-on Developer Lunch: 12:00, Ballroom C.
  • What's New in LabVIEW 2010: 1:00, Room 12B.
  • LabVIEW 2010 Idea Exchange Features: 2:15, Room 11A.
  • ***Tips and Tricks to Speed LabVIEW Development: 3:30, Room 12B. I am delivering this presentation.
  • Team-based LV SCC Development: 4:45, Room 12A.
  • Challenge the Champions: 6:00, Technology Theater.
  • ***LAVA BBQ: 7:00, Scholz Garden. Aww yeah!
Wednesday
  • ***Blogosphere's Best: 10:30, Room 11A. I was asked to show up to this, but I don't know what exactly I'll be doing, if anything.
  • Powering a Smarter Planet: 1:00, Room 16B. If I weren't a LabVIEW programmer, I'd probably be a solar power researcher. So renewable energy presentations are always very interesting to me.
  • Deployment of Large LabVIEW Apps: 2:15, Room 12A.
  • LabVIEW Web UI Builder: 3:30, Room 12B.
  • LabVIEW GUI Design: 4:45, Room 12B.
  • ***NI Week Conference Party: 7:00, somewhere cool.

Thursday
  • LabVIEW Classes - The State of the Art: 10:30, Room 12A.
  • ***LabVIEW Coding Challenge: 12:00, Technology Theater. I've won two years in a row. This will be the third.
  • LabVIEW Class Design Patterns: 1:00, Room 12A.
  • LabVIEW WSN Under the Hood: 2:15, Room 15. I studied wireless sensor networks a fair bit in grad school...I'm curious to learn about the LabVIEW WSN module.
And a few miscellaneous notes to round this out:
  • I will be tweeting out the wazoo about all the cool stuff I see at NI Week 2010. Make sure to follow me (@dnatt) if you don't already.
  • As is traditionally the case, things aren't quite right with my presentation in the NI Week 2010 schedule. The title of my presentation (Tips and Tricks to Speed LabVIEW Development) is correct, but the abstract incorrectly talks about speeding up VI performance. For those keeping track, my NI Week presentations the past few years have been:
    • 2007 - Tips and Tricks to Speed LabVIEW Development
    • 2008 - Tips and Tricks to Speed LabVIEW Performance
    • 2009 - Tips and Tricks to Speed LabVIEW Performance (with all new tips!)
    • 2010 - Tips and Tricks to Speed LabVIEW Development (with all new tips!)
    So this year we're back to development tips and tricks. Be warned: Quick Drop just *might* make an appearance... ;)

Monday, June 28, 2010

Quick Drop in LabVIEW 8.5

Even though Quick Drop was introduced in LabVIEW 8.6, there have been rumors on the internets that an 8.5 version existed. Those rumors are certainly true, since I prototyped Quick Drop well before LabVIEW 8.6 released.

I finally had some time to post my Quick Drop 8.5 prototype on the NI Community site. If you want Quick Drop functionality in LabVIEW 8.5, then download the prototype here:

Quick Drop in LabVIEW 8.5

Tuesday, June 8, 2010

I Like Global Variables

I think the title of this post alone will probably lose me some followers on this blog. :) Nevertheless, let's proceed...

Here's the deal...global variables are not evil. There are perfectly valid use cases in which a global variable is the best tool for the job, and doing something more complicated just to say, "I didn't use globals!" doesn't make sense. Now sure, globals can be abused, and there are certainly scenarios where they are contraindicated. But if you're aware of those situations, and you avoid them, you should feel free to use globals where needed. So let's look at some use cases where, in my opinion, globals can come in handy:
  • Static Data - Whenever I create a UI in LabVIEW in which user-visible strings are programmatically changed, I always store those user-visible strings in a global variable. Let's call this kind of global a Write Never, Read Many (WNRM) global. I am never writing new values into this global...I'm only reading from it in my code whenever I need to update a user-visible string. Another use case for WNRM globals is in scripting apps. When I'm doing code generation involving templates, I always store the identifying labels of panel/diagram objects within a global, and I always read those identifiers from a global in my scripting code. That way, if I need to change the identifiers in the templates, I know that I'll only need to change the identifier in one place (my global) in my scripting code. (Note: I believe Yair's Adding CONSTs to LabVIEW idea on the Idea Exchange is intended to facilitate a cleaner implementation of this use case.)
  • Debug Flags - If I've got parts of my code that I want to run differently when I'm debugging, I use a WNRM global. I'll open the global and change the debug flags before I run my code. Someone once suggested that I should instead use Conditional Disable Structures with conditional symbols in my project, but after I looked into it, I decided that the added complexity and configuration associated with conditional symbols didn't add enough value over the simple global solution.
  • Configuration Data - In this scenario, we are initializing configuration data (from an INI file, for instance) at some point in our code, and reading that data at later points. So here we have a Write Once, Read Many (WORM) global. (Note: The term WORM global was first coined by tbob on the NI Forums a few months back.) As long as there is one, single place where the global is written, it is perfectly fine to have many other places in your code that read that global.
Now one of the biggest reasons given as to why globals should be avoided is that new users could easily find themselves in race conditions if they're not careful. But with the use cases above, there should never be any worry about race conditions, as long as developers adhere to the WNRM/WORM constraints. I don't think we should hamstring ourselves with a blanket refusal to use a feature when it really can be a performant time-saver when utilized correctly.

Monday, March 22, 2010

CLA Summit "Trip" Report

(I say "trip" because it wasn't much of a trip for me...just a walk down two floors. Contrast that with a few of the attendees who flew in from Europe...)

I had a good time at the CLA Summit two weeks ago. We had about 30 CLAs attend the two-day summit here in Austin. Here's a chronological summary of the discussions and events:
  • LabVIEW Classes - data vs. reference - This was a discussion between Damien (of Dr. Damien fame on the NI Forums) and Stephen (Aristos Queue on the NI/LAVA forums) that boiled down to Damien's use of LV Class data wrapped within single-element queues in his xylophone project that he discussed at length on the NI Forums. Damien spent some time justifying his choice for this mechanism, and Stephen seemed like he was wondering why it was necessary. My feelings on the matter generally lined up with Stephen's in this case...
  • Error Handling - We listened to several CLAs present on different aspects of error handling. These included current solutions (like an FPGA<->Host error handling mechanism) and future ideas (like exception handling). The best part of the whole discussion is that some concrete ideas and action items came about for improvements (see here). Hopefully we can come up with another challenge topic as rich as this one for the CLA Summit 2011.
  • My tour of shipping VIs - I presented a tour of the architectures for several shipping G-based LabVIEW features. Since the CLAs were all under NDA for the summit, I was able to show some of the password-protected VIs from App Builder, MathScript, Tools>Options, and VI Analyzer. One thing that some of the CLAs said stood out to them was how heavily we use LabVIEW Classes in some of our own features.
  • CLA Recertification Exam - The CLAs all took part in the new CLA-Recertification exam. I didn't take the exam (since I wrote some of the questions for it), but the feedback I heard was generally positive. I can't imagine anyone would turn down the opportunity to recertify with a 1-hour multiple choice exam instead of having to take the entire 4-hour written/coding exam again...
  • New Features for Large Application Development - Eli gave a long discussion on all of the LabVIEW features and addons that have to do with large application development. One of his common questions to the audience was to find out why people were *not* using some of these products. The discussion became very tangential several times, but overall, I think we got some valuable feedback. For me personally, I got some good ideas during this discussion (and some of the social events) for improvements to the VI Analyzer if I get some significant project time to devote to it for the next release.
    Note: There was a parallel discussion going on at the same time as this presentation regarding RT/FPGA stuff, but I didn't attend that one.
And in addition to all this stuff, there was also a fun dinner at Brian's house Monday night, and I had the privilege of having dinner with several CLAs who were still in town Tuesday night as well. Overall, I think it was a great event (and the CLAs seemed to like it too). I enjoyed the rather unique position of simultaneously being a LabVIEW R&D developer looking for ways to improve the product, a CLA giving feedback on ways to improve the product, and getting ideas from other CLAs on how to be a better LabVIEW developer. I'm already looking forward to the next CLA summit in 2011.

Monday, January 11, 2010

Ain't No Party Like a CLA Party...

If you are a Certified LabVIEW Architect, make sure you are in Austin on March 8-9 for the first-ever CLA Summit. In case you didn't get the memo, here it is. We also have an NI Community Group with more information and discussions about the event. There will be presentations (one of which I'll be giving), coding challenges, hang time with LabVIEW R&D, and much more. And even if your CLA certification is expired, you can still show up and recertify with the new one hour recertification exam.

So if you are (or were) a CLA, come on down to Austin in March, and make sure to bring some warm weather with you!