Giving Back To Our Communities

On Friday night, I went to the opening night performance of a local non-profit choral group, Conspirare. They are an amazing, world-class group, and they put on a wonderful show that will soon be recorded by PBS. I even recognized in the audience Dr. Anton Armstrong, conductor of the renowned St. Olaf Choir.

Sitting in the audience, watching and listening to Conspirare, I could not help but think that this is an organization worth supporting. How fortunate we are to have them in Austin.

---

Today marks the beginning of our three-week employee fall giving campaign, of which I am the chair.

A few weeks ago, I received a mysterious meeting invitation in my inbox... "Quick chat with community relations". I had been warned that I was on the list of candidates to chair this year's campaign, so I knew what the meeting was going to be about. This gave me time to think about it.

At first, it was a "why me?" kind of experience. What was I signing up for? It's overwhelming and intimidating—we've got thousands of employees in the US, and I would be the voice of the campaign.

We've got a pretty good track record of employee giving. High standards, yet the economy is tough this year.

Sigh. I'm not sure I'm the guy for the job. It would be so easy to say no; to push this off on someone else.

But I don't. I won't.

I care about the community in which I live. I care about NI, and feel privileged to work here. I care about the arts. I care about education. I care about animals and the environment. I care about social needs, health needs, literacy needs.

With the consummate support of the National Instruments Community Relations team, especially Yvette Ruiz and Amanda Webster, here I am.

---

We hire a lot of our employees right out of school. This is great; keeps us young. It also means that some of our employees may not yet feel strong connections to their communities. And this is one of my challenges.

I asked for a field trip. I asked our community relations people if we could organize a field trip for our campaign volunteers.

I wanted our volunteers to see a need firsthand. We have dozens of volunteers, without whom we couldn't run this giving campaign. They go to every group meeting and explain the reasons for the campaign, the goals, and the mechanics.

I wanted our volunteers to see where the money goes, and what it buys, and to be able to talk about it to our employees.

We went to SafePlace, which fights domestic violence and sexual abuse.

A few days later, a different group of NI employees went to Dell Children's Medical Center of Central Texas.

And in the past few weeks, I've been to events for Communities in Schools, and the Austin Lyric Opera.

We've got thousands of non-profits in central Texas, thousands more nationwide, and our employees can choose to whom they donate. I want all of our employees to know that they can make a difference in their communities.

---

Another theme I want to stress is that any amount helps.

I am truly proud that NI has the largest number of employees who are able to donate $1000 or more to be a part of the United Way Capitol Area Young Leaders Society.

But many of our employees aren't in a position to donate that much. I want them to know that they can still make a difference, even with a small donation.

Among other things going on in my life right now, I'm raising money for cancer research and survivorship through the Lance Armstrong Foundation. I'll be doing the Livestrong Challenge bike ride at the end of October. (Plug: Support my ride here... austin08.livestrong.org/bhpowell.) One of my friends came up to me the other day and handed me a dollar bill in support of my ride. It's all he had to give. He promised another dollar in a week. That meant so much to me, as it also reminded me of a parable that I am sure many of you know.

---

My challenge to all of you readers, wherever you are, whoever you are, is to go out and make a difference in your community. Find your passion. Give your time. Give your money. Find someone who needs your support, and support them.

Read more of this article...

AutoTestCon 2008

As I mentioned in an earlier post, I was at AutoTestCon in Salt Lake City a few weeks ago. This was my first visit to this MIL/AERO conference and tradeshow.

I was greeted to the Salt Palace Convention Center by banners with images of fighter jets and bombers over Monument Valley and Delicate Arch.

I was there to give a presentation on IVI, be part of a panel discussion on LXI, and to support a demo for the LXI Consortium...

Here's a photo of the demo I built for the consortium, using a Rohde & Schwarz FSL Spectrum Analyzer, a Keithley 2910 RF Signal Generator, two Agilent E5818A Trigger Boxes, an NI 8353 quad-core 1U PXI Controller, and NI LabVIEW 8.6.



The other demo in the booth consisted of Matlab and image processing software from The Mathworks, Agilent E5818A Trigger Boxes, and 1394 cameras from Point Grey Research. Colloquially called "the bouncing ball demo", it used a military grade Playskool Busy Basics Busy Popper for projectile measurements.



Okay, the part about "military grade" was a joke. The demo was there to make noise and entice people into the booth. Shown in the photo are Conrad Proft, from Agilent, and Rob Purser, from The Mathworks.

Both demos showed LXI features such as IEEE 1588 timing and distributing triggers across a network.

---

On Monday, I gave a presentation about IVI instrument driver technology at one of the seminars. This was just a basic introduction into what IVI drivers are, and an update on the status of current work in the IVI Foundation.

The tone was set for this presentation a few seconds into my talk. One attendee raised his hand and said, "IVI drivers don't work."

"I see it's going to be a tough crowd", I replied.

In this particular case, the user had obtained several IVI-COM drivers from his instrument vendor, and all but one failed to communicate correctly with his instruments. He had also received an IVI-C driver for an instrument from a different vendor, and he was unable to make it work until he got National Instruments involved to fix it for him.

This is a good point for me to point out that you don't have to depend on your instrument vendor for your instrument drivers. The National Instruments Instrument Driver Network (IDNet) contains instrument drivers for thousands of instruments from hundreds of different vendors, including IVI drivers, LabVIEW Plug and Play drivers, and VXIplug&play drivers.

Many of the drivers on IDNet are marked as "NI Certified", which means...

Certified instrument drivers comply with instrument driver standards including programming style, error handling, documentation, and functional testing. Certified drivers ensure consistency among instrument drivers and, therefore, improve ease of use. They also provide source code so that you can modify, customize, optimize, debug, and add functionality to the instrument driver. All National Instruments certified instrument drivers receive NI support.

---

I was also on a panel discussion about LXI. We presented to about fifteen people.

A week later, we recorded a webcast for T&M World Magazine with the same material. You can view a replay of the webcast by registering on the T&M World website.

We had time for questions and answers during both versions of the presentation. Additional questions from the webcast will eventually be posted with answers on the LXI website.

Interestingly, most of the questions at AutoTestCon related to GPIB. Conrad Proft, from Agilent, had slides that showed examples where LXI works better than GPIB (over long distances) and RS-485 (cabling).

One question was whether companies are going to continue to support GPIB. Conrad from Agilent voiced his company's continued commitment to GPIB. I added that I believe that many people are still building GPIB-based test systems, and that NI will continue to support our GPIB users. (Later that week, NI announced our new PCI Express GPIB controllers that support a nearly 8 megabyte/second transfer rate, are RoHS compliant, and use only 1.1W of power.)

Another audience member, perhaps a little caught up in the excitement of LAN-based instrumentation, asked, "Why would anyone still use GPIB? It's slow. The cables are so inflexible."

My jaw dropped at this. I bet if you polled all the AutoTestCon attendees, just about every one of them is using GPIB, and is going to continue to use GPIB. So my answer began with, "Because it just works!".

"The GPIB cables are shielded and have rugged connectors that screw in and don't have plastic tabs that break off."

[Bringing it back to LXI] "...the message of the LXI Consortium is that it's important to ensure that LXI works well with other buses."

The reality is that our users are going to develop "hybrid" systems, using a mix of bus technologies. Every bus has pros and cons. GPIB has low communications latency and is rugged. LXI has cheaper cabling and works well over extraordinarily long distances. PXI and PXI Express have high communications bandwidth and low latency.

And that's why it's my job at National Instruments to help ensure that all forms of I/O work well in LabVIEW.

Read more of this article...

AutoTestCon 2008 in Salt Lake City

I'll be in Salt Lake City next week, September 8-10, for AutoTestCon.

AutoTestCon is a large Mil/Aero conference and trade show sponsored by the IEEE.

I'll be doing a couple of presentations...

On Monday, I'm presenting as part of a seminar entitled, "VXI, PXI, IVI & LXI Standards Improve ATE Systems Design". I will be presenting the part about IVI. I'll cover what IVI is, the current state of IVI, future work, as well as technical informationi on configuration, the differences between IVI-C and IVI-COM, and how to use class and specific drivers together.

On Wednesday, I will be part of a panel discussion on "Test Applications Using LXI Instruments". Hosted by Test & Measurement World chief editor Rick Nelson, the panel plans to share some of what we've learned over the past three years creating multi-vendor LXI-based test systems.

Read more of this article...

NIWeek 2008

It's Monday of NIWeek 2008, so it's a tradition for the Austin American-Statesman (the local newspaper) to have a nice article about NI. Today's was about Green Engineering.

Today is Alliance Day, and the full-blown conference starts tomorrow.

I'll be presenting again this year, on Thursday...

My topic is about using NI hardware and software products to work with LXI-based test systems.

I'll be around the convention center all week, including the LAVA dinner Tuesday night, and the conference party on Wednesday. Feel free to find me and say hi.

Read more of this article...

Thoughts on Network Protocols for Instrumentation

Among my other responsibilities, I still hang out with the LXI crowd. Lots of conference calls, and a quarterly face-to-face meeting. (Thank you, TestForce, for hosting our recent meeting in Toronto.)

Following up on my earlier blog post, National Instruments did join the LXI Consortium at some point (last year, I think). I believe that having one network-instrumentation standard to follow is better than having many, and the technical side of the consortium is constantly working to devise solutions to limitations inherent in a network-based test system.

There are a variety of challenges revolving around the fact that LAN opens up the door to having more than one "controller" in a test system.

In a test system using RS-232 or USB, for example, any single device talks to only a single "controller"—typically the test system's PC. A GPIB system is a form of network, but there's always one "controller in charge". Nobody can easily intrude into the test system.

Is this a "feature", or a "limitation"? It all depends on the test system. What if you wanted to see test data from the outside world? Today, you'd probably put a network connection on your test PC, and let it serve up data through the LabVIEW Web Server, or store data into a corporate database. Nobody could talk to the instruments directly; they would always go through the PC.

But an alternative that LXI allows is to connect your private test network to the rest of your company's intranet (or the entire internet, if you want). This allows others to interact directly with the measurement instruments. You probably wouldn't want this feature in all test systems, but it opens the door to some interesting possibilities.

Even if you don't connect your test network to the internet, you might still want to have more than one test PC talking to the devices. Or one grand vision of the consortium is that instruments can control other instruments. How does an instrument manage multiple connections from multiple controllers at once? Does this sound complicated? It is.

And this is where the LXI Consortium comes in. What can the consortium do to make it "safe" to have more than one controller on your network?

There are many aspects of this that the consortium is working on—defining behavior when there are too many connections for an instrument to handle, for example. One particularly challenging problem is how to "reserve" or "lock" an instrument in your test program so that nobody else comes in and changes settings in the middle of your test.

It's worse than that, really. Just discovering instruments on your network can have the accidental side effect of interrupting a test program. And it's especially this kind of inadvertent access to a test instrument that the consortium is trying to resolve.

One step in this direction was announced in the LXI 1.2 standard. There will be a new mechanism for discovering LXI devices that is less obtrusive than the current approach. In the future, when instruments are available that support the next version of the LXI standard, this very common form of inadvertant access should be solved for future test systems.

But there are still challenges with test systems with more than one computer or instrument trying to talk to a single device at the same time. For that, we really need to be able to reserve the instrument for exclusive use by a single test program (or perhaps even a single part of a larger test program).

This problem has been solved before in this domain. In 2004, I helped write an article for T&M World entitled Migrating to Ethernet. I discussed the VXI-11 protocol for communicating with instrumentation over Ethernet.

Because VXI-11 defines processing on both the host (PC) and client (instrument), it is able to provide a way to reserve or lock the instrument in a test program. With VXI-11 devices, the VISA commands viLock and viUnlock can be used to lock the instrument so that it only responds to the program that has the lock.

However, VXI-11 has kind of fallen out of favor with instrument vendors. One reason is that it requires a fair amount of processing horsepower inside the instrument. VXI-11 is based on a technology called RPC, or Remote Procedure Calls. With RPC, much of the processing happens on the instrument, requiring more processing power, more memory, and thus, higher overall cost.

Instrument vendors want to move to simpler protocols. The consortium therefore needs to take a fresh look at instrument locking, and hopefully come up with a proposed solution in the 2009 or 2010 versions of the LXI standard.

Until then, fortunately, most LXI instruments continue to support VXI-11 and you can use viLock or viUnlock (in LabVIEW, they are called "VISA Lock Async" and "VISA Unlock") to lock instruments in your test system.

One caveat is that IVI drivers do not support the same kind of locking. You need to have access to the VISA session to properly lock the device. This is one of the benefits of using a LabVIEW Plug and Play (or for C users, VXIpnp) driver. Since these kinds of drivers use the VISA session directly, you can easily add VISA Lock and VISA Unlock calls to your program without major rework.

Stay tuned as the standards evolve.

Read more of this article...

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...