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.

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

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.

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.

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)

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.

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

Yet more salary surveys

Every so often I like to look at salary surveys.  On average I have changed jobs about every two years over the past two decades.  So surveys come in handy.  Here's a couple that I came across recently.

Dr. Dobbs Developer Salary Survey

This is a pretty good survey from a respected name in software.  Not really my cup of tea, but I program often enough to find it interesting.

Design News 2014 Salaries for 10 Engineering Disciplines
I check Design News a few times a week.  Usually they post/repost interesting items.  But this survey is really more of a overview of salary ranges.  There's no commentary about regions of the country, years of experience, etc.  I suppose it might be useful if you were a parent talking to your kid about how much they might make as a n engineer.  I'm in that situation for at least the next few years, so that's why I looked at it.

Yet another company

A dozen years ago the biggest risk of a startup smacked me upside the head: the company ran out of money and closed it's doors.  Since that first experience in the high-tech* startup world, I've worked at a half-dozen or so other such companies.  Over half of them are no longer in existence.

I have accepted that, but I was never happy with it.  This past summer things went downhill with my latest company.  Within a month I had offers from three companies: a temporary contract gig at a mid-sized company, a large fortune 500 type, and another startup.  Sometimes it is good to mix it up, so I decided to ride with the behemoth.  I've been here two months now - we'll see how it goes.


--------------------------------
* My definition of a "high-tech" startup includes actual hardware.  I'm sure a lot of smart people work at companies developing new apps for smartphones, algorithms for web-hosted databases, or some other clever software tool.  But unless it involves some newly-discovered applications of physics/chemistry/biology, it doesn't meet my criteria. That's just my bias.

PXI work

So I found this link on EDN about PXI systems last year when I was doing some research for a new project.  I was going through old notes this weekend & cleaning up some files when I found it.  I'm not quite sure anymore why I saved it.  Maybe it's because the author mentioned hybrid slots?  I bookmarked the link last year when I was shopping for a PXI chassis for a new test system, but that's as far as memory takes me.

Anyway, I started thinking about PXI-related issues again this past week, and stumbling across this link reminded me of the experience I had selecting the hardware last fall.  After I had determined how the the test system would work, I made a list of all the hardware I needed: DMM, power supply, multiplexer switches, and relays.  It was too much for a cDAQ to handle (as much as I liked the concept), so I started shopping PXI companies.

I priced out what I needed from four different vendors.  At a startup company you try to keep the costs low, so I spent over week justifying the cost for the system.  If the test system would cost $10k or more, I had to show the legwork to minimize that cost.  Of course the expense of someone like me - getting paid what I was paid - digging around to save a grand or less didn't make much sense.  But so it goes.

I ended up buying the PXI gear from NI, and the test system worked.  And the one thing I got out of that week I spent shopping PXI prices?  There wasn't much difference between the vendors.  Originally I tried to shy away from NI since I assumed their stuff would be pricey.  But in the end it was barely more expensive than what I could get from the other three companies.  Learn something new every day, I suppose.

My experience with Labview OOP

About a year ago I started working at a new company.  One of my first tasks was to automated  functional testing for a robotics controller.  When I started we were shipping individual units out for sampling, and I had to test them by hand.  That took about 3-4 hours (including setup time and recording all the data), and we didn't cover all the testing we should be doing.  So my goals for the project were to:

1. Reduce the time down to ~15 minutes
2. Automate it so a technician could easily run it
3. Run additional tests that couldn't be done by hand
4. Save all the data to a database

Once I mapped out the program requirements and logical flow, I decided to make this my first foray into object-oriented Labview.

I had taken a class in LVOOP years ago, and I had read how-to's and  case studies with OOP in Labview, but I had never used it for a work-related project.  There were several reasons I used.

• I was re-engineering a program written by a previous engineer so I had to stick with pre-existing logic.
• I was writing small VIs for a larger TestStand implementation
• My programming partners didn't know LVOOP at all.  

Plus I may have been a little intimidated by the whole idea of an unknown architecture.  So I stuck with the standards: state machines, producer-consumers, and event-driven programs.

But now I had no excuses.   It was a brand new project, I was the only one working on it, and the project's complexity cried out for a sophisticated solution.  This was the perfect time.

And you know what?  It wasn't hard at all.  Maybe it was the OO programming I had done before in VB and C++, but the implementation went smoothly.  The only Labview-related glitch I had was early in the project when I tried to update a VI class member, but I worked it out.  And those classes I wrote for that project ended up being very reusable for two other projects I developed later on.  Excellent.

Fortran

So I read this interesting little tidbit about an ancient language that I used for my grad school work at Fermilab.  Kind of neat.

Noncompete agreements and who owns experience

In Massachusetts, the governor is proposing to ban noncompete agreements.  Go Deval!

My first experience with such agreements stretches back to 1996.  This tech company wanted to hire me, but one of their conditions was I sign a piece of paper stating that if I left the company I couldn't work for any other place doing similar work for a couple of years.  When I first read that I was thrown for a loop and almost turned down the offer.  But then I talked to a friend in law that said those things were hard to enforce - such docs were used more for scare tactics in the tech industry.

Why would a company want to use intimidation tactics to keep their employees from jumping ship?  I can understand not wanting someone to go to a competitor with trade secrets, but there are already some laws in place to prevent that.  But wouldn't a more positive solution be make working there too good to quit?  When I worked at Hewlett Packard in the late 90s they called it "golden handcuffs."  All the perks of working at HP just made it too depressing to leave for some other company.

Another thing that comes to mind is that the company using a noncompete agreement is being hypocritical about experience.  When they look to hire someone, they prize that person's experience in the industry.  But then they turn around and damn someone who wants to take the experience they've acquired to a different company.  That really irks me.  Any experience I've gained in the course of my job (writing programs, building test systems, going to conferences, etc.) is MINE.  The company pays me for the work I do, and they own the product of that work.  They do NOT own the knowledge that I've gained in the process.  That knowledge and experience I've gained by being a good engineer and deliberately learning new things.

On a related subject, you could always watch that bad Ben Affleck movie Paycheck.  Then again, maybe not.

Job satisfaction

As my children have grown older, I've tried to describe to them two important things about the working world: doing a job the right way, and the hard-to-define satisfaction you can get from a job well done.  I had the perfect example described to me this past weekend.

My wife teaches at a local high school, and the hockey team made it to the state championship game.  To show our support, we attended the game.  At the game I bumped into Gus, whom I used to work with at a startup company I left back in 2011.  His company runs the IT support for that company, and I worked with him to implement the database I developed as well as my test systems and analysis software.  We talked some about how the company was doing, and Gus mentioned that the database, the test systems that write to that database, and the programs that pull and analyze that data are all still actively used by the company.

Now THAT is a really nice feeling.  I must've done something right.

National Engineers Week

In case anyone missed it:

http://www.nspe.org/resources/partners-and-state-societies/national-engineers-week?espuid=CNATL000004129555