The Savvy Test Engineer

Congrats to Henry Huang

2011-05-16T08:33:00.000-04:00

Back in February I wrote about my new Ford Escape and the massive amounts of testing that must go into verifying features like the hybrid electronics or the SYNC software. Well, Test & Measurement World just named Henry Huang their Test Engineer of the Year. It just so happens that he is the "specialist and supervisor for the SYNC platform QA group" at Ford.

I must be psychic...

Labview versioning hell

2011-05-14T06:45:00.001-04:00

I've been traveling a lot for work the past year or so. A few weeks ago one of the people I work with on the west coast complained about the different versions of LabVIEW (LV) and how they don't communicate well with each other. I brushed it off at the time, but like Chekhov's Gun, this came back to haunt me...

======================

About a year and a half ago I wrote a camera program that takes a picture and does some processing of that data. This program runs on a station with LV2009 and NI Vision (v8.5) installed. A couple of weeks ago someone asked to make an executable of this program and install it on another computer. So I compiled the program and then tried to create an installation.

This is where I got stuck in LabVIEW version hell. I could not create the install because (as the NI support people told me) the version of Vision had to match the LV version. My choice was to either a) buy a new copy of a program I already had (Vision), or b) install LV 8.5 and compile with that. So I downloaded LV v8.5, installed that on that computer, then I used LV2009 to downconvert the software to v8.5.

But of course it wasn't that simple. When I tried to compile the install, I got a "data space type map" error and LV crashed. After some digging on the NI Forums I found out that this is a known issue with that version of LabVIEW. The solution was to downconvert to v8.2, and THEN open it in v8.5. BUT, I couldn't do it in my version of LV2009. I had to either upgrade to a later release of LV2009 or do it in LV2010. So I installed LV2010, opened the code in LV2010, downconverted it to LV v8.2, and then opened the v8.2 code with LV v8.5. Finally I created the install.

======================

This series of events illustrates a simple question that I doubt has a simple answer. Why can't LabVIEW work like a text-based programming language where you can open it regardless of what programming environment you use? At it's root, code written in C++ or Java is just text, and you can open it in any compiler. You can't necessarily do that with different versions of LV code. I often see requests for reverse compiling in the NI LabVIEW Forums (""), so I know this is a common problem. Maybe it's because LabVIEW is not a public language but rather owned by NI? Is it the nature of a graphical language? Is there some other reason? I don't know, but it's really annoying.

TestStand, (part 1 - Introduction)

2011-04-22T23:00:00.000-04:00

As part of a project I'm heavily invested in right now, I started learning NI TestStand last fall. My next few posts will be about that experience and my impressions of TestStand.

Introduction

My previous experience with TestStand dates back to early 2008. My company was in discussions with Averna about their Proligent software, which is written to work hand in hand with TestStand. So I talked with the sales guys, read the white papers, and tried out the demo. My impression of Proligent (and TestStand) was that they were designed for large companies with large automation needs. We were a startup, so I respectfully declined.

Two years and one company later, I reconsidered TestStand. I had a big program starting up and had no desire to create a test executive from scratch, especially not one with the complicated requirements I needed. After some research and discussions with the other members of the group, I bought it and learned how to use it.

Over the next few posts I'll talk about a) how I learned TestStand, b) my experiences with it over the past few months, and c) how suited I think it is to small companies (like mine). I'm also thinking about getting the Certified TestStand Developer certification to go along with my CLD for LabVIEW. If I ever do, I'll surely blog about that as well.

Test engineer tropes

2011-04-18T13:27:00.002-04:00

A comment someone made a couple weeks ago started me thinking about common rules of thumb that engineers follow. Here's a few that I've seen in practice.

Murphy's Law
If something can go wrong, it will. When I was in high school I thought this was clever and sarcastic way of expressing a dim view of the universe. It wasn't until I was an engineer that I began to appreciate the statement as an elegant way of describing statistical inevitability: if there is a finite chance that something will happen, given long enough time it WILL happen.

Nyquist Sampling
Engineers commonly double the amount of data they take in the name of Nyquist sampling. It may not be necessary, but that's the way it works.

Once is an anomaly, twice is a coincidence, three is a pattern
This is something that I've said for many years, just as a general rule for test engineering. When I did a search for it, the most common mentions of this are either from the novel Goldfinger or The Moscow Rules (which quotes Ian Fleming). But I think it is most applicable when you're debugging something.

Rinse it six times to clean it
There are well over a thousand references to this on Google. Rinse something out with water six times to clean it. It's a simple rule of thumb.

Double the safety factor
My first job after grad school was at an aerospace engineering firm. There were a lot of mechanical engineers there, and I quickly learned of the prevalence of safety factors from them. It was an unspoken rule that, whatever safety factor you calculated, before you finished the design that factor had to be doubled. Better safe than sorry.

New car, part 2

2011-02-27T11:30:00.049-05:00

In my last post I wrote about Consumer Reports, partly as it related to buying my new car. While I wrote that I was struck by two related testing issues.

My latest car, a Ford Escape Hybrid, has Sync in it. Although I've identified several bugs with it, and the voice recognition needs to be improved (especially when there's lots of road noise), I have to give them credit: it's a very slick piece of software with plenty of nifty features.

Back in 2004 I realized that, at least in America, cars were not going away anytime soon, although they would certainly need to change. Gas prices would have to go up as emerging markets like China and India increased their energy requirements. So I bought a Prius in February 2005 and have loved it ever since. But it now has close to 200k miles on it - I'll probably need a new car soon. So I've been considering an all-electric car like the Volt. In my preliminary research I found a great article that pointed out the huge amount of electronics and software in this vehicle.

I guess the point of this post is that software in vehicles is going nowhere but up. The integration of phone/MP3/bluetooth that Sync offers, management of electrical power generation and consumption in hybrid and electric cars, onboard navigation, or even future features such as automatic driving: this will all require huge amounts of electronics and coding, and therefore LOTS of testing.

New car, part 1

2011-02-01T01:13:00.037-05:00

As I said in my previous post, a lot of things were taking up my time last fall. I'd like to relate three of them right now. Bear with me - there is a test-related payoff.

I bought a new car in October. After a lot of thought and research, I decided on an Escape Hybrid. I've written before about my Prius, it has never given me trouble, so I decided to try the SUV version of a hybrid from Ford. I did a lot of research before I committed to buying it, and so far - four months and 7000 miles later - I'm happy with the results.

My water heater sprung a leak last fall, and I finally bought a new one in November. Again, I did a lot of reading up on water heaters, and for better or worse I know more about them than I ever thought I would.

In October my washing machine went kaput. It just stopped working. I debated the merits of a) paying someone several hundred to fix it or b) spending days of my time fixing it myself. It was more cost-effective to buy a new one. For a third time, I did a lot of reading up on the subject and decided on getting a front loader. It saves water, it saves electricity, and it's a nifty piece of engineering.

I love Consumer Reports. For a small yearly fee I can read articles, view customer ratings, and test reports. The test reports are detailed, comprehensive, and informative. I've had a subscription to their magazine, and then the website, for a decade. Needless to say, I gave their test database a workout last fall on the three items listed above. It truly helped out. I tip my test engineer hat to them.

In mourning

2011-01-26T12:33:00.000-05:00

A few days ago the Department of Energy announced that Fermilab will be shut down in December. The New York Times ran a story on it here, as well as an editorial.

As I've mentioned before, as a physics grad student I spent a couple years at Fermilab working on software at the D0 detector as well as testing new calorimeters for the now-defunct SSC. It was a fun, frustrating, exciting experience. It's a sad day for American science as well as physics in general when such a premier lab has to be shuttered.

I wish everyone still at Fermilab luck wherever their future takes them.

New Years resolutions

2011-01-08T22:57:00.000-05:00

Unfortunately I haven't posted to this blog in over two months. A combination of issues - health, home improvements, work travel, kid issues - have contributed to my lapse. I have several items I planned on covering, but I perpetually delayed.

For the past several years I've kept a written document that lists all my new years resolutions. At the end of the year I write a review of how well I did for each resolution. I find it a productive exercise. On of my 16 resolutions for 2011 is write a minimum of two posts every month to this blog. We'll see how I do.

While I'm thinking about it, here's a list of things I want to write about over the next couple months (in no particular order).

TestStand
New cars
Keeping track of things
ATML
Blog toys

So that will keep me busy through March. Happy New Year.

Interview

2010-11-01T11:40:00.002-04:00

Every other month Test and Measurement World has a Test Voices section where they interview different test engineers. The engineers they talk with aren't necessarily the top of the field, just people working on interesting things. For November's issue they talked with me about the testing I do at my current employer. I have to say the process was enjoyable, interesting and efficient. If you're interested, the interview is here.

Blog Action Day - Water

2010-10-15T01:00:00.056-04:00

The past two years I've participated in Blog Action Day (2008 - Poverty, 2009 - Climate Change). On both times I've tried to relate it somehow to testing or technology. This year's topic is water.

When I considered water in terms of testing, I first thought about all the DI water that's used to clean DUTs. Then there's the various water-cooled systems I've used over the years. I've also met people in the New England area who test fuel cells - they are often concerned with how well the water the cell produces is evaporated. So water is a regular part of my field, one way or another.

But then I ranged farther afield. When I first moved to this part of the country, I had to test the water in the new house since it was well-based. Biologically, it was okay. There was a fair amount of sediment the pump sucked up, so I had a filter installed. But the worst part was the radon. There's a LOT of granite rock where I live, and granite rock can have trace amounts of uranium. Radon is a decay product of uranium, and there was some of it in the basement as well as the water. I installed a system to keep the radon out of the air, but filtering options for the water were too expensive. I settled for "use it, but don't drink it."

What I'm trying to say is that we use a lot of water at work, and even the water we drink has to be filtered somehow. The United States is about the top of the food chain economically. Imagine what problems people may have with water if they don't have our resources. Very sobering.

Bucket list: citizen science

2010-09-24T22:34:00.000-04:00

Back in June I wrote a post about my Test Engineer Bucket List. One of the items on that list was "Develop a test system that measures a fundamental aspect of the universe." I think I've found an indirect way to scratch that particular itch: citizen science.

In the August issue of Dr. Dobb's I read an article about a recent success of the Einstein@home project: a new pulsar. Very cool. Also, in the June issue of Wired there's an article listing six different astronomical projects - also very cool.

I doubt any of these projects would give me a rush like building a calorimeter that sat inside the beamline at Fermilab, but it could still be fun. Maybe I'll discover a black hole.

Visual Programming and LabVIEW, part 2

2010-09-13T09:15:00.000-04:00

In Friday's post I wrote about the latest LabVIEW version, my reactions to it, and some thoughts on graphical programming. This weekend I thought more about that conversation and wrapped it up with what I think LV should look like in the (near) future.

I applied for the App Inventor for Android, but I've read it takes a while to get approved for it. When I get it and play around with it some I'll probably write a post about it. But getting back to the Cube language thing from Friday, last month I started asking myself how would this translate to LabVIEW? First I made a little logo, since that's the most important part.

Then I started thinking about how it would look. It should be a stylized 3D environment: zooming in and out, pan and tilt, looking at it from top, bottom, front back, etc. Then I started defining some details:

Navigation: As I just said, it would be a 3D experience.

You could spin the entire wire layout like you spin around a 3D graph
You could "peer inside" a subVI object by making it slightly transparent
You could "zoom" into or out of subVIs

Icons: All the current LV icons should probably just be 3D renderings of their current 2D versions. But user-defined icons... THAT could be the cool part. Imagine designing an icon for a subVI that, instead of a small square with a little image and text inside, is a 3D image of the test equipment it uses (provided by the manufacturer of course). You could even swivel around to the back and see all the plug in options. Cool, huh?

3D image icon of a Keithley 2400

Stylized 3D icon

Debug: This option could be very slick. When debug is turned on, you could have the option of "following" data travel from a "first-person-shooter" perspective.

Still a classic

Optional: It might need to be something you could turn on or off, depending on the speed of the computer's graphics processing. Turn it off, and you're back to the 2D version of the flow.

This also gets down to the choice of whether the 3D view is superficial or impacts how the block diagram is compiled. If it's just visual, then you're fine. If, however, certain aspects of your 3D model impact how the program runs (see, for example, "Flow" below), then you might lose that if you turn off the 3D viewing.

View hidden items: The "hidden" frames of a case structure, event structure, etc., could be viewable as stacked items behind the front of the structure. It could appear perhaps as slightly separated index cards, with maybe the option to fan them out like a poker hand (which would look very cool).

Error case viewed from the front, maybe 30 degrees above the plane

Data Flow: This might be a tricky one. One of LV's defining paradigms is data flow, and style guides suggest left to right. But what happens if you can also go towards or away? Should there be a switch in the compiler that says that code "behind" other blocks is not as preferential and should run "as time allows." Or perhaps data on a tangentially angled line travels more slowly? I think there are several games you could play with that idea.
Layers: Mechanical modeling programs, imaging programs, and semiconductor layout programs all have the concept of layers. Different things happen on the different levels. Could we do something similar with LabVIEW 3D? I alluded to that idea with "Data Flow" above, but maybe it should be more concrete.

What if you defined separate layers for DB interfacing, hardware control, etc? But instead of switching to those different different layers, you could see them physically: just zip over to that layer with your mouse.
Or how about, for multi-core programming, coding on those different layers happened on different processors?
There are certainly other tricks you could do.

I really like this idea of a true 3D interface. I think the computing horsepower to do nowadays, it could improve the quality of LV programs by letting you see more details of the code, and it would be really fun to program in it.

Will this happen? Who knows. But if NI starts working on it, I want them to know that they heard it here first.... can I get royalties on that?

Visual Programming and LabVIEW, part 1

2010-09-10T23:00:00.002-04:00

This is a long post, since I'm covering several different ideas I've had the last few weeks. I'll break it up into two separate posts this weekend.
-----------------

LabVIEW 2010 is out, I've installed it, and I've played around with it for a month. Frankly, it leaves me a little blah. Yes, it has some speed improvements (but they improve the speed some every year) and some nifty new features (listed here) I can use. But there is no real wow factor for me. Maybe I'm jaded, but the last few LV releases have been solid stolid improvements on an existing edifice. I really liked the project concept in LV8, I applauded the object oriented programming support in LV8.2, and I thought the new icon editor in LV2009 was long overdue. NI has been releasing a lot of useful, individual features each year, but there has been no overarching theme. I'd just like to see something more from a graphical language.

I'd felt this way for the past year or so. Then I read an article last month in Dr. Dobb's Journal about Google's App Inventor. I followed this link to a 15 year old article about the cube language, written by a guy who now works at Microsoft. These two items sparked some ideas.

That's enough for tonight. Tomorrow I'll write what I think NI should do with a future version of LabVIEW.

The changing face of online content

2010-09-08T19:00:00.002-04:00

Although it doesn't directly relate to test engineering, there was a good Newsweek article last month about how blogs, twittering, and crowdsourcing in general is changing. Indirectly, it relates to what I wrote on my 3-year blog anniversary about test engineering blogs.

(more) Test humor

2010-08-28T09:00:00.001-04:00

Sometimes when you're testing things, you have to come up with an "innovative" fixture. This website really appeals to that part of my career.

Out of my jurisdiction

2010-08-23T23:00:00.007-04:00

I spent some time the last couple of weeks researching large scale chip-level testing. I needed some information for a new project, so I dug around online.

I'm no stranger to wafer-level testing or semiconductor issues - I've been doing that for many years now. But after digesting the information I found on , I have to say two things. One, the test issues those guys face are out of my current jurisdiction. Two, it's pretty cool stuff (see also here) and I'm enjoying learning more about it.

If you want to do some more digging on your own, I would suggest starting with Chip Scale Review and spread out from there. Also, take a look at this definition of automated test patterns as well as the interface language some large test systems use.

"Today, my jurisdiction ends here. Pick up my hat."

I want a tricorder

2010-08-18T12:00:00.046-04:00

Android Tricorder App

Last year I compiled a list of tools all test engineers should have. That list came to mind a couple of months ago when I got my spiffy Droid Incredible phone and downloaded the Tricorder app. It's a VERY cool tool/toy, especially for a test engineer.

I was reminded of that list again when I read the "New Age of DMMs" article in Evaluation Engineering. The title implied to me that there was a new line of DMMs I didn't know about. Sadly, it didn't deliver on that promise - I already knew about PXI DMM cards and the new capabilities they had.

But what about new handheld DMMs? So I checked out Fluke (of course), and they have a couple of neat multimeters I hadn't seen before. The Fluke 289 is a good DMM that has logging capability with a TI-calculator-type graphing option (it got a Best In Test award in 2009). Even better, the Fluke 233 has a slick wireless option - you can hook it up, put the display in your pocket, walk up to 30 feet away and still read what it's measuring.

Fluke 289

Fluke 233

Both of those would be nice to have. But I still want a tricorder.

Testing rebound

2010-08-13T14:33:00.000-04:00

There was an article on Test & Measurement World last week that points out how the major test equipment manufacturers (Agilent, Tektronix, Fluke, etc.) are rebounding from the last year or two. I would think that this means that test engineering as a career is rebounding as well, since if companies are buying the equipment, then there are engineers needed to spec it, set it up, and run it. This rebound syncs well with the up-tick I've personally seen in job openings in the Boston area. Food for thought.

LabVIEW 2010? Not quite yet...

2010-08-04T22:30:00.004-04:00

I feel sort of bad for picking on National Instruments, after what I've written the past couple months (here or here). But I'm annoyed and need to vent.

NI released LabVIEW 2010 this week. I received an email saying that, "for immediate access, download your new software online at the Services Resource Center." I had a new computer running Windows 7, so I decided to try the 64-bit version of the new software. The download and install took several hours but appeared to work fine.

Problems occurred, however, when I tried to open one of my projects. As soon as I opened the top level VI, LabVIEW started requesting subVIs from toolkits that I had a right to have - database toolkit, report generation, etc. - but were not installed with the download. So I called NI support and they suggested downloading the toolkits individually.

No luck. NONE of the toolkits are 64-bit (except I think vision), therefore none of them will work with my 64-bit install. NI is working on it, but it isn't there yet. When I asked the NI support guy if all the time I spent downloading, installing, and setting up was therefore wasted, he just said, "that is a true statement."

Misleading specifications

2010-08-01T21:30:00.013-04:00

I've been learning more about solar cell testing over the past year. I have a couple of test systems I'm developing, I've taken data, and it's been interesting. It's also been frustrating.

As an example let's consider I-V sweeping, the bread and butter of semiconductor testing. Most of the basic values of a solar cell can be determined from a quick IV check. One of those values, the short circuit current (I_sc), helps determine the maximum power a cell could theoretically produce. A high I_sc is nice to have.

When I first looked at measuring IVs for solar cells last year, I tried to re-purpose my National Instruments PXI chassis to this task. I knew that the source measure unit (SMU) in the chassis (PXI-4130) could only go up to about 1A, but there was an auxiliary supply that could plug right in to the SMU: the PXI-4130 Power SMU. On the NI page for the aux the output specs are listed at "12 VDC, up to 5 A, up to 60 W, 0 to 55 °C" (note the "5A" limit). So I bought the aux supply and got started testing.

But as I tested larger and better cells, with more total current output, I ran into limitations with the NI approach. I couldn't measure an I_sc above 2 amps. This confused me somewhat, since I had seen the the five amp limit on the NI page. Adding insult to injury, I didn't even need the SMU to output that current - the solar cell was generating the current.

I then considered connecting multiple SMUs. There is a "knowledge base" article on the NI website that supposedly answers the question, "What is the Maximum Voltage and Current that the NI DC Power Supplies can Source when Cascading Outputs?" But nowhere on that page does it list a maximum current. I even found a Photovoltaic Solar Cell I-V Characterization Bundle page that says you can "add more SMUs to get three times the voltage or current." I struggled with this problem for a month.

Well, I finally got an answer from NI last week. The SMU cannot measure above 2A current because the PXI chassis has to dissipate the power, regardless of where the current source is. The chassis has "a hard limit on the amount of power consumed by each of the SMUs." In other words, National Instruments has some cleaning to do on their website.

------------------------

So what's the moral of this rant? First, I'm going to get a different power supply (maybe Agilent). Second, you cannot always trust the hardware verbage you read online.

Check your test equipment

2010-07-27T22:10:00.002-04:00

I heard about a perfect example of #1 on my test engineering fears list on the radio the other day. Some doctors announced earlier this summer that they had "identified a group of 150 genetic variants that they said appeared to allow people to live past 100." Very cool, but now it appears that there was a flaw with their test equipment.

Of course, I've never had that problem before....

The Power of Complaining, redux

2010-07-22T22:43:00.001-04:00

Over two years ago I wrote about complaining to National Instruments and the eventual response from NI. Well, back in March I wrote about what happened when I took the CLD.

I use Google Analytics periodically, so I know that my blog gets regular hits in the greater Austin area (National Instrument's home). So I suppose I shouldn't be surprised that eventually someone from NI read about my test experience. A few weeks ago I got an email from the Manager of Customer Education at NI to apologize for what happened. She also said that the problems had been addressed and shouldn't happen again.

I'm not a NI or LabVIEW fanboy by any stretch, but I'll always acknowledge when they do something right. Thank you, Carol.

How To Complain

Posting from Oregon

2010-07-15T21:52:00.000-04:00

I haven’t posted in over a week since I took some vacation time, and then I was hit with a flurry of work that lasted until Saturday afternoon, took a quick break, and is going strong today. A couple of days ago I was somewhere over west Texas watching electricity light up a thunderhead like a deranged Christmas tree. So I decided to catch up on my reading.

What follows is a list of four articles from magazines, digests, etc that I subscribe to. I managed to at least scan each of these and found them at least mildly interesting and at least somewhat related to test engineering. Some of them are recent, some are over a year or so old. I sometimes get delayed in my reading, but at least I get around to it.

Why We Need A Theory for Software Engineering
Dr Dobbs, Oct 2009
This is somewhat related to what I wrote a couple years back about software certification. Plus it gets points for having Ivar Jacobson as an author.

Data Management Speeds Up Simulation of Crash Test Dummy Models
Nasa Tech Briefs June 2010
Crash test dummies are cool, and the idea of simulating those crashes and analyzing that simulated data is perversely cool as well.

The Online Shadow Economy
ZD Net/Messagelabs
This is a white paper, which means it is a piece of marketing with some small amount of redeeming tech value – the actual amount is negotiable. I don’t know how real the picture painted by the author may be. But it’s a fascinating one to examine, even if it is touched up with a bit of invisible ink.

Software Tool Integrating Data Flow Diagrams and Petri Nets
Nasa Tech Briefs March 2010
This little article intrigued me on several levels. First, the tool itself looks like it would be useful for software testing (early in the process). Second, I had never even heard of Petri Nets before - cool stuff. And finally, the guy who invented them (at age thirteen no less) died just a couple weeks ago.

Blog anniversary follow-up

2010-07-04T11:00:00.001-04:00

I was trolling around the NI website looking for blogs I may have overlooked when I wrote this post. Then I found this little nugget: a recent presentation for NI employees about running blogs. I had a good chuckle reading it, especially considering none of the NI blogs I saw were updated at the suggested once/week rate. Also, several of the statements in that presentation paralleled a Wired article and NYT piece I covered a year ago.

When I worked at HP they had a policy of awarding money ($1000 back then) to anyone who was published in a magazine or journal. So when I published an article in a visual basic magazine I scored twice: about a grand from the magazine as well as HP (sweet). I wonder if NI employees that run their own blogs get extra compensation? Or are they allowed to advertise on their blogs? Food for thought.

Three year anniversary

2010-07-01T05:00:00.003-04:00

I've now completed a third year of writing to this blog. That's 133 posts, 35 of them over the past 12 months. That's just a bit above my 32-post pace for year two, and way off my 66 posts the first year. It's rough to keep up just a ~2.5 post/month pace, much less a post a week.

That's what I want to write about yet again today. I took a look at the 8 blogs I had recommended after my first year. Seven of them haven't been updated in a year or more, or only had a single post in the past several months. I'm not even sure if the eighth blog counts, since it's maintained by Test and Measurement World.

I also tried looking at LabVIEW-specific blogs. My main source was this list of blogs on the LabVIEW wiki. Of that really long list, I only found 3 blogs that I would consider current: at least one post per month. And ALL of those blogs are written by National Instruments employees, so again I'm not sure that counts.

So, aside from patting myself on the back, what am I saying? I guess my point is that I've kept writing steadily for 3 years and intend to do it for years to come. As I said a few days ago, I enjoy it.

Almost 3 years

2010-06-28T02:00:00.000-04:00

As I mentioned back in April, I had several ideas for new posts but didn't have the time to finish them off. Now it's close to the end of June and I've posted three items in the past week. I'm catching up.

I am also approaching the 3rd year anniversary of this blog. That date, along with my recent stops and starts, prompted me to ask, "Where am I going with this blog, and what do I want to accomplish?"

I occasionally use blog tracking software, so I know I get between 200 and 400 visits per month, averaging about 1.5 pages per visit. That's a minuscule amount by popular blog scales, but test engineering is hardly a hot button topic. People comment rarely, although I have had a few acquaintances tell me they read my blog and enjoyed it.

I don't get paid for this, it's not a supplement for my job, and I'm not trying to score points with people online. Why do I do it? Because a part of me always wanted to write - in college I briefly debated trying to become a novelist. What do I want to accomplish? To entertain and educate, in relatively equal proportions.

Okay, that's enough touchy-feely soul-searching for one day. I hope everyone had a good weekend.

LabVIEW patent digging

2010-06-27T01:00:00.019-04:00

I started down this path when I read an article about DASYLab in the April issue of Evaluation Engineering. That triggered something in my memory about Measurement Computing, the company that published DASYLab. After doing a little digging, I thought I confirmed what I remembered: National Instruments bought them out many years ago (1998). But then I found a different article from 2003 stating that SoftWIRE, a subsidiary of MC, had patents it had acquired from Fluke that predate the NI patents for LV. Hmm. Finally, I found an article on Bloomberg that states, "as of April 29, 2005, Measurement Computing Corporation operates as a subsidiary of National Instruments Corporation."

But doing all that digging started me thinking about NI's patents. Dataflow programming was first proposed way back in 1966 by Bert Sutherland, so NI couldn't patent that. Although, if you do a patent search on, say, NI and programming you'll find hundreds of patents (or look here). To my knowledge, patents can expire in as soon as twenty years. LabVIEW was first introduced back in 1986. Doing more digging, I found yet more nuggets:

According to this news release, one of NI's key LabVIEW patents expires in April of next year.
NI spent significant time and money defending a patent against The Mathworks (the MatLAB) people in 2002.
There was a very interesting conversation on LAVA back in 2004 regarding the SoftWIRE v. NI lawsuit.
Right around the turn of the century NI was in a LOT of activity: licensing patents and buying companies to resolve patent disputes (ex: here, here, over there, and out thatta way).

So where does this trip down the rabbit hole lead? Here's what I saw:

Many of the original LabVIEW patents are getting long in the tooth and will start to expire as soon as next year, if they haven't already.
NI has no problems litigating patent infringement.
NI will buy companies to protect patents.

Based on that, here's my prediction: history will repeat itself. In the next few years there will be at least one software company that develops a software package that competes on the cheap with LabVIEW (which currently runs several thousand dollars per license). They'll be able to do this because of those expiring patents. Heck, they may even write their compiler so that it can use subVIs written for LabVIEW. After this happens, NI will sue them, force them out of business, or buy them. I imagine they'll buy them out - I doubt they'd want the price point on LabVIEW to drop at all.

It'll be interesting to see how it plays out.

SQL Options

2010-06-25T05:24:00.014-04:00

There is a great article on non-SQL databases in the June issue of Dr. Dobb's Digest. It basically surveys the NoSQL movement, something that I quite frankly had no idea existed before I read about it this past weekend: non-relational databases designed to handle terrabytes of data across multiple geographically divers systems. I'm far from a database expert, but I've dealt with them enough so that I could follow the article.

I'm bringing this up today because it dovetails in with a post I wrote almost a year ago. The point I was making back then was that, with memory and computing so cheap, large amounts of data and statistics would become an increasingly larger part of a test engineer's job. The Dr. Dobb's article complements this idea by describing the tools being developed to deal with this data.

Test Engineer Bucket List

2010-06-24T10:51:00.002-04:00

I've never seen the movie The Bucket List. Nor have I seen either the MTV show or the CBS special that played on the same idea. The idea of making a list of things to do has certainly been around for a while. In fact, a good friend of mine crossed off a major item on his list a few years ago when he bought a Ferrari. "I could almost die happy now," he said.

When he first took me for a spin in his sweet ride, I started thinking about my own list. But now I'm putting a different spin on it: a test engineer bucket list. Before I retire, hopefully a long time from now, what would I like to do as an engineer?

I'm not talking about accomplishments. It would be quite easy to make a list that included items like, "make a ton of money, receive multiple patents, publish numerous papers." That's more of a self-serving list than a self-fulfilling list. Instead, I aimed for things that I would personally want to do as a test engineer, things that I would find professionally satisfying, and things that are just fun. Often we don't think of work as "fun," but sometimes it can be a real hoot.

So I came up with a list of five items. They're in no particular order, but I think they all fit my above boundary conditions. Perhaps it will inspire someone to create their own list.

Mentor a young engineer
I don't think I'm quite old enough to seriously consider being the "elder voice of experience" for younger test engineers. But I can think of several people who tutored me when I was younger. Those lessons were not really about technical details. They had to do more with how to deal with difficult coworkers, presenting your case in a meeting, and other things you don't get in college classes. I'd like to pass on the favor at some point down the line.

Work as a true manufacturing test engineer
Most of my career has been on the R&D side, bringing up a pilot production system, or small production quantities. I think it would be interesting to see how the other side lives: analyzing massive amounts of data for a thousand devices tested a week, troubleshooting an entire floor of test systems. Maybe I'd do it for a few months, maybe a few years.

Be a consultant
This is similar to the "manufacturing test engineer" item above. I worked in sales for a couple years, and that scratched a particular itch. Trying out my hand as an engineering consultant would be another one of those itches. I've worked with several consultants, and sometimes I've thought it would be fun to try that career change out for a while.

Develop a test system that measures a fundamental aspect of the universe
I used to do this, a long time ago. Over the past decade I've worked at startup companies trying to commercialize bleeding edge technology, and that has it's moments. But nothing beats the thrill of measuring something that stretches the bounds of science itself. It'd be great to experience that once more.

Write a story about a test engineer
This would definitely be on the "fun" list. I don't think I've ever read a novel about an intrepid test engineer braving impossible odds to save the day. I do think it would be a blast to try and write one.

Getting busy again

2010-04-12T12:03:00.000-04:00

It's getting pretty busy again for me, in my work and personal life. Because of that, I have several post ideas awaiting completion, ranging from "mostly written" to "a couple of web links." At any rate, by the end of June I expect to have them all done. In no particular order, here's a list of what I have in mind:

Updating the blog
LabVIEW 2010 testing
ATML
Bucket lists
LabVIEW patents
Reliability testing

LHC!!

2010-04-04T16:30:00.015-04:00

Over the past couple years I've talked about my history with high energy physics (HEP) and my excitement with the LHC (here or here, for example). Well, on March 30th they finally slammed protons together at a total energy of 7TeV. Granted, that's only half the energy total they're aiming for, but at least it's doing real physics now.

Looking for evidence of the Higgs boson (that's suppose to be the particle that explains mass like photons do for light) or dark matter is supposedly the official reason for the LHC. But there's always a perverse side of HEP that wants to break the Standard Model. If you can't find the Higgs, or you find something completely different, then that's when it gets really interesting. Sometimes I miss being in the mix of that, but life goes on.

If you're interested, there's lots of photos, videos, and other goodies at the public CERN website.

April Fools Day - Klingon Tests

2010-04-01T03:00:00.016-04:00

Back a couple months ago I posted a couple of bad jokes I had made up about hydrogen. Since then I've been thinking about posting more jokes, but in a testing vein. I've done that before (here and here), and April Fools' Day seems like a good time to do it again.

If you hate Star Trek, you might want to stop now. You won't really get it.
======================

Okay, what I'm posting below is actually a repeat of some jokes I had on my group's website when I worked at HP. Enjoy.

Specifications are for the weak and timid!
You question the worthiness of my code? I should kill you where you stand!
Indentation?! - I will show you how to indent when I indent your skull!
What is this talk of 'release'? Klingons do not make software releases. Our software escapes, leaving a bloody trail of designers and QA testers in its wake.
Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
Debugging? Klingons do not debug. Our software does not coddle the weak.
A TRUE Klingon Warrior does not comment on his code!
Klingon software does NOT have BUGS. It has FEATURES, and those features are too sophisticated for a Romulan pig like you to understand.
You cannot truly appreciate Dilbert unless you have read it in the original Klingon.
Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

As a bonus feature, a friend of mine from high school forwarded these old Star Trek images to me. Enjoy.

Falling into your lap

2010-03-27T13:02:00.006-04:00

Sometimes a perfect project just falls in your lap.

At work I've been heavy into upgrading an existing test system, but I'm at that point in a project where I can see the end. I was starting to consider what I should work on next. I'm not at a loss of potential ideas, but none of them seemed very urgent. Then one of the R&D engineers came to me with a need to do some visual inspection measurements. That sounded great to me, because it's been three years and two companies ago since I last worked with the LabVIEW vision tools. This should be fun.

Passed the CLD (part 5) - test day

2010-03-17T07:00:00.003-04:00

I passed the CLD exam a couple weeks ago, and I'm writing about that experience. I've talked about the NI courses, working sample problems, and my test prep guide. So all that's left is to go over the actual experience. The description is a bit personal, but hopefully if you take the test yourself you might get something out of this account.

It's been a long time since I took a serious test. The last time must be when I took CS grad school classes back in the late 90s. I was nervous. To fight that feeling, I tried to prepare myself as well as I could. Get plenty of sleep for about two days prior to the test, jam to good music the night before, eat a good breakfast that morning. I drove down late Monday morning for the 10am appointment.

I brought my own mug in with me to the test, filled with Mountain Dew (an old college habit). I took the exam in a nice quiet room at a nearby NI office. Unfortunately, this nice quiet room was right next door to the breakroom. At noon it got very noisy. The NI employees were having a good time discussing their weekends. They must have enjoyed it, because there was a lot of loud laughing.

Around 1pm, after trying to code through an hour of conversation, LabVIEW crashed. Great. Fortunately, I had the sense enough to leave the computer alone and show the coordinator what happened. She called down to NI in Austin, and they gave me the option of getting some extra test time or retaking the test another day. Tough call, but I decided to just finish the thing. So I rebooted the computer, restarted LV, recovered the code, figured out what work I had lost, and got back into the programming zone (thankfully quiet this time around).

So that's what my test day was like. It could have been worse, but if any of you take the exam I hope your day is better than mine.

Passed the CLD (part 4) - preparations

2010-03-14T16:15:00.000-04:00

I passed the CLD exam a couple weeks ago, and I'm writing about that experience. I've talked about the NI courses and the NI sample problems. Now I want to show you my test prep guide.

Before I copy it down, let me describe it. I had two goals. First, I suspected that the 4 hour limit would be tough for me, so I wanted to lay out what I should be doing and when. Second, I researched the test extensively. Aside from reading the NI-provided preparation materials, I read online articles and what people wrote about it (for example, on the NI forums or at LAVA). I wanted to efficiently summarize that information.

So, here it is. If you copy it to a two-column document, it fits on a single piece of paper.

1. Open LV if not already open.

2. Read through the problem.

3. Create a blank project and save it.

4. Ctrl-H so I can see the help box.

a. Reminds me to comment everything.

5. Create a blank VI.

a. Turn off automatic tool selection.

b. Select nothing on the front panel and change the font style to bold. This makes all subsequent creations boldface.

c. In the block diagram, open the function palette and search for something.

i. It takes time for the list to populate.

d. Click on the icon to change it.

i. It takes time to load the icon editor.

6. Read through the problem again, in detail.

a. Define the basic objects.

i. These will likely be custom controls.

ii. Start creating some base objects.

1. Reference the GUI.

b. Define what the different state conditions are.

i. The graders look for a state machine, event structure with states, etc. Looking for specific states is a good place to start.

c. Decide on the basic architecture to use. NI states that “exams are based on a sequencer-type application” and “timing is an essential aspect.”

i. State machines: obvious solution, but not suited for storing sequences or (maybe) GUI events.

ii. Queue-based events: commonly used, stores sequences, limit the processing in the event case.

iii. Producer-consumer: possible choice for some CLDs, not great for non-user interface events.

d. Timing

i. Execution: Regulates loop execution (ie – state machine) – may introduce jitter or unresponsiveness.

ii. Software: Measures elapsed time with stop/reset/pause options. Use func global, subVI, or express VI.

iii. Others: Event case timeout, synch VI timeout.

e. Create a top-level VI using a design pattern. Probably a state machine, producer-consumer, or something like that depending on the problem.

i. Take up the full screen width so you know your space – shrink it later.

f. Save it and verify it’s added to the project.

7. From the provided screen shot, design the basics of the front panel.

8. Style checklist

a. Avoid local variables.

b. Property nodes <> indicator or control values.

c. Type defs!

d. No coercions or default tunnels.

e. Make subVIs.

f. Readable code!

9. Error handling

a. Wire error terminals.

b. Wire error clusters to “no error” case.

c. Stop top level VI on error (all loops)!

d. Use simple error handler on program exit.

e. Monitor errors from parallel loops.

10. Documentation

a. Documentation for the VI & subVIs.

b. Free labels on wires.

c. Labels on block diagram items.

d. Label the actual loops (yes you can).

e. Label constants.

f. Tip strips on GUI.

g. Consistent icon scheme.

h. Be brief & to the point.

11. Test

a. Functionality

b. Weird behavior from user.

12. Final check through.

a. Close the project.

b. Reopen it.

c. Open the top level.

i. Make sure there are no errors.

ii. Verify that it runs correctly.

d. Double check documentation on every VI.

e. Make important terminals on subVIs required.

f. Run VI Analyzer if time permits.

===========================

I'll have just one more posts on this subject: the actual test day experience. That should be up in a couple of days, and then on to other topics.

Passed the CLD (part 3) - preparations

2010-03-13T11:20:00.000-05:00

I passed the CLD exam a couple weeks ago, and I'm writing about that experience. In part #2 I talked about the courses that NI offers. Now I want to write about the example problems NI publishes.

NI has plenty of information on their website about their exams - preparation guides, slide shows, and sample exams. There are three samples: a traffic light, a security system, and a car wash. These problems have been posted as examples for a while. I know for a fact that the traffic light problem has been on the NI site since at least 2003.

There are two lessons to draw from that last statement. First, the problems are older and, in my opinion, not as sophisticated as current test problems. Second, the solutions are old as well and not very good. I'm not the only one who thinks this. Do a search through the comp.lang.labview users group, or LAVA, or even on the NI discussion forums, and you'll see that many others have expressed the same opinion.

Here's what I'm saying: don't limit yourself to the practice exams and the NI-provided solutions. Look online for the solutions from other people, read through the discussions about the problems, think about how the problem could be made more complicated. A couple of links to get you started are here, here, here, and here.

=====================

In the course of preparing for the test, I tried to summarize what I learned from the sample exam solutions. Here's an abbreviated list of what I wrote down as important - your own lists may differ.

The top level VI is at least a state machine. Make sure you have an initialize option, and set up default properties within the initialize state. Don’t have them sitting outside the loop – that’s messy.
Controls & clusters

When in doubt, type-define.
There are some things (like changing colors) on a strictly type-defined control cluster. Make it a regular type-defined control instead.
For a control reference, use the To more specific class function to cast the reference as a known control.

SubVIs

Wire errors for all subVIs. Use a case statement to skip operations if there is an error.
Make use of functional globals.
Always have an initialize case for functional globals.
Some subVIs will be state machines themselves.

Timing is an essential part of the CLD exam. You need to understand how to time operations, pause them (while maintaining the elapsed time), and abort them.

If you can, just use the express timer.
If you have to create a timer VI, make it a functional global.

The main states are Initialize, Start Time, and Get Time.
Use the initialize option to set everything to zero
The stored items in the VI are the target time, start time, elapsed time, and Time Elapsed?
Check the time as the image below: subtract the current time from the start time to see if the difference is greater than the set time.

Queues are often used in sequence-type patterns. Know them well.

Adding something to the queue puts it at the end of the line. To put it at the front of the queue, use the Enqueue element at opposite end function.

If you must abort a sequence, place the abort action in the front of the queue.

Queue VIs wait until there is something in the queue to act upon. Use the timeout option if this behavior is unwanted.
You can preview the next item in the queue without removing it.

Passed the CLD (part 2) - preparations

2010-03-11T08:07:00.000-05:00

As I mentioned last week, I recently passed the Certified LabVIEW Developer (CLD) exam. In that post I said that I'd write more about my preparations. One way I prepared was studying course materials.

There are three courses that NI recommends you take before trying the CLD exam: Core 1, 2 and 3. In fact, they offer a money back guarantee if you don't pass. That's a good thing, since the price just for Core 3 is ~$2k.

Note: the courses used to be named LabVIEW Basics (I and II) and LabVIEW Intermediate (I and II). They were renamed last year to "better align with NI certification program." Sounds like marketing to me.

Anyway, I said that I studied the course booklets. I didn't actually take the courses. Well, I did take a LV basics course, but that was back in 1997. I borrowed a copy of the Intermediate course books from friends, along with the CDs, and worked through them on my own time. Most of it was review, but I picked up a few tidbits while studying. Furthermore, that work helped me focus in on LV in a way that my normal job couldn't.

Alternative: If you want to take the classes but can't afford it (or your company won't pay for it), and you can't get a copy of the books from a friend, then try searching online. I suspect that somewhere out there someone has published the contents of the courses. Not that I'm condoning that, since I'm unsure of the legalities. But it is an option.

===============

I think I'll make three more posts on this subject. Two of them on preparations for the test, and the third on the test experience itself.

Changed the RSS layouts

2010-03-05T16:14:00.000-05:00

Someone pointed out to me that many of the RSS feeds at the bottom of the blog had Invalid Date listings. I then found out that Science Magazine now requires a (free) membership to view articles. That's all well and good, but they should change their RSS settings to at least allow the "article publish date" to go through. Looks like they didn't thoroughly test their software...

Anyway, I changed my feed to Science News, which gives me no invalid results at all.

Passed the CLD exam (part 1)

2010-03-04T13:45:00.000-05:00

Last summer I finally decided to take the CLD exam. Other things interfered, and it took a while to decide when I'd have time to prep for the test and take it. But I finally took it early in February - that's the main reason I didn't post anything on this blog in January.

I just found out I passed. I was pretty sure I did well, but it was nice to get the confirmation. I'm very busy until after the weekend, but I hope to post about the experience in more detail in the next week or so (hence the "part 1" title). In particular, I'll discuss preparations and the actual test experience.

Article on Test Proficiency

2010-02-15T10:03:00.000-05:00

While looking up some LabVIEW details I came across this article about skills a test engineer should have. This dovetails nicely with quite a few blogs I've written. It will make you think.

Geeky humor

2010-02-06T11:27:00.000-05:00

So I heard a joke from the CEO of my company yesterday that was told to him by a very rich, well-known engineer. Not to drop names, but he's on the same order as the guy who invented the mouse. They were discussing a startup company that's designing hydrogen fuel-cell technology:

A hydrogen atom walks into a bar, walks up to the bartender and says, "I've lost my electron. Have you seen him?"

The bartender replies, "Nope. Are you sure you lost him?"

Says the hydrogen, "Yes, I'm positive."

That joke was so bad, I came up with two others this morning. They're also bad, so naturally I had to share.

After the hydrogen atom has been at the bar a few minutes he looks at the clock on the wall in surprise. "Is it really that late?"

"Yeah," replies the bartender. "You have to leave already?"

The hydrogen atom nods. "I've gotta split."

And this one:

Before the hydrogen atom leaves the bar he sees an oxygen atom walk in with two blonde bombshells, one on each arm. He groans and says, "Now that's just not fair."

"What isn't?" replies the bartender.

The hydrogen atom points to the three and says, "There should only be one of those blondes per oxide."

I'm sure the job offers for joke writer at SNL will start any minute now.

Happy New Year

2009-12-31T23:54:00.000-05:00

Happy Holidays, and I hope 2010 treats you better than the last. Heck, I hope the next DECADE treats you better than the last.

JMP 8.0

2009-12-26T11:51:00.001-05:00

I upgraded to JMP 8.0 this fall, and it's great.

I'm in danger of being redundant, since I've mentioned this software package FOUR separate times over the past couple years: here and here in 2007, briefly in 2008, and again this past summer. But I've used the software regularly since 2005 for data analysis and presentation material. I really like it.

Anyway, I wanted to give props to SAS for the latest version of JMP. There are a few big things they added (I liked the animated graphs) and several smaller additions, but the best feature for me has been the graph builder. In the past when I was trying to see a trend in data I would graph some things as linear plots, try them as contour plots, maybe add histograms. In other words, I would play around with it.

Graph builder sort of automates that process. You can interactively add data to the x-axis, multiple sets of data to the y-axis, separate plots with the same x-axis, separate sets of data on the same plot, etc. If you don't like what you see, remove a set of data, or graph it differently. It's helped me out with two specific problems already, which makes it worthwhile in time savings alone.

I don't work for SAS, I don't get any compensation from them. I just really like the software.

Instrumentation Finder website

2009-12-16T10:57:00.001-05:00

There's a relatively new website called Instrumentation Finder. To quote from their intro page:

This site aims to provide a one stop shop for any and all Instrumentation requirements whilst providing all users with the option to source equipment from overseas suppliers outside their normal purchasing reach.

I've tried it out some and it is a) heavily biased towards UK and Europe suppliers (they say that is changing), and b) still a work in progress. But I certainly like the idea of a website specifically for finding instrumentation manufacturers and their products.

FIRST robotics

2009-12-08T12:43:00.001-05:00

I posted over a year ago about FIRST Lego League and how my oldest son liked it. Well, now my second son is in middle school and decided to join the robotics club as well. They had their regional competition a few weeks ago and just barely missed the cutoff for the state championship.

He was disappointed about it, but I know he had a lot of fun. From an engineering point of view, I thought the best part was the night before the regional competition. I stopped by for the last half hour of their planning session and got to see them toss ideas back and forth, debug code, and try out different ideas for solving a tough challenge. In other words, it was a lot like a group of engineers solving a problem. Cool.

Spam

2009-11-24T09:12:00.001-05:00

Well, today I had to implement word verification for comments to my blog. Up until a couple months ago I'd never had this problem. Test engineering is not exactly a hot button topic, so this blog never gets more than a couple dozen hits a day. I probably flew below the radar.

But starting early this fall, and accelerating the past couple weeks, have been a lot of badly-phrased comments advertising drugs and websites of the usual varieties you see in spam. I guess the auto-generating junk-mail code out there is starting to expand.

So now I've implemented captchas for anyone who wants to add comments. Hopefully that will cut down on the comments I have to delete.

Test engineering fears

2009-11-13T06:07:00.000-05:00

I originally planned to write this post for Halloween, but my schedule slipped. Today is Friday the 13th, so that's a decent fallback position.

========================

My middle child was talking about scary movies and what he thought made them scary right before Halloween. That started my thought train on what I fear as a test engineer. More specifically, what a test engineer at a startup fears. Here's my top five:

5) Bugs caught by management

In a small firm most everyone helps out, even management . When you write code, bugs are inevitable. It's okay when other engineers spot the bugs, but it's really embarrassing when the CEO emails you about a mistake he found in your program.

4) Feature creep

Things are always changing in a startup, and that most definitely applies to the testing process. You come up with better ways to test the DUT, you come up with new things to test on the DUT, you speed up your testing, etc. All of these things are fine, but sometimes they feed into extraneous changes to the test system. A design engineer may think, "Hey, it'd be really cool if I could see this set of data while the test is running," but any change like that takes time, and those changes can eat into the time you need for something else.

3) Bad requirements

Worse than feature creep are bad requirements. Suppose you are told that you need to measure current and temperature of a DUT under specific load conditions. So you get the hardware, set up the software, build the station. THEN you are told that - oops - we also need to measure optical parameters of the DUT under a separate set of conditions as well. Suddenly, you have a serious rework on your hands. That scenario can happen in a startup, and it's a real pain.

2) Data getting lost or corrupted

In every startup I've been a part of, data management is a problem. In the beginning, it's easy to sort your data and analysis work with a combination of spreadsheet files, text files, and a good subfolder setup on your network. As the startup grows, you have to implement a database, which introduces its own growing pains. In the meantime, your company lives and dies on that test data. About 4 years ago I had a problem at a startup where an entire set of test-data subdirectories was accidentally deleted from the network by an engineer working in his own directory. I spent an entire day getting the IT guy to get the network backup from two days before and then figuring out which devices had to be retested. Gruesome.

1) Great test results

This is my top fear. At a tech startup you are developing new technology. Things aren't supposed to work right. You have problems with the manufacturing process, you miss key design issues, or you discover unexpected behavior. When I see great test results from a DUT I get nervous; my first thought is that something is screwed up with the test equipment. So I will do a quick check of the hardware connections, software design, and the algorithms used. Good results can play havoc with my sense of well-being.

Post Eleventy One

2009-11-08T09:21:00.001-05:00

I didn't realize until last month that I had recorded 100 posts to this blog. By then it was too late to really say anything about it, but I wasn't about to pass up a chance to commemorate 111.

Why that number? You could say that it's because of the interesting information about it on Wikipedia, the fact that it is symmetrically slick, or even that it was Bilbo's birthday when he left the Shire.

But really, it's because in binary form the number 111 converts to 7. And as everyone who watched Saturday morning cartoons in the 70s can attest, seven is a lucky number.

LabVIEW source code control, Tortoise, and JKI

2009-11-06T22:49:00.000-05:00

All programmers should know the advantages of source code control (SCC), so I'm not going to talk about that. What I do want to touch on is using SCC with LabVIEW.

I've used Tortoise SVN for close to three years now with LabVIEW. It works pretty well, although LV doesn't sync well with SVN. Several years ago I used Visual Source Safe, and I liked being able to check files in and out from within the LV development environment. So I was happy when I saw JKI say that they had a Tortoise tool. I installed it later that summer, but then LV2009 came out so I had to re-install it.

I don't use it anymore, for one simple reason. Everytime I try to check something in or out, this annoying popup appears:

I might as well just go to the explorer window to check in & out, which is what I've done for years now.

I can understand JKI wanting to make money for their work (although $99 seems steep). But that pop-up appears every single time... it has annoyed me so much that I'll never buy it. Too bad, because otherwise JKI seems to do great work.

Catching up

2009-11-05T16:08:00.000-05:00

As you may have noticed, I've posted more to this blog the past week. I was swamped this fall. After a fairly productive July and August, I posted a single post from September to October. I had ideas for posts, I wrote down snippets, and I tried to schedule time to finalize thoughts. But that last step can be a stretch. Regardless, I'm catching up now and expect to have at least 4 more in December. I hope you get something out of them.

Climbing mountains vs building roads

2009-11-05T13:59:00.000-05:00

I read an obituary for Israel Gelfand a couple weeks ago, and it struck me as a very interesting read. I especially liked the travel analogy comparing the mentalities of two great Russian mathematicians:

“Suppose they both arrived in a country with a lot of mountains,” Dr. Retakh said of Dr. Arnold’s comparison. “Kolmogorov would immediately try to climb the highest mountain. Gelfand would immediately start to build roads.”

As a test engineer more often than not I'm building the roads that others will use to get to the mountains. And I like that.

Climate Change

2009-10-16T11:10:00.001-04:00

So I had signed myself up for Blog Action Day, on October 15th, and then forgot about it. The topic was Climate Change, and I had a vague idea of what I wanted to discuss. But this past week I've been helping my son with a big term paper, running around town running a lot of errands, and it slipped my mind. It didn't help that it had been over a month since my last post on the blog. But better late than never.

I met a fellow grad student back in 1990 that was planning to do his dissertation on climate modeling. Dr. Hansen gave his famous senate testimony about global warming in 1988, and this was now a hot topic in scientific circles. This particular student was fascinated by all the mathematical modeling involved and how so many different aspects of physics and chemistry had to be involved.

I'll never forget a long conversation we had about the changing climate. Even then he thought it was more important to call it climate change instead of global warming, because he believed that the key change was the increased amount of energy in the system. The planet heats up, sure, but heat is just energy, and all that energy can go into other things as well. The oceans heat up, the air heats up. This leads to more storms, deadlier storms, changing weather patterns, etc.

It all sounds sort of prescient nowadays.

Test Engineer of the Year

2009-08-29T08:24:00.000-04:00

Test and Measurement World may appear to be yet another trade magazine , and sometimes they are. But they also do great things for the test engineering community, like the salary survey. Their annual Test Engineer of the Year award is another one of those community service sort of things. Pretty cool.

So, go read about the past finalists and winners. Then recommend someone you know who deserves the award. Then vote.

Statistics is cool

2009-08-23T16:57:00.001-04:00

During vacation I read this article about statistics being the job of the future (also, refer to this talk by the chief economist at Google). I've posted a lot about statistics before (here, or here, or there for example), and I seem to use it a lot in my job, especially when dealing with large sets of data on a lot of DUTs. So that article naturally jogged my brain to recall a conversation I had last month with some other engineers at work.

The field of computational physics has existed for a long while - at least as long as relatively cheap computer time. The premise of comp. phys. is that many of today's physics problems don't lend themselves to elegant mathematical solutions. You have to apply numerical techniques to simulate, prove, or disprove a theory. When I was in grad school two decades ago I knew a post-doc whose entire job (at least while I knew her) seemed to consist of running Monte Carlo simulations on potential collision results at Fermilab: computational physics.

But let's go one step further. Decades ago one of my favorite books was the award winning Startide Rising by Dr. David Brin. One premise of the novel was that, while other alien races used brute force numerical calculations to figure out engineering, the upstart humans were pursuing solutions using mathematical proofs, theorems approximating effects, etc. Good stuff, but I suspect that the aliens are right. I predict that as science progresses, more and more discoveries will be made using powerful computational tools, not "elegant mathematical formulas."

I'm not sure how much that last, rather speculative paragraph has to do with test engineering. But if scientists can theorize about something, sooner or later it has to be tested. Until then it's just theory. And I think that testing will increasingly involve statistics.

2009 Salary Survey

2009-08-17T11:54:00.001-04:00

The 2009 TMW Salary Survey came out this month. I've written about their survey before, but it's always interesting to take a yearly peek into how everyone else is doing.

Interesting tidbit #1: The highest ranking for "New technology learned about in the last 2 years" was clearly RF Measurement (38%). I guess that makes sense when considering the prevalence of WIFI and Bluetooth devices.

Interesting tidbit #2: There is still no breakout of salaries by geographic area. Too bad.

Interesting tidbit #3: The highest paid group of engineers are those with 30+ years of experience, followed closely by the 20-24 years group and then the 25-29 group. To make sure this wasn't a fluke, I checked the 2008 and 2007 surveys as well - they had similar results.

What does that last tidbit mean? I considered that question for a while & ended up with two guesses:

Optimistic view: In some professions the older you are the less you are worth. In test engineering, the more experience you have the more valuable you are. The engineer's programming skills, knowledge of test circuitry, etc., do not go out of style or get stale.

Pessimistic view: Most engineers are forced out of the profession as they age. The ones that are left are the exceptional few with skills not easily replaced, so they can command higher salaries.

For obvious reasons, I prefer the former over the latter.

New test magazine

2009-07-30T21:08:00.001-04:00

Well, I said in my last post that I was going on vacation. But this post was already mostly written, so what the heck.

======================

Keithley is sponsoring a new magazine called Project Test. According to the press release, it is a "unique 32-page electronic magazine edited for test and measurement engineers." In my opinion, the jury is still out. It's obviously meant as a marketing tool - most of the articles in the first issue are written by Keithley employees and spotlight Keithley equipment. I'm not sure if that fits the press release though.

There's nothing inherently wrong with this sort of self-marking document, if it's done right. Hewlett Packard did a good job at this with their Journal this back before the split. The articles were usually written by HP engineers (sometimes in conjunction with marketing), and they often conveyed a great deal of solid technical detail. That is the standard I would hold Keithley to.

Getting LabVIEW certified

2009-07-22T17:44:00.000-04:00

Well, I've decided to get my Certified LabVIEW Developer (CLD)... certification? diploma? license? Regardless, I plan on shelling out the money and taking the test probably by the end of the year.

A couple of years ago I was ambivalent about certification. But I've modified my opinion for the following reasons. First, NI now offers a CLD renewal test, which was one of my original gripes. Second, the CLD test used to be one long test - half written and half practical - and it seemed like overkill to me. Now the written part is given as a separate test - Certified LabVIEW Associate Developer (CLAD) - and is often offered as a free test. Third, I took the CLAD a couple months back and passed it easily. I figure I'm halfway there already.

Finally, given the state of the economy I think it makes good sense to get recognition for my skills. Another engineer friend of mine just lost his job, and that sort of thing reminds you to be prepared in case you need to find another employer.

===================

Over the next few weeks I'll be taking some extended vacation time. I have at least one or two other posts partially written, but I may not get to them until late August or even September.

Test gear history

2009-07-18T11:37:00.001-04:00

I found this picture back in April and thought cool. It looked like it could come from a Hollywood period movie yet it was real. I noted the page for future reference and then forgot about it.

My current company is in a huge building that's over a century old. It was one of the first buildings in the world to use reinforced concrete, and it used to be the headquarters for the United Shoe Machinery Company. The halls are decorated with little mementoes of the company's past: poster-sized pictures 50 to 100 years old, historical vignettes of life in the company's heyday, old-style shoes, and equipment used on the manufacturing line. One day I stopped to stare at this display.

It's an old poteniometer used for equipment calibration. So I dug around online and found out that it was manufactured by Leeds & Northrup in Philadelphia - evidently they were quite the test and measurement company back in the day (see this or this).

I connected this piece of equipment with what I'd seen back in April and thought a lot about old test equipment, where it goes, and the history of the equipment and the people who make them. Does the equipment eventually sit on a shelf for decades before it is tossed (or sent to theSmithsonian)? Do the people who devote so much time & effort to create this equipment get any recognition (other than a brief summary on Wikipedia)? Normally I'm not a very reflective or pensive person. But sometimes you just have to think about these sorts of things.

LAVA flows once more

2009-07-03T14:30:00.000-04:00

The LAVA (Labview Advanced Virtual Architects) website is back up and running after a several month absense. While I don't read that forum on a regular basis, it is definitely a useful resource. Along with the NI-hosted forums and the Info-LabVIEW mailing list, it's part of the top three online resources for programming with LV.

I'm glad to see it's back up.

Two year anniversary

2009-07-01T22:04:00.000-04:00

So, it has now been about two years since my first post. When I recognized my one year anniversary, I noted that I'd posted on average once a week for a year. Well, I haven't been quite as prolific since then: only 32 posts. But still, considering the job changes the past year, that schedule is not too bad, considering I do this "just because."

There was an article a few weeks ago in the New York Times about blogs getting abandoned after people lose interest in maintaining them. It's an interesting piece, but I expect it's probably a retread article of what happened a decade ago when there was a rush of people creating their own webpages, and then they gave up on them. I know I did that at one time.

But two years... it's not abandoned yet.

Apple secrecy vs. collaborative transparency

2009-06-28T21:53:00.000-04:00

I wrote about a month ago about intranets & collaborative software. That post also referenced a Wired magazine article about companies becoming more transparent. Well, this past week the New York Times ran a tangential article this past week: the main thesis was that most companies are becoming more open, except Apple. It's a good read.

Tools every test engineer needs

2009-06-07T00:28:00.001-04:00

The May 2009 issue of Popular Mechanics has a very nice article listing the 50 tools every man needs and how to use them. I enjoyed reading the article, and certainly learned a few things - for example, WD-40 stands for "Water Displacement 40th attempt" since it took 40 tries to get the formula right. And this article started a train of thought.

What are the essential tools a test engineer needs? I'm not talking about industry-specific measurement equipment, but rather tools that span those industries. So I combed through the list of tools I've used at multiple companies, tools I commonly see in labs, and of course Google. I also included software packages as tools - that's part of how engineers roll in the 21st century.

So below I offer, in no particular order, my personal top list of tools every test engineer should have (or at least know how to use).

Digital Multimeter

The first that comes to mind is the DMM, the essential tool for troubleshooting electrical connections. My personal favorite is the standard Fluke model.

Leatherman

I'm surprised the Popular Mechanics article didn't list this as an honorable mention. I've already written about its usefulness.

Power Supply

A good utility power supply is essential to any lab. My personal favorite is the Keithley 2400.

Labview

You have to have some way to automate data acquisition and storage. I've used Visual Basic, C - heck, I've even used Fortran. But like it or not, Labview is designed to be used for test engineering, and it shows.

Statistics Package

Once you get the data, you need a way to analyze it: graphing beyond just the basic X-Y axes, SPC work, trending. A good spreadsheet package will get you most of the way there, but for more detailed work you may need something more like Matlab or Minitab. My personal favorite is JMP.

Oscilloscope

Almost as important a troubleshooting tool as the DMM, oscilloscopes were popularized by Tektronix. I still think they make the best ones.

Video Microscope

This one is obvious. Sometimes you need to zoom in and take a picture.

TEC & Thermister

I can't count the number of times I've had to use a TE cooler (sometimes coupled with a fan assembly) to adjust or control temperature of a DUT. They're easy to use, small, have no moving parts, and relatively maintenance free (unless you fry it).

Function Generator

Similar to the power supply, this is a tool a test lab has to have, or it's just not a test lab.

Well, there's my list. Feel free to suggest more if you want.

Startup: one year anniversary

2009-06-02T15:00:00.000-04:00

I've been with my current startup company for a year now. When I first joined, I posted about whether "startup specialist" was a specific subset of test engineering. I hedged on the answer to the question back then - today I'll claim yes. I'll try to explain why.

Here are the four skillsets I thought a test engineer at a startup needed:

1) software skills
2) general knowledge of mechanical and electrical engineering

3) data storage and analysis ability

4) people skills

Over the past decade I've worked in 4 engineering startups where I was the only (or first) test engineer. In the three startups before this latest one I used #1 & #4 always and #2 & #3 about a 1/3 of the time. But in this latest startup I've had to rely on all four extensively. For example:

I've learned more about databases in the past year than I ever thought I'd need to.
I've stretched out my knowledge of semiconductors quite a bit.
I have to write some form of code (whether it is LV or just scripting for data analysis) practically every week.

These are skills that I never exercised extensively as a test engineer in a bigger company. So, I think that proves my point.

LabVIEW Developer Education Day, 2009

2009-05-28T13:09:00.001-04:00

I attended the LabVIEW Developer Education Day last week in the Boston area. It was pretty good, although one of the presentations by a non-NI person was partly an advertisement for OpenG tools. That was okay with me, since I've used them in the past.

If you are interested, the presentation slides are here.

I know someone who has an Emmy

2009-05-21T11:19:00.000-04:00

I just found out this week that a friend of mine received an Emmy.

There's a loaded statement. But no, there was no red carpet stroll - just a certificate in the mail for work he did back in the mid 90s to support testing ATSC (Advanced Television Systems Committee) standards for HDTV. He had no idea it was coming until they contacted him right beforehand. Evidently it was part of the publicity push when HDTV was supposed to be released this past February.

But still, that's pretty cool. Congratulations, Chuck.

Intranets and collaborative software

2009-05-17T10:47:00.001-04:00

The post I wrote about HP/Agilent a couple weeks back started me thinking about what that experience was like. Then I recalled something that I had started writing well over a year ago. This is what resulted...

============================

When I worked at Hewlett Packard back in the late 90s, I was told that HP had the world's largest intranet. I'm not sure how true that is, although I did find this press release from 1996 where they make that claim. I do know that all groups in my division were expected to create and maintain an internal website. That website was in turn linked to department websites, division websites, etc. Employees could also create their own websites & link them to their group's website. I was the admin for my group's site.

It was a great tool for three specific reasons:

Information Repository - While I was there, our group started using the website as a convenient way to store information online. Plus, guess which is easier: a) Tell someone to go to your group's website, click on "documents", and download the test report; b) direct them to H:\Shared\public-files\bfg2000\documents\reports\new-test-report-v1.1.doc

Reasearch - This was back before Google was commonly used (although I was partly hired because my manager had found me online via Google), and Wikipedia wasn't even invented yet. There were search tools that HP had specifically for digging up info on it's intranet, and you could find a lot of technical information that way. I downloaded bits of code, internal specs, and other useful bits of info that HP employees had loaded onto the intranet.

Status Information - Testing schedules, group members, who is working on what project, milestone schedules. All these things were listed on our website. Managers could go there directly and get that information without bugging the engineers.

Flash forward several years. I read an interesting article in Wired magazine about company blogs and sharing information while on a plane flight to Denver. When I got back home I talked with my company's CEO about starting up an internal company website that would include blogs and other information from the various departments. I had some success - by partnering with our IT manager, we introduced Sharepoint to the company and got people to start using it.

At my current employer we use Sharepoint extensively, and it's a good tool for the three reasons I wrote above and then some. Other good reasons for having this sort of tool include a) it can be used as an inexpensive document revision tool, b) postings can start discussions about technical issues, and c) you can post general information (HR policies, company calendar, etc.) there.

I guess what I'm trying to say is this: if your company doesn't already use a tool like this, talk to your manager, director, or CEO about getting one.

Agilent and Hewlett Packard - So long, and thanks for all the fish

2009-05-08T13:41:00.001-04:00

Martin Rowe at Test & Measurement World wrote a nifty blog post about how younger people don't know that Agilent used to be HP. It generated quite a few comments.

Until I read that post, I didn't realize that it has been ten years since that happened. Officially, the split was completed on November 18, 1999, after the IPO. But for everyone working there, including myself, it happened on March 2nd of that year. I had heard a rumour that something like that was in the works, and some of the oldtimers there said that a split had been rumoured for several years.

I worked at the Santa Rosa, CA, facility on Fountaingrove Drive. It was a beautiful facility, and counting the manufacturing facility in nearby Rohnert Park, HP employed several thousand people there in Sonoma County. As I recall, the mood of nearly everyone I talked to was somber, and yet glad that they were going to be with the "real" HP - the test and measurement side. There was a LOT of pride there.

So, here's a (belated) happy 10th Anniversary to Agilent Technologies. I hope they have at least a dozen more of the same.

Atlas LHC - Very cool stuff

2009-04-26T10:18:00.002-04:00

As I've mentioned before, I cut my testing teeth in high energy physics. Once again, I'm cleaning out my in box and I found a great article in Evaluation Engineering about the Atlas Experiment for the Large Hadron Collider. It's chock-full of details about all the different measurements they do, and it sort of made me nostalgic for my grad school days - sort of.

At any rate, I'm pretty sure the massive detail the test engineers at Atlas have to deal with exceeds the difficulties Intel has when testing it's chips.

BTW, here's a funny cartoon that came out about the time the LHC went online. Perversely amusing: http://xkcd.com/401/

Sifting through my inbox - CAST

2009-04-23T12:40:00.001-04:00

So once again I'm going through my Inbox and sorting through months of miscellaneous emails. I came across this press release about the Collaborative Alliance for Semiconductor Test (CAST). here's the key quote:

CAST was formed in 2008 by semiconductor device makers and test industry suppliers to engage in, and resolve, common industry issues related to higher test equipment utilization, lower costs, and greater standardization and return on test-related R&D.

Sounded interesting, so I went to the website for the group. They had a little more information there, including slides from a meeting a couple weeks ago. The list of member companies includes mostly test equipment companies (no surprise there) and big users of semiconductor test equipment (i.e. - Intel).

I'm all in favor of things like standardization and lower costs, but these sorts of organizations tend to founder unless they are led (at least in the early days) by a strong leader. I wish them luck.

----------------------

After a month+ of not posting, I finally have a little more time to get back to the blog. I have at least three more items I'll be posting over the next week or so.

Test Engineer - the musical

2009-04-22T13:34:00.000-04:00

I haven't posted in a while - mostly due to tax season, a long project a son needed help with, and of course work keeps me busy. But here's a funny series of songs about testing. They were recorded by Martin Rowe, the senior technical editor at the Test & Measurement World magazine. Although acoustic blues aren't really to my musical taste, I really appreciated the sentiment.

Engineers in sales

2009-03-12T15:38:00.000-04:00

Almost two years ago I wrote about moving from testing into sales. In the February issue of Evaluation Engineering is a pretty good essay about this topic. In the article Malcolm Levy (the author) covers why an engineer might move into sales, what skills are needed in a sales role, and how to get started moving into that position.

-----------------

I've been clearing up some accumulated junk in my inbox again (magazines, app notes, newsletters), so I'll be posting at least a few more times this month.

Optimistic skepticism

2009-02-17T11:28:00.000-05:00

I've been deep into updating two separate test stations recently, and I almost repeated a mistake I made last fall: wanting the code to work so much that I willingly believed that a bug had just one source. Fortunately I dug deeper and found three separate sources of a single bad result.

For a couple of years in the late 90s I tested software for HP/Agilent. When you test software, the goal is to break it. You go to your job thinking, "What would a user of this software do that the programmer would not expect to happen, and will that behavior break the program?" It was a difficult gear change at first, but I think it made me a better programmer (that's the reason that many young programmers at Microsoft get their start testing code).

A primary goal of a programmer is to get his code to work. There's an indescribable, almost physical thrill you get when an algorithm you've invested so much time into comes together and performs. To subsequently try to break it is a literal buzzkill.

Test engineers, at least the ones who also write code for their systems, are sometimes stuck between opposing priorities. On the one hand, you enjoy building a new system that works. On the other, the system has to work all the time - the worst result from a test system is erroneous data that you think is correct - so you have to spend a good deal of time trying to break it.

It's a tough row to hoe, but that's just part of the job.

Adhering too tightly to the requirements

2009-02-11T14:49:00.000-05:00

I've been really busy at work the past month plus - but I'm employed, so my complaints are few.

Read this article and watch the video (also on youtube). The part that really troubled me was when the engineer says "this is just bad engineering" and the manager says:

That might be, but I can’t afford to worry about that. My job is to make sure the project follows this plan from start to finish.

There are two sad parts to this. First, that this was a real event that happened at NASA. Second, that I've seen some of this same behavior at big companies I've worked at before. The management adheres to the process, and all the documentation they have, even in the face of contradicting data.

As a test engineer, that is especially abhorrent to me: valid data is what I work to create for a living. For a manager to favor process over data is just wrong.

Still around after the storm

2008-12-30T14:50:00.001-05:00

It's been a busy month, personally and professionally. Aside from new hires and a reorg at work, on December 11th there was a huge ice storm in the New England area that knocked out my electricity for ten days. Luckily I got it back before Christmas - some people weren't as lucky.

Anyway, I have several more posts that I'll be getting up this winter. As I've said before, I usually flag emails/articles/etc. when I find something interesting to say. I'm about due for another clearing of the in-basket.

Shot of the woods near my house the day after the storm.

The power of repeated testing

2008-12-05T13:58:00.000-05:00

I know I've talked before about statistics in relation to test engineering (here or here for example). One thing I haven't really discussed is Gage R&R testing, but something personally happened to me this week that reminded me how useful that testing tool can be.

Where I live is close to the bottom of a hill within a subdivision. I have found, through repeated testing, that if I a) shift my Toyota Prius into neutral at a specific speed once I turn into the subdivision and b) follow the same path, then I can overcome the two small hills and coast all the way down to the end of my driveway. It's kind of a geeky thing to know, but I'm an engineer with a cool car built to do stuff like that.

Last week I got new tires. A day later I took the normal coast route but the car felt different - a little slower while coasting. I had shifted into neutral within a couple mph, the roads were not slippery so I didn't need to brake excessively for the curves, but it was definitely slower. So I called the shop &, as I suspected, they need to be balanced better.

This is a perfect example of why you should run a Gage R&R on your test system every once in a while. Like my regular "coast to the house" test, a regular test against a known standard will show you if there is something a little "off balance" with your system.

A good test engineer studies the details, part 3

2008-11-20T14:49:00.001-05:00

A couple of weeks ago I went on a camping trip up in the White Mountains of New Hampshire. I'm on the boy scout committee for my son's troop and one of the scout masters put together an overnight trip just for the committee adults. The plan was to hike up the side of a mountain, set up camp in an unheated cabin built back in the 30s (by the Civilian Conservation Corps, part of Roosevelt's New Deal), fix our own meals, then hike back down the next morning.

This is not something I've ever done before. I love to camp - we went on camping trips every year when I was young, and I take my kids on at least a couple trips every summer. But when I say "camping" the assumptions made are a) it's warm weather, b) I pack lots of stuff in the car, and c) it's at a state park or somewhere similarly well-organized. For this overnight trip we were each expected to hike a couple of miles uphill all the way while carrying our own food, a gallon of water, sleeping gear, and very warm clothes (forecast of ~20°F that night).

So I approached this almost like I would approach designing a new test: look at previous designs, step through the new test algorithm detail by detail, examine my constraints and design with them in mind, and finally buy the equipment I need. I started with the list I usually use for summer camping trips. I shopped around and bought a good internal frame backpack with plenty of room for a sleeping bag, clothing, water, etc. I did a preliminary pack of what I had to see how much room I had left. Then I went through a mental checklist of what could go wrong & what I would need if it did. Finally, I went out and bought the remainder of my equipment.

This level of detailed preparation paid off. My folding saw came in very handy cutting the wood we burned for heat that night. I stayed nice and toasty with my thermal underwear and sleeping bag (rated to 0°F). And my spare plastic baggies were invaluable in making the chocolate pudding we had for dessert.

The point I am trying to make here is that my attention to details meant that I had everything I needed to be comfortable on an arduous trip. Similarly, that level of detailed planning will usually insure that your test system will give you valid data as well as recover from difficult situations.

A good test engineer studies the details, part 2

2008-11-20T14:33:00.001-05:00

I've always been a big fan of PDAs. I bought a Casio Telememo watch as a "congratulations on graduating college" present for myself. It held up to 100 phone numbers plus it had calendar and memo functions. I was hooked. Since then I've had a host of such portable devices, including wring a program on my Hp48 calculator to hold contact info. My next device will be either the new Blackberry Storm or maybe an iPod touch.

I view such a device as a necessity for a test engineer. Sure, it can be a time-wasting toy at times, but I think there are 4 good reasons for using one:

Having a calculator with good scientific functions in you pocket is really handy when checking your test results.
I have often kept technical specs (often in PDF format) on my Palm - this can be a lot handier than looking it up online.
Writing down notes at any time in electronic form is very helpful when you have to refresh your memory 6 months later via a search function.
More so that other engineers, test engineers are mobile - commuting from your office to the test lab, meetings, customer's facility, remote site, etc. But sometimes a laptop is cumbersome, especially if you need to fit in tight spaces.

How does this fit in with my thesis that a good test engineer is detail-oriented? Referring to the reasons above, I would say that having a tool like this allows you to focus more on the details.

Chronological list of my PDAs (1989-2008)

Casio Timebank, HP48S, HP Jornada 680, HP Jornada 620, Palm TX

Testing Intel's latest chip

2008-11-17T10:23:00.000-05:00

It's not every day that your profession is spotlighted in the New York Times. It's even rarer that it is cast in a favorable light. And yet, today there is a nice piece about Intel's testing of their latest chip, codenamed Nehalim. The writer interviewed the guy in charge of product testing, and the article references the difficulty in designing the tests. Of course, they had to talk about the Pentium floating point bug (I certainly remember that one), but that was way back in 1994.

Anyway, I liked reading that article & I wish John Barton (the test chief) luck. Testing something of that magnitude has to be keeping him up nights.

A good test engineer studies the details, part 1

2008-11-13T10:05:00.000-05:00

Back about 14 years ago I created my first website. It had maybe a dozen different pages, talked about different interests, had a few jokes on it - the usual stuff that people were doing on the web way back then. In 1997 I decided to upgrade my computer & ran into all sorts of grief debugging it. Feeling the need to gripe about it afterwards (blogs weren't invented back then), I wrote a page about it and added it to my website.

I applied for a job at Hewlett Packard a year later. During the interview I found out that the hiring manager had looked me up online - Google was invented back then - and found my website & description of the upgrade. One of the reasons he brought me in for an interview was because he was impressed over how I had a) dug into the problem, b) tried out several different solutions, c) identified the problem (bad EIDE plug on the motherboard) and d) fixed it. It was that kind of attention to detail and problem solving skills he needed in a test engineer. I got the job, moved to California, worked there a couple of years, and loved it.

That website is long gone, but last week I dug around and found the original HTML files I had created. So, here's the complete page that helped me land the job:

=================================================================

The Upgrade From Heck

Early in 1997 I decided that my poor 486DX had seen its last. Fancying myself a clever fellow, I decided to upgrade on my own. I mail ordered a motherboard, Cyrix 686, 72pin memory, and a PCI video card, carefully shopping around to get the best price on each.

Tragedy struck. First, I found that the screwhole locations on motherboards are not standardized. Solution: epoxy plastic standoffs to my sturdy metal case. Then, the board would not recognize my hard drive. Here are the steps it took to fix this:

Played around with the BIOS settings. No luck.
Borrowed a brand new Western Digital drive from a friend. Still nada.
Called tech support, who returned my call several days later with no answer.
Borrowed a plug in IDE card from work that goes into an ISA slot. When I plugged the old hard drive into the card (rather than the built-into-the-motherboard EIDE plug), the computer did detect the drive.
Faxed all these steps in a long memo to tech support, who shipped out a new motherboard free of charge. Problem solved.

Below is a picture I took of my version of dual-processing. During the month I was working on this problem, I still wanted to work on my computer. So I would have to unplug the new board (bottom), plug in the old board (top), turn on the computer, change the BIOS settings, and go.

Okay, I'm done venting now.

Relieved

2008-11-05T06:50:00.000-05:00

Thank goodness it is, finally, November 5th.

A good test engineer studies the details (prologue)

2008-10-31T07:41:00.000-04:00

Different professions require different skillsets. To be good in that profession, it also helps to have certain character traits. I think that being a good test engineer requires attention to detail. Over the next week, I'll write about three different personal examples that I think illustrate this point.

Blog Action Day - Poverty

2008-10-15T07:53:00.001-04:00

Today, October 15, 2008, is Blog Action Day, and the subject is Poverty.

Growing up, my family was at the lower end of middle class, a couple steps up from being really poor. So I have always been strongly motivated to study hard, get a good job & have a good amount of cash. Partly because of that, I have historically believed that if you are focused then you can pull yourself up by your bootstraps. Not having lots of money doesn't prevent you from going to the library. You can take advantage of what the public schools teach you, provided you study hard. Loans and scholarships are available for college if you work for them. Don't get distracted by parties, games, TV, etc. while in school & you should be just fine.

That was how I felt until my senior year in college. That fall I participated in a mentoring program at a local elementary school. I was paired up with a 4th grade boy, David, who needed help with math. So once a week I would go to the school and we'd go through his math work for an hour or so after classes were over. Once or twice we just hung out and threw a baseball outside as well.

What did this have to do with why did my opinions change? I guess I just started realizing how being poor can handicap a kid. When I was working with David I realized that things my mom had helped me learn when I was his age, he hadn't had that option - his mom had to work a lot since his parents had been divorced. When I was a kid my parents had bought a set of children's encyclopedias (published by the Worldbook people), and I always had ready access to reading those at any time of the day. The library is only open at limited times, and when you're a kid you can't just hop in a car & drive there. Also, he was often hungry. I remember bringing snacks once to a study session - I had skipped lunch to study for a test - and he wolfed down the food in a heartbeat. It's kind of hard to focus on learning things when you're hungry.

Years later, I would think even more about David. He lived in a rural area, where the schools just weren't very good. The library was in the middle of town, so he couldn't get to it easily. He didn't have a lot of time to do school work after hours because he had a lot of chores. Then I related that to my dad. I'm pretty sure that if he had been born into a different part of the country, & his family had more money then he would've been an engineer of some sort. But he grew up in the woods of Kentucky, quit school when he was in 8th grade because he had to get a job, & bounced around from one factory job to another. Sure, he managed to become an electrician, but that came at great effort and not until he was well in his 30s.

There are other ways that being poor can make it tough. There is a strong link between nutrition and brain development. If a child doesn't get good food, his brain as well as the rest of his body suffer. If a child has to work a lot to help make ends meet, that means she can't spend time learning things she'll need to make her own life better as an adult. If you live in a geographical area that is dirt poor, then the public amenities like schools, libraries, etc. are probably either scant or nonexistent.

I think the point I'm trying to make is if your family is poor then sometimes there aren't any bootstraps worth pulling.

Testing very small stuff

2008-10-14T20:59:00.001-04:00

I was cleaning out my inbox (again) and started reading a recent issue of Evaluation Engineering. I realized that I had referenced articles from them before, did a search, and found three separate times (one, two, three). So the next box car in my train of thought ran, "I wonder what they say about nanotech testing?"

For the last 9 months or so I've been involved in testing devices that involve either MEM structures or nanoscale devices. This has required a certain evolution in my thinking. For example, a few years ago I had never thought I'd have to automate & analyze the data from an interferometer that imaged micro-scale shutters. I did just that this past spring.

I think the first time I was really aware of nanotechnology as a going concern was back around 1991 when I read Great Mambo Chicken and the Transhuman Condition. Of course, that book is somewhat out of date 18 years later, but at the time it was a great read - I still have my copy.

SO I've been reading more about testing at this level lately. Here's a few articles:

Imaging at the atomic level

Battery development & testing
Testing a nanotech system

Keithley has been particularly active in this area. Two years ago they introduced a nanotech testing blog. A couple of weeks ago I received a Nanotechnology Test & Measurement Resource Guide. Good for them.

After reading more details about nanotech testing over the past couple months, I've come up with two conclusions. One, I've barely scratched the surface. Two, nanotechnology is rapidly expanding, and I thnik the need for testing it will be key in the 21st century.

Congrats to the LHC

2008-09-20T08:41:00.001-04:00

In the early 1990s I was in grad school doing research for the Superconducting Super Collider (SSC). I worked at the Texas Accelerator Center, where the "first foot" of the SSC was built. Then I went to Fermilab, where I spent a couple years learning high energy physics and building a new type of calorimeter that would work at low-angle regions after the collision (where the radiation levels were particularly high).

Congress started reducing the funding for the project, then cut it entirely in 1993. My project lost its funding, and I escaped with my MS in Physics. For years I was bitter over that whole episode, but eventually I realized that my life would have turned out very differently, perhaps for the worse, if I had stayed with the SSC. Also, my experiences there - writing programs for data analysis, building a test system - started me down my current career path. I can't be bitter about that.

In the 15 years since then, I've lost track of the cutting edge of high energy physics, but I still try to read up on it once in a while. I was very excited on September 10th when they activated the Large Hadron Collider (the New York Times wrote a nice piece about it from a layman's perspective).

So, cheers to everyone involved with the LHC. When I was at Fermilab there was a sort of rivalry between us and CERN (where the LHC was being built), but I'm pleased that at least someone will be slamming protons into each other.

Structural mechanics kit

2008-09-17T18:47:00.001-04:00

Last month I received an email for a "complimentary copy" of an Introduction to Structural Mechanics Simulations CD. It comes from Comsol, a company that writes software for physical modeling. According to the email, the contents include tutorials on simulating:

- Static linear analysis

- Thermal stress

- Fluid-structure interaction

- Fatigue analysis

- Nonlinear materials

- Multiphysics user stories

- Tour of COMSOL Multiphysics

Now, I am in no way a mechanical engineer. One of my very first jobs was as an engineer in an aerospace firm, and yes I did do some analyses of stress levels, gear matching exercises, and other mechanical engineering 'grunt work'. But that job also taught me that if you dig into the details, then mechanical engineering is a serious discipline.

But, if any of you out there are interested in this, here's the website:

http://link.abpi.net/l.php?20080812COMSOL01

Optimizing LabVIEW

2008-09-16T11:32:00.000-04:00

Last month I attended a local NI-sponsored LabVIEW seminar. Usually I don't bother with those things. They are aimed at novice users and are usually frequented by consultants looking for new work. But our NI rep assured me that this one was aimed for experienced users. Since they were also serving free lunch, I figured it wouldn't hurt.

It was actually pretty good. The title was Advanced Performance Optimization in Labview, and the focus was improving programs using memory management. Because of the unique ways that LV treats data, there are some tricks to speed up your programs. I mean, if all you want to do is run an instrument and take data, these tips won't help. But if you're controlling half a dozen instruments and dealing with reams of data, then you probably need all the help you can get.

The presenter was a guy named Brian Powell. I listed his blog , Open Measurements, as a useful one this past summer. He obviously knows his work well.

Anyway, I have a PDF of the presentation (including his notes). If anyone wants it, email me and I'll forward it on to you.

Coming this fall

2008-08-31T13:36:00.000-04:00

With all the things going on this summer (new job, summer camps for the kids, big vacation trip), it has been over a month since my last post on here. In that time, I've had several ideas I've wanted to blog about. So I made a note/flag/task for it and kept working. I just got back from taking my kids on a 2400 mile trip (driving my Prius, which I love) to see some friends and family. That excursion marks the official end of my summer activities, so now I have more time for other things.

Here's a quick list of things I plan to write about over the next few months. In no particular order they are:

Testing small stuff
Intranets
LabVIEW v8.6
LabVIEW optimizations
Blog Action Day
Being organized
Contractors

Clearing my mailbox, pt 3: VB6

2008-07-19T22:14:00.000-04:00

I subscribe to various magazines online. Yes, the subscriptions are free, and yes most of those articles are written by the marketing arm of a company trying to peddle something. But sometimes you can still find interesting stuff.

One case in point is an article in the June edition of Evaluation Engineering. A marketing person from NI wrote a piece about life after VB6, since Microsoft is ending support for Visual Basic 6 at the end of this year. The question the author addressed was 'what do I need to know to upgrade from VB6 to VB.Net?' And I would say she did a credible job of covering the high points, as well as listing other references for further reading.

Back in 2000-2001 I programmed almost exclusively in VB6, with a smattering of C++ as well. When the time came to consider upgrading to VB.Net, the VP of engineering at my firm decided it was too expensive at the time. A contractor I worked with left after that - he felt that he needed to keep his skills current - and I started thinking about migrating back to LabVIEW. So this article had a personal historical interest for me.

Clearing my mailbox, pt 2: joys of dual monitors

2008-07-19T17:39:00.000-04:00

Someone forwarded an article to me from the New York Times about the productivity improvements using dual monitors. The article is a little dated (2006), but makes a valid point. But if you program in LabVIEW, once you go dual you'll never want to go back. The advantage to having the front panel on one screen and the block diagram on the other is huge in my opinion. I liked it so much at work, that I found a cheap monitor on craigslist so I could do it at home as well.

Of course, now I also feel a little like an evil genius in a secret lair....

Cleaning my mailbox - LabVIEW vs C

2008-07-19T16:09:00.000-04:00

My various email inboxes have been filling up with things I want to keep until I've had a chance to look at them. Today (Saturday) I had time to go over a couple.

National Instruments has a semi-monthly email newsletter where they publish details about new white papers, new products, etc. Some of the time it's just marketing and not useful, sometimes it's good. The article that made me keep this latest issue was about comparing LabVIEW with C. I was particularly interested in this white paper since I had blogged about this subject a year ago.

I judged this paper on two different levels. The first level is a marketing level: it's apparent goal is to convince C programmers that LabVIEW can do about anything that C can do for test engineering. Does it convince? Ehh, maybe. It certainly goes through a list of typical things that a C person may ask about. SO on that level I would give it good marks.

The second level I considered to be more philosophical: does it address why LabVIEW would be better than C, at least for test engineering? On this level it really falls flat. After I read it I couldn't come up with any single reason it gave me for why it would be preferable. But maybe I was asking too much.

One year anniversary, pt 2

2008-07-04T09:37:00.001-04:00

As I said in my last post, I've been writing to this blog for a full year now. One of the things I said in my first post was that I hadn't found any blogs about regular test engineering. One year later, I should put a caveat to that statement. There are some blogs about test engineering, but they are usually written by someone who either a) works at NI (or some other huge test engineering firm), b) gets paid to write about test engineering (i.e. - a magazine), or c) written by a consultant (and writing a blog is a form of advertising for a consultant). This blog is still one of a very few in test engineering written not for profit or for promoting myself. It's just because I want to.

Having said all that, here's a list of test and engineering blogs that I read from time to time (arranged alphabetically). Maybe you'll find them useful and/or entertaining. But be warned - most of them focus on LabVIEW usage.

The Automated Test Blog
http://automatedtestblog.com/
A director of marketing at NI posts here once a month or so.

Blogs on Test & Measurement World
http://www.tmworld.com/blogs.html
This page is for a group of blogs written by people at that magazine, rather than a single blog. But it's useful to look at the summaries on this one page. These are often worth a quick read.

Expression Flow
http://expressionflow.com/
This LabVIEW programming blog has several different consultants posting to it from time to time.

Ideas in Wiring
http://ideasinwiring.blogspot.com/
The author workss at NI, but the blog is more of an independent piece.

Open Measurements
http://openmeas.blogspot.com/
Brian Powell is a senior R&D guy at NI. I've attended talks he's given before, & he seems like a great guy. As to be expected, his blog is specifically about LabVIEW.

Testing with NI
http://nitesting.blogspot.com/
Another test engineer writing a blog on his own. Good for him.

Thinking In G
http://thinkinging.com/
This blog is ran by Jim Kring, who co-wrote the great LabVIEW for Everyone book. He runs a consultant company.

VI Shots
http://vishots.com/
This is written by a pretty active consultant, Michael Aivaliotis. I see his name pop up quite a bit in LabVIEW circles.

One year anniversary, part 1

2008-06-30T10:48:00.001-04:00

It was a year ago tomorrow that I wrote my first post to this blog. Technically, I created this blog a few days before that, and I started thinking about creating the blog several months before. But the first post sounds like a good enough date to use. In that year I've written 66 times - a little over one a week is about what I had originally aimed for, so I'm happy with that.

Anyway, I wanted to formally mark the occasion of one year. Note in the header that this is "part 1" - I'll write a related post tomorrow (or the day after at the latest).

Boston testing is hiring

2008-06-29T08:14:00.000-04:00

I touched on this over a month ago when I talked about moving to my new job. But it really bears repeating: there are plenty of test jobs available in the greater Boston/north of Boston area. Over the past 5 to 6 months I have averaged at least a call a week from a recruiter - just this past week I had four. And I'm not counting the emails I get from recruiters.

Now, I could be full of myself and say that I get all this attention because I'm just a great guy... But in reality, recruiters are looking for specific skill sets. For most contacts I've had, they want someone with a) several years experience as a test engineer, b) good knowledge of LabVIEW, c) some sort of engineering education, and d) live in the area (relocation is expensive right now). So, if you fit that criteria, come to the Boston area and you'll get an interview.

What do I base this observation on? First, the two companies I have left in the last 6 months are still trying to fill my old position. Second, over the last two weeks I've asked several recruiters if the test engineering field is busy. They have all replied that the market is tight and they are having troubles filling the open reqs. So, there you go.

Test Engineer Humor

2008-06-10T10:13:00.000-04:00

While looking for software drivers I came across this page at Cal-Bay Systems.

I cracked up, especially at the shot of the PXI chassis with a tap in the middle. And the "BXI Chug 'n Play" standard in the specifications page was even better. It struck just the right tone to mimic a NI press release.

This is a great example of humor developed by a test engineer: obvious reference to the industry, plenty of spec details, and playful.

Test engineering in a startup

2008-05-26T17:54:00.000-04:00

As I wrote a couple of weeks ago, I start work with a new company this week. This will be my fourth startup in the past 9 years. About a month ago I wrote something I had learned about funding startups, and that post got me to thinking about what I wrote last year about the different types of test engineering. Specifically, is a test engineer who works in high-tech startup companies a separate type of test engineer?

A successful test engineer in a startup needs a broad set of skills. First of all, you're probably the only test engineer in the company, so of course you need to program. At first you can set up some rudimentary manual test stations, but soon after that you'll want to automate. People won't have the patience to sit and run a manual station for very long.

You're putting together test systems, but in a startup time is often at a premium so you'll usually hire contractors for specialized assistance. Knowing something about mechanical as well as electrical engineering will help when working with those contractors.

Furthermore, a high tech startup has a strong need for data. The test engineer that knows how to handle a database - writing to it, reading from it, designing it - has a leg up. And if you can do decent data analysis (I blogged about JMP here), then you help out the other engineers as well as have some fun.

Finally, you have to be a bit of a people person. You're in a small group of people, most of them are engineers. Those engineers rely on the data from testing. You cannot just sit in your cube and program, or sit in the lab and build your systems. You should communicate with the engineers to find out what kind of testing they need, how the data should look, and a dozen other issues. Things can change fast in a startup, so the test requirements drawn up a month ago might have changed. You need to stay on top of those changes.

The skills I have described are of course used by test engineers. But it is the breadth of skills rather than the expertise in any particular skill that is important for a young company. So, back to my original question: Is "startup specialist" a separate type of test engineer, or is this more of a 'jack of all trades master of none' issue?

I don't have an answer to that question right now, but I'll think about it more. But there is one thing I can add. Since I've started making a career for myself by having a broad set of skills, I've never really liked the negative connotation of the "'jack of all trades" epithet. In reality, the full quote is, "Jack of all trades, master of none, though ofttimes better than master of one." When you think about it, that's a compliment that I can live with.

Working at Google

2008-05-24T23:23:00.000-04:00

I wrote in December about a friend I worked with who is a statistics master. Well, back a couple of months ago he left that company. He traveled across the country to work at Google.

Now, there are a hundred things I can easily think of that Google would do that involve statistics. So I'm sure he will not lack for work, and I believe that Google is lucky to have him. So, Bhairav, I wish you all the luck in the world out there on the west coast.

The Power of Complaining

2008-05-19T11:30:00.001-04:00

Complain (Verb) - To express feelings of pain, dissatisfaction, or resentment

About three years ago I went to the yearly National Instruments Technical Symposium. Held every fall in Massachusettes, it is a mix of companies selling things (roughly 20 booths), programmers getting in touch with each other, and NI showcasing the newest updates to LabVIEW that they promoted at NI Week the previous August.

Well, three years ago I was disgusted with the state of the symposium's presentations. Without fail, all the presentations had a high percentage of marketing and a low percentage of actual technical content. And the technical content seemed to be pitched at either a) a beginner's level or b) extolling the great new things that had been added to LabVIEW (in other words, more marketing).

Most of the seminars and conventions I've attended over the years have a comment/rating sheet where you can grade your experience. Usually I check off a few things, write one or two sentences on what I liked, and that's it. This time, I roasted them. I wrote what I really thought of the day's events, and it wasn't pretty. I went into graphical detail of each talk I attended and why I felt it sucked. I also wrote that other people I had talked with had a similar opinion.

It must've hit a nerve. I received a call from a NI marketing guy in Austin a couple of weeks later. He wanted to talk in more detail about what I disliked (his wording - mine was stronger) and felt should've been done differently. The next time I talked with the local NI rep he mentioned that he had heard about my comments.

Well, over the last couple of years the LabVIEW symposiums I attended definitely had more technical content. A couple of weeks ago I attended the LabVIEW Developer Education Seminar. It's similar in spirit to the technical symposium but without the booths. And I have to say that this time NI did a great job of presenting good technical content. Every seminar I attended had solid information that I can use. Even better, there are actual notes with the presentation materials. I may have to keep that booklet.

So sometimes it pays to complain.

Moving yet again

2008-05-08T14:09:00.000-04:00

Back in January I wrote that I was moving to a new job. Well, about four months later, I'm doing it again. I start another job by the end of the month.

Supposedly the US economy is in a recession, but it hasn't hit the Boston area that hard - probably because most jobs lost have been in real estate and finance while this area is a hotbed for technology. If I had to guess, I'd say the engines of scholastic research (MIT, Harvard, UMass, Tufts, etc) combine with heavy military tech work (BAE, Raytheon, MIT Lincoln Lab) and a puritanical tradition of hard work to constantly churn up new applied science. That's partly why this will be my 4th start up company in the greater Boston area.

That, plus I'm a sucker for new tech.

Anyway, the same caveat that applied in January applies now. For the next month or so I don't expect to write much to this blog since I will be learning the new company. But after that, I'm sure I'll have more to say - I am rarely at a lack of words.

The right tool for the job

2008-05-08T13:49:00.000-04:00

My dad was an electrician and something of a general purpose handyman. He had tools everywhere - from the shed to the basement to a fully-stocked work van. One of the many things I learned from him is that any job you do is a lot easier if you have the right tool. To that end he had a lot of different kinds of tools. As a kid and then a teenager (when I used to help him on weekends and the summer) it amazed me how inventive the people who designed those tools were.

I started carrying a pocketknife when I was about 12 or 13 years old, probably because it was a useful tool. I bought my first swiss army knife in college and loved it. I always used it. Knife, screwdriver, bottle opener, even a little saw - what else could an engineer-in-training want?

I found that answer when I bought my first Leatherman tool. In the last dozen years I've used that tool all across the country in clean rooms, trade shows, customer visits, and even at parties opening beer bottles. I still have it, I still use it, and any young engineers I encounter eventually hear that they should buy their own (and stop using mine).

So the other day I pulled it out to adjust a screw on a cabinet and wondered how long these tools had been around. It has been an essential tool in my career for a long time, but how much longer had they been around? Turns out that 2008 is the Leatherman tool's 25th anniversary. So this is my official toast to 25 years of the right tool for many jobs.

Practice Makes Perfect

2008-05-05T10:42:00.000-04:00

I have always told my kids that the only way to really be good at something is to practice. You could be a gifted athelete, a natural genius, or a musical prodigy. But that natural talent can only take you so far. History is full of genius that disappointed as well as overachievers who thrived. As the band Rush put it:

You won't get wise
With the sleep still in your eyes
No matter what
Your dreams might be

Engineering can be the same way. During the last 10 to 12 months at my previous company my job mostly consisted of a) training new people, b) building and qualifying copies of existing test stations, and c) maintaining those existing stations. There was nothing inherently wrong with this activity. It needed to be done, and I was the only test engineer to do it. But that meant that my LabVIEW programming skills atrophied. Well, maybe not atrophied, but they certainly were not improved.

I've now been at my current company for close to 4 months, and it has been heavy on the programming. As a result, I have had to stretch out my skills. I've read up on certain programming techniques, played around with new ways to present data, and some of the algorithms I've developed are among the most complicated of my career.

I'll pat my own back a little and say that I'm really happy with some of this work. I've created new data structures I really like. I'm working with some aspects of LV code I haven't used before. I've improved my LV knowledge in a small but noticeable fashion.

It almost makes me want to go back and rewrite test code I did a couple of years ago. Almost.