Waterloo Labs strikes again!

Chances are good that you’ve already seen this.  If not, be sure to check out the latest episode of Waterloo Labs: How to drive a car with an iPhone.

Enjoy.

Hardware Abstraction Layers and the German Rail System

See if you can guess what this photo is?  (Answer below).

How do you architect your test software to manage hardware obsolescense?

Is hardware obsolescence a challenge for you?  I particpated in two different Automated Test Customer Advisory Board (AT-CAB) meetings in the past month in Germany and France where we discussed strategies for handling test system hardware obsolescence.  The challenge is well-documented in mil/aero systems when the unit under test (a jet fighter, missile system, etc) has a life span of 30 years or more, you’ve got to deal with instruments in your test system going obsolete at some point during that time.   In addition to the business aspects of this problem - like budgeting and planning for system upgrades periodically, and developing a strategy for spares and repairs – we work a lot with people on software architectures that make it easier to swap in new instruments without requiring major rewrites and re-validation of code.

This continues to be a huge focus area for test engineers.  It’s refreshing when customes really open up and share key concerns and issues that they are struggling with.   For the latest AT-CAB, we actually have the customers break up into groups and brainstorm, prioritize, and present back with their recommendations.  It can also be an eye-opening experience – for as much as we talk about developer productivity, one customer explained that they spend 25% of their time on developing and 75% validating, updating, and maintaining their test code.  These discussions are great to help drive our efforts at the issues that matter most.

We’ve worked for many years on instrument drivers over the years.  I was personally very involved in the development of the Interchangeable Virtual Instrument (IVI) driver architecture.  We defined and built a lot of technology into IVI, and we’ve learned over the years that you can’t simply buy drivers to give you interchangeability out of the box.  We have seen companies be successful with a software abstraction layers – many based on IVI drivers and others on native LabVIEW implementations.  We’ve recently created some presentations with some recommendations on how to approach hardware interchangeability for the protecting against obsolescense:

• A white papwer with example code  on hardware abstraction
• A short webinar about hardware abstraction

My Latest Experience on the German Rail System (and Highways)

Now for the picture.  After the last AT-CAB meeting, I joined our European branch marketing managers in Germany to spend a day discussing our software business and LabVIEW adoption strategies (a subject for future blog posts).  After the meeting, we all jumped on the train back to the Munich airport.  One stop before the airport, the train stopped and the conductor announced we are going no further – so we all climbed off the train, over a bridge, and down to a bus stop at the side of the road – where 500 people were in line for a bus that was nowhere in site.  Someone then had the great idea to walk to the airport, amid cries of “the terminal is right there…”   Like most major airports, there are big looping highway exits that take you to the terminal doors.  So what appeared to be a few hundred meters away was actually about 2-3 miles.

I was walking with my colleague from Italy, who joked that we expect this kind of problem in Italy, but the Germans are renowned for their efficiency and timeliness.  I promised him I would post on the topic to ensure our German counterpart was made aware of the situation.   We were laughing at ourselves so hard that I had to take a photo with my phone.  You can barely make out the sign for the exit to the airport above the shuffling masses in fear of their lives (and of missing their plane).  It’s a little blurry because I was walking as fast as I could carrying my bags while trying to avoid slipping off the curb to get crushed by a speeding Mercedes. 

Just another event in the glamorous world of business travel – I’m sure many of you have your own stories.

Are you part of a user group?

We are deep in the middle of planning for 2010 right now.  One of the areas we want to continue to invest in (or perhaps raise our investment) is around user groups.  Working with user groups can be a tricky topic for us – the best groups are those run completely by customers, and they tend to be the ones who don’t want a lot of interference from NI trying to “sell” them on products.  On the flip side, we are often asked for new technical content that can be used for user group presentations. 

Feel free to comment on this topic – I’ll create a poll to make it easier to respond:

 

Physical User Groups
If you are looking for more information on user groups.  you can learn about physical user group meetings in your area at http://www.ni.com/usergroups

Virtual User Groups
We have a new capability on our Web site for creating virtual user groups.  Most of these are organized around specific topics like “Building Large Apps with LabVIEW” or “RF Testing” and so on.  You can see a list of these at http://decibel.ni.com/content/groups

Feel free to comment with any specific ideas for future user group meeting topics you would like to see…

3 Development Tips for the Serious LabVIEW Programmer

The other day I ran into LabVIEW developer Phil Joffrain, one of my friends from my R&D days, and asked him to share some of his tips for serious LabVIEW development – we settled on three “random tips about under-utilitized development features” as the approach.  Phil is a hardcore computer science major who has been working at NI for 7 years.  He has worked on our LabVIEW SignalExpress project, which is a unique combination of a LabVIEW-built application running within a C/C++ application framework – so Phil is constantly switching contexts in terms of programming language – he is an expert programmer using LabVIEW for professional development.

Here are three tips for hardcore users – this may be something new for you to consider, or it may be old news.

1. Type Defs:

Large application constantly need to pass around bundles of information. Bundles of information obviously come in different types, but more importantly, the type of information can sometimes change either midway through development, or from release to release. An easy way to bundle information in LabVIEW is to use a Cluster. Clusters, for example, which contain a fixed number of items could in the future need to contain more or less items. But when a cluster being used by a large number of subVIs needs to update, it’s simply not feasible to open each and every subVI to update the cluster being passed in by hand (or by writing a tool to do it). Instead, turning that cluster into a Type-Def solves this problem since changes made to a type-def update all consumers automatically. It’s also important to note that there are 2 types of type-defs in LabVIEW: regular type-defs, and strict type-defs. The difference (as the name implies) is in the level is strictness and the frequency by which the type-def will update when changes are made to it. Strict type-defs contain the most information about its contents and force updates most frequently. Now type-defs are not simply a good idea for large clusters of data, they are also very useful for single item types. Imagine for example, an internal API where a set of subVIs take in a control reference. If this is a strict reference (meaning that extra information about that control is associated with that reference), making a change to the original control will change the strict reference type and break that input to all our subVIs. Having a strict type-def which simply contains that strict control reference means that only one place needs to be updated, to automatically propagate that change. When a number of subVIs take in the same type of input or produce the same type of output is when using type-defs makes sense.

2. User-Defined Events for the Event Structure

Most large applications have to process requests or provide the application with actions to perform. The LabVIEW event structure is an ideal tool to do this. The common use case for the event structure is often associated with processing control value changes on a User Interface, but this is only scratching the surface of the event structure’s usefulness. First of all, what makes the event structure such a useful tool, is that it doesn’t poll the UI for changes, nor does it steal the CPU waiting for things to happen. When no timeout is set on the event structure, it is happy to wait and wake up only when needed (unlike old-style state machines that comprise of a while loop and case structure). But the main feature of the event structure that is often overlooked is User-Defined events. A developer can create custom events that can be received by the event structure. This allows the developer to create a messaging system to process requests and define actions to be performed. The powerful thing about User-Defined events is that a developer gets to dictate what information gets sent to that event via the event’s internal terminals. A very simple example of this is: you can create an event called “save”, which has a path attribute. When the event gets called, the path attribute can be accessed using that events terminals, and the application can save its state at the path given. It is the caller of the event who would have gotten to specify what path to provide. Old and alternative ways of doing this was to use a LabVIEW Queue, who’s elements would either be a cluster of the data you wanted to pass around, or a variant so that anything could be passed. Both of these techniques have issues. One places a burden on the type of data that can be passed in the cluster, the other places the burden on the receiver of the data to extract it from the variant. The event structure removes both of these burdens by allowing each event type to have different data passed to them, and by giving direct access to that data within the event case via the internal terminals.

3. LabVIEW Classes

A relatively new feature to LabVIEW which is becoming mainstream very quickly is LabVIEW Classes. The fear with using a new feature is often the potential instability and performance hit, but a lot of time and effort has recently be put into LabVIEW Classes to make them more stable, faster and quickly becoming a mature feature of LabVIEW. The benefits of using LabVIEW Classes are the same as using any object-orientated programming approach to a large application; scalability and modularized components are among the top reasons. A lot of large applications today need an easy way to “plug in” new features, or new tools. When these new features or tools share common information and common abilities with the existing ones, having a base class with that information and ability that a new feature or tool can inherit from simplifies code greatly. A new plug-in no longer needs to start from scratch nor start by copying over half the code, it simply “plugs in”. Adding the extra functionality to that new feature or tool’s class is all that is left. In addition, new information and abilities added to the base class are automatically also available to the classes that inherit from it.

How complex is your LabVIEW code?

In a recent post on sumerlin.com, the author bemoaned the fact that the software industry has made great strides in programmer productivity with new visual tools (like LabVIEW), but has done so at the expense of visibility into the size of the code.  His blog harkens back to the exact day that his guys re-wrote more than 30,000 lines of FORTRAN and Assembly code for simulating satellite communications in LabVIEW in just a few days.  This event was what pushed the author into the ranks of management because “at his age” he could no longer keep up with the latest productivity tools in the new “visual” programming world.  (He actually never mentions LabVIEW, but instead he refers to GOOP - the graphical object oriented programming tools from Endevo/Flander)

First, let me say that our goal has never been to push people out of programming.  In fact, through efforts like our partnerships with Lego Mindstorms and FIRST Robotics, we are working hard to bring more kids into programming.  But that’s not the point…

The issue is that the programming industry, particularly in mission-critical application areas, has spent years building tools, tactics, and programmers’ intuition around traditional code complexity metrics like single lines of code (SLOC).  Although we can find lots of examples where graphical programming is more advantageous than text-based code (see multicore), we can’t ignore all of the history and infrastructure built up over the years around text-based languages.  Users need some methodology for measuring the complexity or size of their projects – for estimating project  timelines/cost, for comparing programmer productivity, or for planning maintenance. 

We’ve built a lot of tools and integration over the past 5 years to address some of these traditional software engineering challenges with LabVIEW.  More specifically, LabVIEW has tools built into the Professional Development System for measuring the complexity of your code, as well as some tests you can run with VI Analyzer for measuring cyclomatic complexity of code.  This is just another one of the efforts we’ve made to map LabVIEW to the traditional programming process for large applications. 

My question to any of you LabVIEW users out there – are you using these complexity metric tools?  Or better yet, were you aware of them?  Let me know.

Guns, Fireworks, and Nerds: Hope for the Future

Following up on my earlier “LabVIEW on TV” post, I wanted to share with you a grass roots effort from a group of our AEs here in Austin who refer to themselves as Waterloo Labs.  Our AE department is full of recently graduated engineers and computer scientists from some of the top schools around the country.  Once they get more acquainted with our products and technology, they tend to find very creative ways to experiment with it.  These guys are taking it one step further.  They are combining our cool technology with their interest in movie making and multimedia, and creating their own web-based version of a MythBusters-like show called Waterloo Labs.  I urge you to check it out – it’s pretty cool, in a geeky sort of way.

We spend a lot of our time in Marketing trying to figure out ways to penetrate the hardcore programmers of test and embedded systems out there with our graphical programming story.  We are constantly looking for ways to make more credible arguments with benchmarks, case studies, and code examples to convince experienced programmers that LabVIEW is a valid alternative.  

A different approach is to go after the next generation and get kids excited about our technology before they ever get “stained” with the traditional approach.  We experiment with a lot of ideas to try to get kids interested in technology in general, and LabVIEW more specifically.  Also, because our tools are so widely used, we have to learn how to market through the channels that are emerging – YouTube, Twitter, Facebook, etc.  We do a lot of experiementing to see how we can get people interested in our tools beyond the traditional marketing approaches.  These Waterloo Labs guys are driving right down the middle of all of this – and its all driven from their own interest and passion in the technology and the media.  Their latest video has more than 200,000 views.

It’s interesting to talk to the crustiest, most entrenched, hardcore programmers who are so set in their ways that they swear they could never switch to LabVIEW even if they wanted.  These sames guys are the ones who light up when you tell them that their kids can program robots with LabVIEW.   Perhaps more cool videos like Waterloo Labs is what we need to be doing.

Final NIWeek Thought: The real reason to come next year

A little side note about NIWeek…

The last night of NIWeek, after the annual Wednesday night NIWeek party, I was reminded of the real reason you should consider coming to NIWeek next year.  We stumbled into a bar on 6th street sat and watched an amazing blues guitar virtuoso jam out for about 3 hours of some of the most ear-splitting, face-burning, mind-blowing guitar pyrotechnics I’ve ever seen to a “crowd” of about 9 people for no cover charge.  There is something really cool (and tragic) about seeing a talent that good in a place that small.  It was awesome. 

So talk about all of the great networking and coding techniques you can pick up here when you are convincing your boss to come next year, but keep artists like Eric Tessmer  in mind.  (and don’t forget a really good alarm clock – those Thursday morning keynotes are great)

NIWeek 2009 Thoughts – Part 1

NIWeek 2009 is in the books, and NI as a whole is recovering from our annual NIWeek hangover.  A few thoughts looking back at the week:

1. Attendance was stellar – we actually saw a slight increase in attendance over 2008 numbers.  For those of you who were able to join, a big “thank you” for investing your time and energy by coming to the conference.  We recognize that any kind of expense is going to be looked at very closely in these tough times.

2.  Graphical System Design as a concept seemed to get its legs at this NIWeek.  The notion of using LabVIEW beyond its test and measurement roots as a system design platform was evident throughout the conference.  The tremendous activity around robotics was the strongest testament to this.  Not just the technologies and success stories, but the people who showed up who are involved in this area was impressive – Dean Kamen, Ellen Purdy, Dr. Dave Barrett… (more on that in a separate blog entry – it’s justified).

3. The future of LabVIEW is bright – for the first time in awhile, we shared some of the new technologies that we are developing in LabVIEW and there was genuine interest and excitement from the users.  In particular, we are doing some things to address some core issues with the product and language in the short term (next year or two), as well as starting to reveal some of our 3 to 5 year plans that will have an even greater impact.  It’s always exciting to see the amazing solutions from our users each year at NIWeek.  It’s even better to see the smiles and fist-pumps from users when you let them know where we are going to confirm we are working on the right things.  (I’ll have to figure out how I can post on some of this stuff for those of you who were not able to make it to NIWeek).

4. The Austin Convention Center re-affirmed its position as the coldest building in North America.  I think the HVAC system there alone could cure our global warming problem.

… more thoughts to come….  Anyone who was there, feel free to tack on with your own comments.

More on the VI Snippet

I had so many people ask me the same question, that I went ahead and created a new post to answer:

When you create a snippet, we indicate that fact two ways:

• the image is surrounded by a dashed line
• the snippet glyph is appended to the top of the image

See below for an example.  Feel free to drag this into a blank LabVIEW 2009 VI to try it out.  Or you can see more here.

Scripting: Get inside the guts of LabVIEW at NIWeek 2009

NIWeek 2009 – Getting back to the (deeply technical) basics. 

That was one of our goals for NIWeek this year.  In the past several years, we really pushed the envelope into application areas with the Summits – mini-conferences within NIWeek – on topics like RF, Sound and Vibration, Vision, Robotics, etc.  These have been great at attracting experts from these areas and having more topical discussions about trends and techniques.  However, we still believe that NIWeek at its core is about LabVIEW and what you can do with it.   This year, we made a concerted effort to “go deep” and deliver very technical presentations at the conference.  Two areas where we got a lot of great attendance and feedback were on the LabVIEW Scripting session and the LabVIEW for large applications. 

The scripting session had over 180 people in attendance.  Scripting refers to the set of APIs you can use to edit or generate VIs – use LabVIEW to create macros if you will.   You can learn more about it at our LabVIEW APIs community group.   We also highlighted some pretty cool uses of scripting in a video we showed during Jeff K’s keynote.  Check it out:

The LabVIEW for Large Apps sessions was standing room only as well.  It covered all the tools and techniques for using LabVIEW in a large, team-based environment for large projects, including topics like:

• Configuration Management (Source Code Control, Diff, Merge, etc)
• Requirements Management
• Testing and Debugging (Unit testing, dynamic and static code analysis, etc)
• Documentation and validation

Yes, we have tools for all of these.  Check it out at at www.ni.com/largeapps