Getting LabVIEW certified

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

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

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

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

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

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

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.