I’ll be personally attending each of the following NITS events:

• Detroit, MI October 9
• Irvine, CA October 14
• Santa Clara, CA October 16
• Boston, MA October 28
• Raleigh, NC November 5

Additionally, I’ll be presenting a technical session, Effective LabVIEW Code Reuse Strategies and Tools, at the Santa Clara, CA (October 16) and Raleigh, NC (November 5) events.  This presentation was sold out (standing room only) at NIWeek 2008.  So, make sure to get there early to get a good seat

The purpose of attending all these events will be to spread the word about VIPM Professional and how it can help LabVIEW developers and their teams take control of their reusable VIs.  I’ll be giving live demos at our booth showing people the benefits of VI Packages and chatting with people about how they reuse LabVIEW code in their projects and with their team members.

During our NITS tour, I’m looking forward to learning a lot, meeting new people, and visiting with colleagues, friends, and customers.  I hope that you can make it, too.   If you can, please make sure to stop by the JKI booth and say hello.  I’d love to meet you.

The XML Parser VIs (shown below) can be found in the Functions Palette at Programming>>File I/O>>XML>>XML Parser .

One major drawback of these VI’s is that they still don’t make it easy to work with XML data.  Don’t get me wrong, I love the fact that these VIs ship with LabVIEW.  In fact, they expose more people to XML and thus create more demand for an easier approach to working with XML in LabVIEW.

So, how does it work?  Basically (and I’m paraphrasing greatly), the remote control has an infrared camera that is looking at two LEDS (which appear as two bright dots to the remote’s camera) on the LED bar, which sits on or near your screen.  The remote calculates the position and orientation of the remote relative to the LED bar (and thus the relative position of the remote relative to the TV/Computer, after a simple calibration step).  The remote then transmits this position and orientation data via RF to a receiver in the LED bar, which then is communicated over USB to the computer.

It might have been partially due to Anders having a lot of practice using the Wavit, but it seems like a very efficient way to control a computer.  After seeing the demo, I can’t help but think that this will be one of the principle ways that we interact with computers and televisions, very soon.

Another reason that this demo was cool, was that Anders showed off a lot of very impressive LabVIEW software that the Wavit controls and communicates with.  ThinkOptics provides free LabVIEW drivers for the Wavit, so that you can use it to control anything that you can control with LabVIEW!  Now, how cool is that?

What reminded me, today, to write this post is that I watching a talk by Clay Shirky.  In it he describes an event where he’s having dinner with some friends and the friends’ four-year-old runs behind the TV to look for the mouse (because, TVs should obviously have a mouse to control them):

I was having dinner with a group of friends about a month ago, and one of them was talking about sitting with his four-year-old daughter watching a DVD. And in the middle of the movie, apropos nothing, she jumps up off the couch and runs around behind the screen. That seems like a cute moment. Maybe she’s going back there to see if Dora is really back there or whatever. But that wasn’t what she was doing. She started rooting around in the cables. And her dad said, “What you doing?” And she stuck her head out from behind the screen and said, “Looking for the mouse.”

Here’s something four-year-olds know: A screen that ships without a mouse ships broken. Here’s something four-year-olds know: Media that’s targeted at you but doesn’t include you may not be worth sitting still for.

I think it’s cool that LabVIEW is helping to shape the future and fixing the things that are broken in our world.  And, it’s very cool to be in the San Francisco Bay Area and get to see these new inventions, and their inventors, first hand.

LabVIEW has been highly successful in industry, where it really has become a tool of choice for engineers who need to automate test, measurement, and control applications.  Additionally, the NI platform is well poised to be a tool of choice for system design, development, and deployment, as industry sees that the graphical approach, with a fully integrated tool-chain, just makes a lot of sense (because it saves time and money).

However, universities and engineering schools are very entrenched in both older (and freely available, open) technologies.  These academic institutions currently feel the top-down weight of industry demanding engineers who are proficient in LabVIEW and will soon feel the bottom-up swell of myriad youngsters who learned LabVIEW while playing with the Lego WeDo and Mindstorms and then participating in FIRST Robotics Competitions.

Universities won’t have any choice but to start using LabVIEW to teach a variety of engineering courses, because students will be demanding it — that’s the squeeze. When this happens, NI will have realized its goal of getting LabVIEW to be used everywhere from “K through Rocket Science” (an NI marketing mantra).

Now, I don’t want to undermine what an incredible thing NI is doing by helping educate our youngsters, using LabVIEW — I’m just saying that it’s a pretty smart move

Note: I wish that LabVIEW was a standard at UC Berkeley, back in the late ’90s, when I was in school.  I was fortunate to get a student research assistant job at LBNL during my first year, which lasted through graduation, where I was assigned the task of learning LabVIEW and adding a couple features to spectroscopy control and data acquisition system.  I loved LabVIEW and had to fight hard to get my instructors to let me use it for my assigments instead of HP (now Agilent) VEE.  Anyhow, I kept using LabVIEW all through school and decided to keep using it, to this very day.

OpenG has been green since 2001! In fact, we’re known throughout the LabVIEW community for how green our VIs are

But, that’s not the only way that OpenG is green.  Think of all the energy (both mental and electrical) that is saved by not having to write these VIs yourself!  (Thanks, Antoine, for reminding me of this fact.)

This year, at NIWeek 2008, we saw a demo of the new Lego WeDo platform that allows primary school students, 7–11 years of age, to build and program Lego robots.  The demo was given by a youngster named Sara, who showed how to program robotic animals like a pro, using LabVIEW. (here’s a video of Sara that will blow your mind — jump to the 8 minute mark).

Seriously, watching this keynote demo almost made me cry (in a happy way).  I get very emotional seeing kids who are excited about learning and being able to express their creativity (it probably has something to do with the fact that I also love Legos, LabVIEW, and robots).

Last year, at NIWeek, we saw Samuel Majors, a 10 year-old wiz kid who uses LabVIEW to control model trains.  I can’t wait to see what kids are doing with LabVIEW, next year.  And, I can only imagine what these kids will be doing with LabVIEW when they hit the work force!

It is really amazing what an opportunity NI and Lego are providing young people and I hope that every parent get’s this message:

Start your child programming Legos in LabVIEW, now! Computers aren’t just a window into the world and a way to find information.  Those who can effectively use computers to automate our world are in top demand, and that isn’t ever going to ever change.

# 5 – You (and your team) aren’t using the reuse library.

You used to have big plans for your reusable VIs.  You organized them.  You had meetings to review them.  You assigned someone the job to clean them up and create a great big library for everyone to share.  But, that was years ago and, after an initial burst, progress and interest tapered off. You realized that reusable VIs were either too much trouble to find or too much work to maintain.  You’re not really sure what went wrong, but something did go wrong because your reusable VIs (and all the effort that was put into them) aren’t being reused.

# 4 – You haven’t added new VIs to your reuse library in years.

Something killed the fun and/or productivity gain you thought would be realized when you started your reuse library.  You’re not really sure what it is, but you know that it’s just too much work to reuse VIs.  Sure, you’re reusing a VI here and there, but your grand reuse library isn’t really growing — it’s just too much work add new VIs to it.

#3  - You’re missing VIs when you open your project and palettes.

You write a great reusable VI for project A, so you copy it over to project B.  Then, you find and fix a bug in a reusable VI while working on B, so you copy the fixed VI over to project A.  When you try to open your project after copying your reusable VIs, you’re missing some important subVIs.  Or, maybe they are missing from your LabVIEW palettes after you spent hours getting the palettes just the way you like them.  You spend even more hours trying to find the missing VIs and put all the pieces back together.  In the time you spend, you might as well have just rewritten the VIs from scratch.

#2 -  You have multiple copies of your reusable VIs in several projects, but they’re all slightly different.

When projects are started you always grab the latest and greatest version of your reuse library.  Why wouldn’t you?  Then, as you work on your project, you find and fix a few bugs, and add a few useful VI inputs and features.  Like most people you tend to work on one or two main projects at a time and do occasional maintenance on a handful of others.  But, when you’re working on a project you’re more focused on getting the job done, than you are in making sure that your “main reuse library” gets updated (or that the copies of it in various projects are kept in sync).  As a result, each project has a slightly different copy of your reuse library.  In fact, you might have even fixed the same bug multiple times in different projects.  And, you’re not really sure which projects have the fix and which ones still have the bug.

1) You’ve rewritten the same VI over a dozen times!!!

You have had ambitions to create a reusable VI library, but you never really got around to it (or, you’ve tried and not gotten very far). It’s way easier to just rewrite that VI than to find the one that you already wrote, because you have no idea where that other one is.  But, you’re rewritten that same VI at least a dozen times and it’s driving you crazy.  You’ve just about had it. You wonder, “I’m an engineer, so why you keep reinventing the same wheel?”

So what now? Should you give up on the idea of reusable VIs?

Of course, we should not give up.  One great solution is VI Package Manager.  Stay tuned for my follow-up article The 5 steps to take control of your reusable VI library where I’ll tell you everything you need to know to regain control.

And, I’d like to take this moment to give a big “thank you” to all the readers of Thinking in G — especially those of you who leave comments regularly. I love hearing what you all have to say

Here are some of the new favorites that got me excited:

• Save As (on your project file) — LabVIEW 8.0 and 8.2 do not have Save As for a project and I really missed this expected feature. Now, in 8.5, NI has exceeded my expectations You can also rename and save a copy of your project, and even choose subsets of the project for the new copy.
• Immediate update of Dependencies after adding new project items. (I wonder if I can set Destinations based on a Dependencies location)
• Show file paths in Items View (it would be nice if there were a setting to show the paths relative to the project file’s parent folder [if located beneath that folder] instead of absolute paths.
• Show Callers and Show Callees when right-clicking on VIs in the project explorer (hmm… I wonder if this works for Classes, yet — e.g., Show Parent and Show Children.)

These features really make using the project explorer a lot more enjoyable. Thanks, Christina (and LV team)