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.

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

Birth of a Feature: The improbable story of VI Snippet

The next version of LabVIEW will be coming to a presentation near you very soon.  I thought I would share the back story about one of the new features that you will see called the VI Snippet. 

First, the problem statement.  For many years, we’ve been working on better ways to empower users to share their code with other users – through better Web features on ni.com and better ways of packaging and distributing your VIs.  The popularity of the platform, and the expertise of our user base, can be measured in some ways by the number of VIs available on the Web – it’s a kind of currency for LabVIEW. 

We have a few challenges in enabling users to share code:

1. LabVIEW is graphical, so you really need to see the block diagram to understand what techniques you want to learn more about
2. Seeing the diagram ins’t enough – it needs to be easy to get the VI from a Web site into your LV environment so you can experiment with the code.  One advantage text-based languages has is you can simply cut and paste text from any document into your environment to transfer it.  LabVIEW code needs to move that easily. 

With these seemingly insurmountable hurdles in the way, enter the Hogg – that would be Simon Hogg, one of our talented young LabVIEW product managers.   Simon had some ideas on how we can create a better experience for users to share code, but rather than try to convince R&D to build something, he went off and built it prototyped it himself (the beauty of LabVIEW for fast prototyping).   The idea is simple, but when implemented comes across as magical.  In LabVIEW 2009, you create a special screen shot of your VI – called a VI Snippet – which embeds the actual binary information of the VI into the image.  You can then post that image anywhere on a Web page and other users simply drag the image onto a blank block diagram in LabVIEW and voilá! – the actual LabVIEW code is there, ready to explore, edit, or run.   Check out the video below to see it in action:

Once Simon created his prototype, it was quickly dubbed internally as “the Hogg Feature” or “the Hogg” for short.  We’ve even taken it to its verb form – similar to “googling” or “xeroxing” something, when you distribute a VI Snippet, you are “hogging it.” 

Naturally, there was the small step of actually designing, implementing, and testing the feature in R&D to make it work in the product for real – but having a working prototype was a great influencer.  If one of our product managers can prototype the feature, then certainly our R&D guys can develop it. 

So I wanted to share this story to show that even the best-laid plans at NI to smoothly manage the feature set of upcoming LabVIEW versions can be disrupted here when someone combines initiative with the power of LabVIEW programming to make something happen (and because the Hogg is a cool feature).  I look forward to “hogging” some VIs posted by the c0mmunity of LabVIEW users in the near future.

What do you want to see in a roadmap?

I’ve been busily updating our LabVIEW roadmaps for NIWeek next week and once again I am faced with the challenge of creating a presentation that is relevant to a crowd of LabVIEW users – we are doing so many things with LabVIEW, that is more difficult than you think.  So as I am preparing for next week, I thought I would hit the user base to see what you guys want to know. 

My goals for a roadmap presentation are:

1. Show your loyal users that you are hearing them and understand their concerns, and share our plans to address these concerns

2. Explain our higher-level strategy and investment directions (for example, if you aren’t considering the benefits of using LV FPGA with our RIO architecture, you need to)

3. Recap where we are today – most users can’t keep up with everything we are doing

4. Speak to the skeptics in the room with an honest assessment of key issues that have and share plans to address those issues (to push them to reconsider)

5. Capture reactions to our plans, questions, and open issues from the customers at hand.

Maybe I am missing something.  Respond with any other general topics that you would like to see in a LabVIEW roadmap discussion, or send in specific questions or comments so I can comment and/or include them in my presentation.

Now Taking Suggestions on the LabVIEW Idea Exchange

You may have seen this new feature on our Web site already, but we just rolled out the LabVIEW Idea Exchange where you can suggest ideas for us to implement in LabVIEW and, more importantly, you and your fellow LabVIEW users can vote on the ideas that you think are most worthy.  We’ve tried suggestion boxes in the past, but this more public approach where we not only get new ideas but also get a better notion of the priority based on the collective wisdom of the crowd has a much better chance of driving impact. 

A little background – our LabVIEW R&D managers are also excited about this feature on our Web site as well.  With the breadth and complexity of the LabVIEW platform, we struggle at times making tradeoffs about feature development.  With tools like Idea Exchange, we aren’t necessarily looking for MORE ideas, but we see it as a much better process to prioritize and improve our hit ratio for new feature development.  At certain times in the development cycle, we hope to populate the Idea Exchange with our list of features planned for development in an effort to make some late-in-the-game adjustments as we go.  We will also try to comment on the ideas coming from the community periodically to give our position on them.

So bring on your ideas, but be prepared for your cohorts in the LabVIEW user community to weigh in with their own opinions.