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.

Building Amazing User Interfaces with LabVIEW

Back in the good old days (a phrase some of our younger product managers are tired of hearing me say), our sales guys had it easy.  Simply open a blank VI, drop down a knob or toggle switch, make it move, and wait for the oohs and aahs (and orders).  The user interface – how you develop it and how it interacts with your programs – is and will continue to be a key differentiator for LabVIEW.  In recent years, as iPhone apps and other hot new devices have become the talk of the tech world, people have begun to expect that UIs should look sexy, with glossy controls and color schemes. We’ve heard the low, rumbling feedback about  how LabVIEW UI elements could use an update, and believe me, we’re working it. In the interim a few employees and LabVIEW users have formed the UI Interest Group   to share best practices and templates for building modern, eye-catching controls for LabVIEW.  There is actually a lot you can do to create your own custom controls that look very modern, unique, or conform to some specific design themes.  Check out some of their work: 

Creating your own custom controls is fairly simple. Each control is made up of several elements that you can replace with your own images. For example, a LabVIEW gauge is made up of the following objects:

To create your custom control you just replace each object with your custom design:

Now it does take a good eye for design and a decent image editing tool to make these, and I don’t have either. If you’re in my boat, join the UI Interest Group to download the controls they’ve built and learn more about making your own.

LabVIEW Testing Part 2 – Reliability Lab

In our second video interview installment about how we test LabVIEW and our driver software, Byron Radle takes us through our internal Reliability Lab.  When you watch it, the background noise is coming from 20 fully-loaded PXI chassis and 40 fully-loaded CompactRIO systems all running at once in our lab – raw (loud) power!  You can tell from the freeze frame below that Byron is excited about this lab. 

 

Once again, if you can think of specific scenarios that we need to add to our testing matrix, please respond.

Resolution #1: Get More Involved in the LabVIEW User Community

For years, NI’s LabVIEW leadership (Marketing and R&D – yes, that would be me and my compadres) have taken a fairly hands-off approach when it comes to commenting in the LabVIEW community – in particular, forums on external sites like LAVA or INFO-LV. I am not talking about the typical technical questions, but more about the posts that are controversial – like when people start questioning our intentions or believe that we have made an outright wrong decision on some policy or other. In the past, our approach has been to sit back and rely on our very active and supportive user base to jump to our defense rather than ourselves because it might come across as NI “tampering” or being “heavy handed.” In reality, that is an “old school” approach that we need to change. I believe that today, we need to be more open to jumping in and sharing our perspective on these discussions where we can (sometimes we can’t comment on revenue or strategy issues that are not public yet). Many users often wonder aloud in these discussions if we (NI management) are listening. We are – many people monitor INFO-LV and Lava forums here at NI. When flames spark, we sometimes fail to act. I don’t expect to change anyone’s mind, but just the fact that we are listening and sharing our perspective is a good start. I hope to use this blog to share these perspectives – whether in reaction to a particularly spirited discussion we see on the forums or in discussions with customers, or as a premptive strike on topics where we are looking for feedback.

I shouldn’t be too critical. About four years ago, we made some pretty significant changes to our End User License Agreement to accommodate home use and use on multiple computers that was spurred on by an INFO-LV discussion. So we try to do what’s right most of the time – we just don’t always close the loop with those of you who are chirping on the forums.

The truth is, for most of our customers, it’s not about the big policy decisions or strategy and positioning that is interesting – its mainly about the technology and how you can get the most out of it. This is another, more relevant example of where we are planning to get more involved. We have recently developed our own “blog college” training session to get some of our R&D engineers prepped and ready to enter the blogosphere. You will see new blogs in 2009 authored by some of our engineers in areas like developing large applications in LabVIEW, Embedded Control with LabVIEW, Advanced math, signal processing, and simulation with LabVIEW, and general LabVIEW development techniques. We want to show you techniques to maximize your investment in LabVIEW and expose you to some of the newer areas you can use LabVIEW, directly from the desks of our experts.

Stay tuned.

 

2009 LabVIEW New Year’s Resolutions

(Confessions of an NI LabVIEW Guy)

I, like many of you, are taking some time at the end of the year to reflect on the successes of 2008 as well as the gaps that still exist.  In thinking about next year’s goals, I thought it might be fun to share some of these with the LabVIEW community at large to get your feedback or commentary about.  Most of these address areas where I believe we have some shortcomings today, hence my “confessions” sub-title.  

For now, I will simply list my resolutions.  I will use a series of subsequent posts to explain in more detail each of these and what I hope to accomplish in 2009.

1. Get NI more active in the user community
2. Provide better support for third-party tools
3. Be more transparent with our roadmaps
4. Clearly document our “support” and product lifecycle policies
5. Get serious about addressing upgrading and deployment pain
6. (an extra bonus) Develop new, more effective ways to capture user input and feature requests (and act on it!)

I will follow up with more details about what each of these means in the near future.  For now, have a great holiday season.

LabVIEW and Giant Telescopes

For those of you who think the whole “LabVIEW is great for multicore programming” story is a bunch of hype, you need to check this out…

But first, a short digression.  One of the coolest (and more frustrating) things about working on LabVIEW is the fact that it can be used to solve so many different applications.  Big or small, test, design, or control – LabVIEW again and again comes up in the most incredible places.  When you find yourself talking with an NI person about LabVIEW, you quickly get the feeling that LabVIEW is “all things for all people” – which of course breaks every rule of marketing and product positioning.  But the reality is, you can use LabVIEW for a lot more applications than you think.  Our long legacy of test, measurement, and data acquisition sometimes gets in the way of people realizing that LabVIEW is a potential solution for other app areas.

One such area is advanced, high-speed control.  LabVIEW is uniquely positioned to combine advanced algorithms with best-in-the-world I/O capabilities.  Combine these algorithms with the parallel/multicore capabilities of the LabVIEW programming language – and you’ve got some real power.  

But rather than read about it, take a look at this YouTube video from Darren Schmidt – one of our math and analysis algorithm experts.   Darren has been toying around with running LabVIEW algorithms on an Nvidia Cuda GPU (stay tuned for some libraries coming soon on NI Labs), and in the process has gotten himself and team plugged into a large telescope application.   This video was shot at the Super Computing Conference, where LabVIEW was a finalist for the Supercomputing Analytics Challenge.