Monday, January 12, 2015

LabVIEW thoughts, part 2

I stated in my previous post that I wanted to write a series about LabVIEW.  Today I want to write about a project I'm just wrapping up that dovetails with a recent NI  article, Top 5 LabVIEW Rookie Mistakes.

Here are the mistakes NI lists:

  1. Overusing Flat Sequence Structures 
  2. Misusing Local Variables
  3. Ignoring Code Modularity
  4. Creating Massive Block Diagrams
  5. Disregarding the Need for Documentation
As I wrote last time, for the past couple months I've been working on a LabVIEW project.  It's a high visibility test system that was originally built well over a decade ago and then went through an upgrade some years later.  For several reasons it needed to be updated again.  I have now wrapped up the major code rewrites, and once I resolve the remaining hardware issue I'll turn the system over to other engineers for debug work.  

To be fair, the system worked.  It's hard to fault the engineers whose work produced a functional test system of such complexity.  Having said that, I need to add that the original code hit EVERY SINGLE ONE of the items on that NI list.  In fact, I would add at least a couple more:

  • Using GUI objects as data holders.  Do NOT place a numeric control on the front panel, make it hidden, and then use it as a quasi-global variable.  Just say no.
  • Lack of knowledge about functional global variables.  Oodles of information about them exists on the NI website, there are templates for them, and they don't break the dataflow paradigm.  Just do it.

Sunday, December 7, 2014

LabVIEW thoughts, part 1

My last couple posts of the year will be about LabVIEW.  In fact, my first couple posts of the new year will be as well.  I guess I have three reasons to do this.

LabVIEW is all over
This blog is not meant to be LabVIEW-specific.  I've said this all before but it bears repeating:

  • I am not nor have I ever been an NI employee.  
  • I have never worked for a test engineering house that has a tight NI-LV connection (well, I once considered it).  
  • I'm just a test engineer.

However, LV has a huge presence in the test engineering field, and I am a good example of that:

  1. Even though I've done a fair amount of programming in VB and C++, historically I still do most of my work in LV.  
  2. I've been a certified LabVIEW developer going on 5 years now.  
  3. Of the 200 or so posts I've written over the past seven years, about 25% were about LV in some way.

Recent projects
Over the past two months I've been heavily invested in a LV project at my new company.  Last spring I wrapped up my first big LabVIEW-OOP project.  Before I was laid off, I had just finished a LV tool for writing and reading build data for the manufacturing floor.  All this LV-specific work has got me to thinking about things.

New environment
With my latest company I experience something that I've seldom had in the world of startups:  colleagues.  I sit in a cubicle area with four other test engineers in easy talking distance.  A dozen more sit within a 30 second stroll.  That level of interaction has gotten me to think about LabVIEW in different ways.

Anyway, I'll write at least one more post on this topic before the year is out, maybe two.  But it's Christmas, so things can get busy.

Sunday, November 30, 2014

Interviewing tips for newbies

I've changed jobs about a dozen times (so far) in my career, and I've been on the other side of the coin many times as well.  So I think I've gained some insights into the interview process.  The last time I posted something on this topic was June of last year (and a follow-up as well).   So this topic came to mind when something else happened a couple weeks ago.

My udergrad alam-mater contacted me about a new alumni mentoring initiative they had started.  This is certainly nothing new - many colleges do it - nor was I special in being contacted.  I added my name to the list and filled out the online data form, and then I started thinking about what the heck I would actually tell someone if they contacted me.

One of the most intimidating aspects of getting a new job after college (at least for me) was the first job interview.  So here's a few things I jotted down.
  1. Check out the company.  This should eb obvious nowadays.  Check out the company website.  Then dig deeper: what division would you work for, what do they make, who are their competitors, etc.
  2. Check out the interviewers.   Look at their LinkedIn profiles.  Look at any papers they've published.  Who do they report to?
  3. Review the technology.  If you're not that familiar with the industry, spend a couple days and get familiar.  Download a PDF primer, read about it on wikipedia, whatever.
  4. Consider what you'll be testing.   (This one is very specific to test engineering, but that's what I do.)     Find out what you'd be testing and spend some time thinking about how you would test it.  I guarantee you will be asked questions relating to that topic. 
If I do ever get contacted, maybe I'll write about the actual experience.

Sunday, November 23, 2014

What comes after accelerators

A couple of weeks ago I wrote about my penchant for storing away articles I come across.  I've also talked many times about my continued interest (here or there, for example) in high energy physics.  It's been two decades since I left grad school, but I still have to credit my background in particle physics for my test engineering career.

A few days ago I came across a piece I had stored away from back in July about what might come after accelerators.  The author, Dr. Victor Stenger, pointed out that while ever more powerful accelerators may not be on anyone's radar right now, there are numerous other tests to expand our knowledge of the universe.

So I then looked up Dr. Stenger and found out he died back in August.  Depressing, but it looked like he lived a good life.  So I downloaded his last book God and the Multiverse and started reading it.  I'm only a chapter or so into it, but it's fascinating.

Sunday, November 16, 2014

Black Friday flashback

I know Black Friday is still two weeks away, but can you imagine getting this as a Christmas present back in the day?

Interestingly enough, back in 2009 one of these sold for $4150 on eBay.

The geekiest part for me is the cloud chamber.  I remember reading about Wilson's work and playing with simplified cloud chambers back in undergrad.    Cool.

Sunday, November 9, 2014

Reasons to test

I tend to be a packrat for interesting articles.  I'll come across something interesting, open the page, and then move on.  Consequently, I'll pile up 20, 30 or more open links on Chrome for iPad until I finally break down and binge read.

Today is a lazy Sunday morning, so I binged.  One of those stored links dated to way back in July about reasons to test.  It's a nice little summary of four canonical test types.  However, it missed at least two test reasons that are specific to volume manufacturing: binning and SPC.

Suppose your company makes thousands of widgets that have variations in a key parameter.  You therefore have two choices: spend time and money reducing that variation to acceptable limits, or find customers that desire those variations.  If you opt for the second one you spend time and money to implement the testing for that parameter, and you use the test results to put the parts into different categories for different customers.  That's binning.

I'm not going to try to describe statistical process control (SPC).  I've taken a couple of small courses in in it, and I've applied it to manufacturing testing at a couple of different companies.  But I'm no expert.  Go here for a good summary, and follow the external references for more detail.  All I will say is:

  1. SPC is a requirement for high volume manufacturing.  
  2. You need lots of data for SPC.
  3. You have to test to get that data.

So why did the article's author leave out these items?  I can think of three reasons.  First, maybe he thought they fell under the verification or validation categories.  I could maybe buy the verification for SPC argument, but that's as far as I would go.  Second, his testing experience is in low-volume industries (i.e. - certain military markets) where SPC or binning isn't useful.  Third, he just wrote the article quickly to meet a deadline without thinking it through.

That last reason is a little harsh.  But this lazy Sunday morning is also kind of cold and overcast, so I'm a little morose.

(the internets love cats)

Monday, November 3, 2014

Matlab improvements

I went to a Matlab seminar a couple of weeks ago,  Actually, I thought that I would mostly hear about RF and microwave testing using Keysight (the company formerly known as Agilent) test equipment.  I knew they would throw in a little Matlab, especially since Keysight and MathWorks have becomes  BFFs (here or there).

I realized early in the day that it was shaping up to be a majority Matlab experience.  So I decided to roll with it and listen - besides which, I also scored a coffee mug.

Displaying 20141103_094533.jpg

My experience with mathematical software like Matlab is complicated.  Back in grad school I test drove  an early version of Maple, and I used MathCad to make some nifty models for my thesis.  But in the working world Matlab and Labview tend to conflict more than complement - google Matlab versus Labview to see what I mean.

I had used Matlab at several different companies the past decade and viewed it as a great tool if you're a researcher trying to put something together.  But when you have to get something to test shippable product, go with the more professional Labview.

That opinion was shaken up a bit with what I saw in the seminar.  The last version I used was Matlab 2007.  The latest version (2014) has quite a few new tools.  I'm not going to make this a Matlab commercial, but here's what caught my eye:
  • Better debug support
  • Source code control
  • More tools fork converting what you just did into m-script or functions.
  • OOP support
  • Data highlighting tools
Of course, none of this means that I'll drop Labview and migrate to Matlab.  But the experience was an eye-opener...