64-bit LabVIEW

Last week, we announced the 64-bit LabVIEW beta. That announcement reveals a little about how I've spent the last couple of years of my life.

A long, long time ago, when I first started at NI, we were pretty proud of the fact that LabVIEW started its life as a 32-bit Macintosh application. We didn't suffer the pains of some applications that were having to live in (and later convert from) the 16-bit DOS and Windows environments.

But in some parts of the source code, we weren't as rigorous with our data types as we should have been. I asked the guy next to me, "Hey, Steve. Should I be worried about all these places we assume pointers fit into 32 bits?"

"No," he responded, "we do that all over the place. Somebody far in the future will have to go through all of LabVIEW and fix that."

I did not know then that the "somebody" would be me.

As I alluded to in my Twenty Years post, when I first started working on this, it seemed like an insurmountable task. LabVIEW source code is big, with a lot of developers having their hands in the code over time. And it's part GUI, part compiler, part runtime engine, and part kitchen sink.

Fortunately, I soon got help—a small, but really good team—and we just started plugging away at it. The little milestones along the way...

• Compile the source code without errors


• Compile, link, and crash on launch


• Launch to Untitled 1


• Launch to the Getting Started window


• etc.

There was a snowball effect—we'd fix something, and then a whole bunch of stuff would start working.

I wouldn't say it's been easy. When we first started, I had a fair amount of skepticism... I had fears that we would hit a brick wall, or we'd discover something that would require more effort than we were willing to invest. That skepticism was justified. We had to make some tradeoffs to keep the project from getting out of hand.

From a software engineering perspective, I think we did a good job of containing the risk to 32-bit LabVIEW while pushing forward with 64-bit LabVIEW. (All the code is shared.) Perhaps more on that later.

I'm pretty happy with our level of quality in this beta release. If you've got access to a 64-bit Windows machine, I encourage you to sign up for the beta and give it a try. Here's a teaser for the kinds of things you'll be able to do. (Click to enlarge the image.)

Read more of this article...

Twenty Years

Last month, I celebrated twenty years at National Instruments.

One of the first things I learned about software development at NI is that food plays a prominent role. Back in the early days, it was mostly Double-Stuf Oreos®.

Hardly a day goes by without someone sending out a food announcement email—bagels, doughnuts, leftover party food. There's almost always a reason for the food: an anniversary, or "Thanks to Kevin for helping me figure out this problem", or "I broke the build".

During one test day, someone wrote a LabVIEW application that sits in the system tray (multi-platform, of course) and pops up to let you know that someone has brought in food. It also showed you the shortest path from your desk to the food. Who says testing isn't fun?

For my fifteen year anniversary, I bought fifteen dozen Krispy Kreme® doughnuts and scattered them around several floors of the building I'm in. It's frighteningly easy to buy 15 dozen doughnuts. They didn't bat an eye. They did offer to help carry them to my car.

For twenty years, I made a couple of desserts, both from the Hotel Limpia (Fort Davis, Texas) cookbook. I made the most decadent chocolate brownies ever—containing about 20 pounds of chocolate and sugar. And in a feeble attempt to provide enough for everybody on the team, I made dozens and dozens of oatmeal raisin cookies.

But enough about food. That's not what keeps me coming back to this place every day.

Let's tie this all back to software engineering.

While software engineering is mostly about the process of developing software, one aspect of it has to cover how you get people to come into the office every day and do the work. Food is nice. Pay is important. But it's the cool projects that keep me coming back.

I'm working on a long-term project that I sooo want to be able to talk about. (Soon, soon.) I've been working on this project for a couple of years, and I still come in to work each day eager to work on it. What seemed like an insurmountable problem when I started is now within reach, thanks to a small and really good team we've put together.

A Sense of Urgency

There's a lot to be proud of as I look back over twenty years, but I come to work every day thinking about what's next. And maybe that's something to be proudest of—I helped build a software development process that is still one I want to be part of after twenty years.

I come to work every day with a sense of urgency. I think all good software teams do. It's not a sense of panic. Okay, maybe it occasionally approaches panic, but mostly it's under control. It's more wanting to relentlessly make progress, every day. A little bit more works every day, and soon we've worked past major obstacles. Celebrate briefly. And we keep going, because we're not done yet.

It's a whole lot like twenty years ago on the LabVIEW team. And that's a very good thing.

And my project is one of many. There are many other small teams here working on exciting things, with their own sense of urgency.

So I think it's pretty cool that after twenty years at the same job, I'm still having fun. We haven't run out of things to do. We haven't run out of ideas. We aren't "done" yet.

Read more of this article...

Linux and LXI Instrument Control

A long time ago, I learned a lot about UNIX — first, as a programmer at a well-run BSD shop, and later after joining NI, by becoming NI's system administrator for our lone Sun 3/160 workstation. (That was in addition to my real job of being a LabVIEW programmer.)

I've also been heavily involved in the UNIX/Linux flavors of LabVIEW... initially LabVIEW for Sun, and later, LabVIEW for HP-UX, LabVIEW for Concurrent PowerMAX, and LabVIEW for Linux.

So with great interest, I've noticed several new Application Notes from Agilent about Linux, the most recent of which is Using Linux to Control LXI Instruments Through TCP.

While these app notes provide some useful information, they typically show you how to do things the hard way. With NI software, things are much easier...

For example, in the above-mentioned application note, you get to learn about socket calls, network byte ordering, and Nagle's algorithm for packet consolidation. In another application note, Using Linux to Control LXI Instruments Through VXI-11, you get to learn how to program remote procedure calls and the XDR format for data representation.

---

NI and Linux

One of the benefits of National Instruments' software is that we actually have Linux versions of LabVIEW, the LabWindows/CVI Run-Time Module, our I/O Libraries such as NI-VISA and NI-488.2, and some of our other device drivers such as NI-DAQmx.

So instead of having to learn how to write your own I/O libraries, and how to use the GNU Compiler Collection and debugging tools, you can work at a much higher level in a graphical system design language.

---

Instrument Drivers

LabVIEW is a portable language, which means that the functions (VIs) that you write can be moved from one flavor of LabVIEW (e.g., LabVIEW for Windows) to another (e.g., LabVIEW for Linux, or Macintosh, or Real-Time) and function correctly. There are a few caveats to this... Not all real-time targets have hard disks, so the File I/O functions don't work there. Another example: VIs that use OS-dependent technology, such as IVI-COM drivers that depend on Microsoft's ActiveX technology, are not portable.

So what to do about instrument drivers? Agilent, in their application note Using Linux in Your Test Systems: Linux Basics suggests "in most situations you do not need an instrument driver." While true, it sidesteps the issue that instrument drivers are really valuable, since someone else has developed and debugged the code that deals with the nuances of specific instrument models.

Fortunately, the National Instruments Instrument Driver Network contains thousands of LabVIEW Plug and Play instrument drivers. These instrument drivers will work on Windows, Linux, MacOS X, and LabVIEW Real-time — anywhere you have both LabVIEW and VISA.

What about IVI? All IVI drivers are Windows only, but there's a way to get IVI-C drivers working on Linux. They're no longer officially "IVI", but it can be done. NI has an article entitled Porting IVI-C Specific Drivers and Applications to Linux that describes the steps.

---

So to summarize, if you like doing things the hard way, the Agilent application notes lay out a nice roadmap. The rest of you might want to consider NI's Linux products. To learn more, see ni.com/linux.

Read more of this article...

LabVIEW in Public Places

I've been traveling quite a bit lately. That's my excuse for falling behind on the blog.

Having spent nearly twenty years of my life at National Instruments, I've gotten pretty good at detecting the presence of LabVIEW in the world around me. For example, during the Tour de France coverage on TV, there was a short segment on the San Diego Air & Space Technology Low Speed Wind Tunnel. There was maybe one second of video showing software, and I call out, "That's LabVIEW." Those buttons on the front panel are pretty recognizable.

I recently visited (as a tourist) the Oregon Museum of Science and Industry, and found LabVIEW in the Vernier Technology Lab. It's used to show how electrical activity in the heart is measured.

I also recently visited—again as a tourist, this time with colleagues from Agilent—the Deutsches Museum in Munich. We went to the museum late in the afternoon one day, with only an hour before closing. This is a big museum, so we were racing through trying to see as much as we could. We ran across the TUMLab, an engineering education lab in the museum, associated with the Technische Universität München.

The lab was closed, but through the glass window, I could see a Lego robot. This meant that LabVIEW was probably nearby. I don't think my colleagues from Agilent were quite as excited by this discovery as I was.

---

I never get tired of seeing LabVIEW in the "real world". I'm proud to be part of the team that's made it possible. And I'm especially proud we're helping educate the next generation of scientists and engineers.

Read more of this article...

NIWeek recap

Michael Aivoliotis just published his video interview of me. That's prodded me into posting a quick NIWeek recap. Thanks, Michael!

I got the attendance numbers for my sessions. A total of nearly 300 people attended my presentations. Wow! Thanks to everybody who came, and I hope the sessions were useful.

"Software Engineering—The NI Way" was very popular; we filled a large room. I'm pleased that we had such great audience participation during this presentation.

The LXI presentation had the least amount of interest, but I think we had a good selection of attendees there. I showed unreleased products from both NI and Rohde & Schwarz. A big thank you to David Owen from Pickering Test, and Johannes Ganzert from Rohde & Schwarz, for loaning equipment for my demo. Afterwards, one attendee said that my presentation was "better than the one Agilent gives". I haven't seen Agilent's LXI presentation, but that sounds like a good compliment.

Another highlight for me is that one of the stars of NIWeek came to my Instrument Control Bus Comparison presentation. If you didn't attend the Thursday NIWeek keynote, you should visit the NIWeek Keynote Videos web page. Click on the Thursday tab, and watch the 8-minute video entitled, "Future Scientists and Engineers - An Interview with Samuel Majors". I think you'll be inspired.

I was honored to meet Samuel, but I was even more pleased that I was able to connect him with Jim Kring, the co-author of one of Samuel's favorite books, LabVIEW for Everyone.

I also had a great time at the LAVA Barbecue at the Salt Lick. Somebody needs to tell Chris Relf that I already paid. ;-) My car (and Nancy Hollenback and I) made a cameo appearance near the end of another Michael A. video. We had a great time.

Read more of this article...

My NIWeek 2007 Sessions

I hope you are attending NIWeek, and that you are planning to attend at least one of my NIWeek presentations...

• Software Engineering - The NI Way


• Using LabVIEW in an LXI-Based Test System


• Head-to-Head High-Speed Bus Comparison: GPIB, PCI, PCI Express, USB, and Ethernet/LAN

Read more below for details on each presentation...

Software Engineering - The NI Way

Wednesday, 3:30 PM, Room 12A

Join me for an interactive discussion about how NI develops software. When I first joined NI nearly 20 years ago, our software development process was, shall I say, "underdeveloped". Fortunately, we've been improving ever since.

I'll talk about how our process has evolved as our team and code have gotten bigger. I'll talk about and demo some of the tools we use.

This topic is significantly more interesting with audience participation, so bring your own thoughts and stories about how you develop software.

Using LabVIEW in an LXI-Based Test System

Wednesday, 4:45 PM, Room 17A

LXI is a relatively new standard for LAN-based test and measurement instrumentation. As many of you know, I represent NI at LXI Consortium meetings. You may have read my earlier blog postings about What is LXI? and LAN is Simple, Right?

In this presentation, I'll show how you can use NI hardware and software to control an LXI-based system. I've put together a system containing LXI devices from Rohde & Schwarz, Pickering Interfaces, and Agilent. (Thanks to the vendors who loaned me their equipment!)

This NIWeek presentation is heavy on demos and light on slides. I'll show you everything from simple instrument communciations to advanced synchronization and timing.

Head-to-Head High-Speed Bus Comparison: GPIB, PCI, PCI Express, USB, and Ethernet/LAN

Wednesday, 10:30 AM, Room 17B

Thursday, 2:15 PM, Room 13B

The typical test system these days includes instrumentation with a variety of interfaces. You might have a mix of simple PXI devices, legacy GPIB instruments, and perhaps a LAN or USB device thrown in. This presentation will shed some light on the strengths and weaknesses of various buses, including performance, cost, and ease of use.

Read more of this article...

Pop Quiz Answer

Nobody answered my pop quiz!

Pop Quiz: Default data on a front panel control is useful, for example, when the control is on the connector pane, but isn't wired in the caller's diagram. The subVI runs with the default value in that case. When is default data on an indicator useful?

Read more for the answer...

We pass data out of subVIs through its indicators that are on the connector pane. But what if an indicator doesn't receive any data while the subVI runs? In that case, we use the indicator's default data and pass that out to the caller.

A picture helps. Here are the two frames of a case structure...

This is an example of a conditional indicator. The indicator is only updated in one frame. If the VI never executes that frame, no data ever reaches the terminal for the indicator. When the indicator's data is passed out of the connector pane, the default data for the indicator is used in that case.

So in the example above, I made the default data for "My Conditional Indicator" the value 456. I put the "Case?" Boolean and the "My Conditional Indicator" on the connector pane and saved the VI. In the calling VI, if I pass True, I get the result "123". If I pass False, I get "456". Make sense?

Why did I bring this up in a posting about performance? Because it affects memory usage. LabVIEW has to account for two different ways that a conditional indicator can be updated (through a wire or by copying the default data). This interferes with the in-place algorithm and means that LabVIEW can't be as efficient with memory usage.

Conditional indicators aren't typically needed. I could have achieved the same effect with the following diagram...

(Or, for simple things like this, I could have used the Select function.

So, you might want to look at your own code for places you are using conditional indicators to see if you can improve your memory usage. I wouldn't worry much about scalars and other small data, but if you have large arrays or strings, this can make a difference.

Read more of this article...

NIWeek 2007

NIWeek 2007 is fast approaching on August 7-9. If you use NI products (or are thinking of using them), this is an awesome event. Dozens of technical sessions, amazing keynotes, and scores of exhibitors. In addition, we have special summits for Graphical System Design, RF and Wireless Communications, Sound and Vibration, and Vision applications. Register now at niweek.com.

Staying informed during NIWeek

• Whether or not you are attending NIWeek, watch the NIWeek Blog by Michael Aivaliotis. Videos and stories throughout NIWeek.


• The official NIWeek Twitter link can keep you informed of late-breaking NIWeek news. Or maybe you can just twitter each other during my presentation about how great it is. ;-)
  

Speaking of my presentations, I have three this year...

• Software Engineering - The NI Way


• Using LabVIEW in an LXI-Based Test System


• Head-to-Head High-Speed Bus Comparison: GPIB, PCI, PCI Express, USB, and Ethernet/LAN

I'll post more information on these as we get closer.

Read more of this article...

Yet another kind of data

Note... I'll be in Vancouver, B.C., for next week's LabVIEW Developer Education Days on June 26. I hope to see some of you there.

As I mentioned last time, there's a fourth kind of data that can show up in the profile window...Default Data.

I'll go back to the simple VI I used in the last posting. It's an array of int8's wired to an array of int8's. The default value of each array is empty. This means that when I load the VI into memory, the front panel doesn't have the arrays allocated. (And the VI only takes up about 8 kilobytes of disk space.) For my earlier profiling tests, I was typing a new value into the millionth element of the array control, which allocates the million bytes for it. When I ran this VI, it consumed five megabytes of data.

Now let's see what happens when I go ahead and "Make Current Value Default" for the million-byte array...

When I run the VI (and I've run it more than once, so you can see the final values in the profile window), you see that the five megabytes has turned into six megabytes. The profile window is now showing you that there's an extra megabyte of memory being consumed by this VI, because of the default data.

To take it a step further, if I also made the indicator array's data the default, I'd be growing the memory consumption to seven megabytes.

Default data is often a good thing, but we sometimes find VIs where we've saved a large amount of data as default accidentally. This is easy to do if you select the "Make All Current Values Default" menu item from the Edit menu. I try to stay away from this menu item, and instead only set the default value for the controls I know that need it.

Pop Quiz: Default data on a front panel control is useful, for example, when the control is on the connector pane, but isn't wired in the caller's diagram. The subVI runs with the default value in that case. When is default data on an indicator useful?

Note that the VI Analyzer reports non-empty default values for arrays so that you can take a closer look at them. (The VI Analyzer is a separate add-on for LabVIEW that can check your VIs for common programming errors, style conformance, and in this case, performance issues.)

Interesting side note... When I save my new test VI to disk, how much disk space do you think it consumes? Seven megabytes? Two megabytes?

It turns out that it takes up about 8 kilobytes, which is about what it took when I hadn't saved any default data. Why is that? It's because my default data was entirely made up of zeros. The VI's data gets compressed when it's saved, and a million zeros compresses very well.

Just for fun, I created an identical VI with a million bytes of random data saved as default data for each front panel array. That VI took about 1.2 megabytes on disk—still, that's a 40% savings over the uncompressed data, which is pretty good, I think. (Your mileage may vary.)

Read more of this article...

LabVIEW Performance and Memory Management

When I talk about performance optimization in LabVIEW, I pretty quickly focus on memory management issues. Memory isn't the only concern. It's just that memory issues are sometimes the hardest to understand. Plus, since LabVIEW is a dataflow language, we have a lot of emphasis on the data.

One way to monitor memory usage in LabVIEW is to use the profiler.

Select Profile Memory Usage to see how much memory each of your VIs is consuming.

Here's a simple VI I wrote that contains an array control wired to an array indicator. I changed the data type of the array element to be a 1-byte integer. This makes it easy to see how much memory the array is taking--one million array elements equals one million bytes. (If we had an array of doubles, one million array elements equals eight million bytes.)

I've initialized the control to have one million elements. (Actually, 1,000,001, but who's counting. ;-) Before I run the VI, it is using 1 million bytes for its data--the indicator is an empty array. The profiler won't show you this; it doesn't do its thing until you run the VI.

Okay, once I run the VI, how much memory do you think it takes? Let's see what the profiler says...

Approximately 4 million bytes! What's going on?

In my last blog entry, I said I'd tell you about the three kinds of data in LabVIEW, and they're all showing up in this profile result. The three types of data are...

• Operate Data—Every front panel control and indicator keeps data that we call the "operate data".


• Execute Data—Every wire on the diagram represents a buffer of data. The data for the diagram is called "execute data" or "execution data".


• Transfer Data—Buffer used to isolate execution threads (which work with execution data) from the user interface thread (which works with operate data).

So why do we need these three kinds of data? As we'll see in later postings, the diagram likes to share execution data buffers among parts of the diagram, so the data that originally came from a control can get overwritten with intermediate and final results as the VI executes. You don't want front panel control's data to be changing while the VI runs, though! This means that we have to have a separation between the diagram and the panel.

The transfer buffer is used as an optimization in LabVIEW's multithreaded execution system. When the diagram wants to send data to an indicator, it has to work with LabVIEW's user interface thread to draw the data. There can be many execution threads, but there's only one user interface (UI) thread. Thus, the UI thread can potentially be a big bottleneck if all those execution threads had to sit and wait for it. That's where the transfer buffer comes in. It's a buffer that both the UI thread and execution threads can quickly access without (usually) blocking.

So when a block diagram updates an indicator, the execution data is copied to the transfer buffer by an execution thread, and some time later, the UI thread reads the transfer buffer and copies the data to the operate data.

So back to our example. We have a million bytes in the control (operate data), a million bytes in the control's transfer buffer, a million bytes on the wire (execute data), a million bytes in the indicator's transfer buffer, and a million bytes in the indicator (operate data). That adds up to five million bytes, right?

But the profile window said four million. What's the deal? Recall that I said that the profiler does its thing while the VI is running. It turns out that in this simple diagram, the VI stops running before the UI thread has had a chance to make the last copy of the data (from the transfer buffer to the indicator's operate data).

When profiling, I tell people to run their VIs a few times to make sure that buffers are allocated. If I run the VI again, I'll now see five million bytes...

If this were a more realistically complicated VI, there's a good chance that the profiler would have counted all the data the first time.

Next up... I lied. There's a fourth kind of data that can show up in the profile window. What is it?

Read more of this article...