LabVIEW thoughts, part 5: A Little-Known Language

A couple of weeks ago I commented on an article about "little-known" programming languages and how it didn't mention LabVIEW at all.  Well, Dice posted a follow-up article of sorts on whether someone should learn a little-known language.  Again, LabVIEW is not mentioned.

But I've come to the opinion that it doesn't really matter, for two main reasons.

First, my impression of Dice is a site geared towards pure programmers.  Yes, I like to read specific articles on the site that appeal to my interests, but the majority of their content deals with web-based programming, games, and database/big data concerns.  LabVIEW isn't designed for that.

Second, knowing LabVIEW on its own is too limiting.  LabVIEW is a language, but it is language optimized for specific applications.  Sure, you can write pure database applications with it - I have - or you could write web apps with it.  But if you know LabVIEW and you are an electrical engineer, manufacturing engineer, etc. - then you are an order of magnitude more valuable to a company than if you just know LabVIEW.

Maybe that's why as a language it doesn't get much love from regular programmers.  They recognize that it is as much a tool as a language, so they just skip right past it.  But as my undergrad physics professor told me, it's always good to learn more methods on how to solve problems.  If the only tool you have is a hammer, then every problem looks like a nail.

LabVIEW thoughts, part 4

Back in December I said that I would write a series of posts about LabVIEW.  This is the fourth post, and now I want to talk a little about the nature of LabVIEW.  Let's start with this post I found from January, Little-Known Programming Languages That Pay.

Labview isn't listed in the article, not even in the "Math and Science Languages" section of the article.  Under that heading, the author instead lists an open source language that's compatible with Matlab.

And yet LabVIEW is used all over the high-tech industry - I've certainly made a living out of that fact.  Next post I'll explain the way I think LabVIEW is perceived, and why.  

LabVIEW thoughts, part 3-a (addendum)

A few days ago I wrote a post about LabVIEW versioning problems (again).  Here's something that I forgot to include in that rant:

To be fair, NI did help me resolve the problem.  I had to talk with a half-dozen people before it was fixed, but still.  Of those numerous people I talked with, one confidentially shared with me an interesting observation.  He (or she) said that this was far from the first versioning issue he'd dealt with, and it all went back to an NI philosophy: they don't go out of their way to support older hardware/software.  They would much rather you just upgrade to the latest versions.

This is fine if you're a small company buying equipment for the first time.  But for a big corporation (like I work for now) that is trying to maintain older systems, it's is difficult.

I'm guessing that this is partly why LabVIEW sometimes has such a bad rep.

LabVIEW thoughts, part 3 (the bitter edition)

I said back in December that I would write a series of posts about LabVIEW.  In this third post in the series, I want to talk a little about LabVIEW versioning hell.

This is not a new topic with me (look here or there).  LabVIEW version issues bit me again at work, only this time it was related to old hardware.  The problem stretched out for a month - from mid-December until I finally fixed it in January - but here's the crux of it:

1. I had an older PXI chassis with a new RT computer.
2. I couldn't get triggering to work on a couple of DAQ cards.
3. The triggering didn't work because the newer version of the PXI software (on the new RT) didn't support the old PXI.
4. The newer LV for RT code didn't support the older PXI software that I needed.

To resolve this, I had to completely wipe the RT computer (several times, but that's a different story), re-install an older LV version, and then downgrade my LV code (with all the headaches that entailed).  In other words, WEEKS of effort.

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

Not convinced that LabVIEW has a versioning problem?  Take a look at these convoluted eye charts, all directly from the NI website:

• DAQmx and LabVIEW Version Compatibility
• NI-VISA and LabVIEW Version Compatibility
• NI-RIO and LabVIEW Version Compatibility
• How to Upgrade or Revert a VI to a Different Version of LabVIEW

Sometimes I think NI expects customers to just sit and take it, like obedient pets...

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.

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.

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

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.

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.

Labview versioning hell, pt 2

Back in July I wanted to look at some fairly old code I had stumbled across - in the past I've had to do this a time or three.  This code was too old to up-convert with the version of LV I had, and I didn't have access to any older versions of LV.  While I worked on posting the code online to ask someone to convert it for me, I posted a suggestion to the LabVIEW Idea Exchange.

Basically, I was asking for a way to at least view very old code, and maybe include reasons for why it couldn't be up-converted.  The response I got was, basically, "If you are an SSP member you can download older LV versions.  If you don't pay to keep up your SSP, you're SOL."

Needless to say, I found that less than satisfying.  First of all, why would I want to spend the time and effort to download and keep track of older versions of Labview?  Second, it sounds like just another way to have owners of the LV software to continually pay money to NI...

Test your code

So at my new company I'm back to software testing.  What goes around comes around I suppose - I first learned the ins and outs of software testing at HP about 15 years ago.  Even though most of my jobs have been hardware testing since then, I still enjoy reading about it (i.e. - here, there, and way back then).  As my dad has said many times, it never hurts to learn something new.

Speaking of which, I recently found two articles about the costs of NOT testing your software that I enjoyed, in a perverse sort of way.  The first article is a bit esoteric unless you've done serious code testing before.  Basically, it explains how Kaspersky released an update to software that wasn't regression-tested.  In other words they made changes to the software, and, while they may have tested their changes, they didn't test whether those changes would mess up the base code.  That's the whole point of a regression test suite.

The second article is of somewhat more personal importance.  For a long time I owned only Toyota cars.  But once I started reading about braking problems back in 2009, I decided to buy Ford instead (here and here).  This past October a court finally ruled against Toyota, and central to the case was the Engine Control Module's firmware.

Will companies forever keep neglecting software testing in favor of releasing product ASAP?  I mean, just reading a paper like this from NASA and anyone with half a brain should realize that software testing is of paramount importance.  Jeez.

Test Executives - part 3

I started writing about test executive software last month, and then a couple weeks ago I wrote about off the shelf software.  Now I want to write about my experiences with "rolling your own" test executive.

I've worked with homegrown test executives at two different companies.  At the first company the test executive evolved out of a couple of different programs for testing different features of the same product.  In the second company, I worked with a test executive that had been written several years before I started. I'll address each one in a separate paragraph.

The executive I wrote myself was somewhat rudimentary.  For the products we were manufacturing, there were six distinct tests you could perform.  Each of those tests had from about 3 to 20 different numerical parameters that could be adjusted.  This just screamed out for scripting, so that's what I did.  The end result had the configurability I needed, and it was often used by test technicians, but it was missing several other features of an off the shelf system test executive:

• It was only usable within the Labview framework I had written.  For example, it couldn't interface with any modules written in C++  without a lot of extra coding.
• There was no programmatic logic in the scripting.  The scripts consisted entirely of what tests to perform under what conditions - no if-then or optional looping allowed.
• Some reporting tools existed, but mostly in simple formats (saving CSV files or bitmaps of graphs).
• It was written with testing a specific product, and had to be overhauled to test some other type of product.

The other test executive was written in .NET and made use of Measurement Studio for certain graphical presentations.  The scripting tools had quite a bit of programmatic control, and the reporting tools were more extensive.  But there were different problems.

• Because it had been designed as a reconfigurable tool, it was horribly complicated to use.  We didn't let technicians near it without a lot of training.
• It was only usable within the .NET framework and didn't play well with other modules.
• It was written with testing a specific product, and had to be overhauled to test some other type of product.

That's a brief synopsis of the two in-house test executives.  So, what is the point I'm trying to make?  I'm not really saying that you should run out and buy a copy of Test Stand.  It's certainly a nice piece of software, but it's expensive and may be overkill for what you need.  I guess the lesson I've learned is that if you get to the point were you want to develop something for yourself to reuse over and over, learn from how the OTS software does it.  Specifically:

1. Don't make it overly complicated
2. Make it generic enough to use for different tasks
3. Use programmable logic in the scripting
4. Have plenty of reporting tools

Test Executives - part 2

A couple of weeks ago I started writing about test executive software.  I've decided that this topic is another three-parter, so in this 2nd post I'll write about off the shelf (OTS) software.  The third post will cover in-house test executives.

I mentioned last time that I have my own definition of a test executive software, but I never wrote that definition.  Well, for me the software is defined by what I expect it to do.  The three things I expect at a minimum are:

1. Configurable testing.  I need the capability to switch up the order in which specific parameters are measured and under what conditions they are measured.  This is typically done with scripting or configurable sequence files.
2. A solid, usable GUI.  A test executive is often used by a test technician instead of an engineer, so you need software that doesn't require a lot of care and feeding.
3. Easy to see what's happening.  This is somewhat related to #2 above but more specific.  I like graphs, reports, and charts.

The OTS platforms I have experience with are TestStand and ATEasy.  I wrote about my experiences with TestStand a year ago (a three parter, starting here and continuing with this and that).  To be honest, I'm a lot more nebulous on ATEasy and my knowledge of it consists of three data points:

• I sat through a long seminar on it once.
• I worked with a guy who had used it before and liked it.
• I evaluated it for about a week at a previous company.

Given that limited knowledge, I think it would serve as a cheap, limited alternative to TestStand.


On a final note, NI published a checklist for evaluating test executives.  While the list is a little self-serving and obviously slanted towards NI software, it's worth consideration as a starting point.

Test Executives - part 1

For many years now I been a little obsessed with the subject of test executives.  I'll explain why in a minute, but first let me try to define what I think of as a test executive.

Wikipedia has a specific description of test executives, but my definition is more specific to my experiences.

So why do I want to write about this topic?  Ten years ago I was working for a small division of a Fortune 500 company.  We had just bought a complicated test/manufacturing tool developed by a consulting firm.  This firm had written a script driver that they used for most of their hardware projects.

That was an epiphany moment.  I had written a script driver for a specific test instrument when I worked at HP back in the late 90s, but I'd never really thought about writing one that I could reuse across projects.  Nor had I considered buying one off the shelf.  In the ten years since that moment I've worked at four other companies that developed four separate solutions.  So over the next couple posts I will write about different test executives - commercial as well as "roll-your-own" - and compare and contrast my experiences with each.

Historian Software

A week ago I sat in on a presentation for a type of software I had never had dealings with before: historian software.  It was GE's version of the software, called Proficy.  Before the demo I did a quick check on what the software was, and it really just sounded like a database with a nice GUI.  

But after the presentation I have to admit that it's really a lot more than that.  I'm not sure if I'll ever use anything like this, since it seems geared towards enterprise-level applications and I gravitate to startup companies.  But it's still neat. 

It's always cool to learn about something new in this field.  Maybe I'll check out NI's historian software, NI Citadel.

Prepping for the CLD-R (part 3 of 3)

Last month I wrote about refreshing my Labview skills before I passed the CLD-R exam.  This topic turned into a set of three additional posts.  The first two were about available seminar materials and online help topics.

Now I'll write about the third (and last) thing I did to prep for the test:

Study the sample tests

I found two sample tests that NI had posted on their website for the CLD-R exam.  Who knows - if you dig hard enough maybe there are more.  The first thing I did was take one of the tests as if it were real - no cheating.  Then I followed these steps:

1. Examined every write answer I got to make sure I understood why.
2. Looked at every wrong answer to figure out the correct answer.
3. Researched the specific topics that were a little fuzzy.
4. Looked online to see if anyone else had worked out answers.  A few examples are here and here.  You can try looking at LAVA as well.
5. Worked out IN DETAIL every single problem that had code attached to it.  
6. Took the second test as if it were real.
7. Repeated steps 1 through 5 for the second test.
8. Took the first test again.  A couple weeks had passed since I first tried it, which was enough time for me to gauge whether I had improved.
9. Took a couple days to digest my second pass.
10. Repeated steps 8 and 9 for the second test.

I know all that effort may seem excessive, but what can I say?  Engineers tend to be like that.  Regardless of the effort involved, following those steps definitely helped me understand the topics NI thought were important for the test.

The fifth step - working the problems out - was particularly useful.  In my opinion just memorizing answers stimulates only one part of your brain.  I created a separate VI for each problem, added as much detail as I needed, and ran the VI until I got a satisfactory (an understandable) answer.  Going through that effort helped to create a sort of "muscle memory" that I could call on during the test itself.  Besides which, I think going over those topics helped me improve my programming skills in general, even if only a little.

So that's all I'm going to write about the CLD-R exam.  Good luck to anyone taking the exam, and I hope this helped.

Prepping for the CLD-R (part 2 of 3)

In a previous post I wrote about the tasks I undertook to refresh my Labview skills before I passed the CLD-R exam.  My first post on this topic discussed NI seminar materials.  Now I want to write about something else I focused on:

Review online help info

NI publishes a list of about a dozen items the test covers.  Of those, I found the following to be worth my time reviewing:  Events, error handling, timing, recursion, reentrancy, shared variables, and file IO.  So I went into NI's online help, bookmarked the pages relevant to that topic, and then reviewed it in detail.

For example, for timing I looked at these items:

• Timed loops
• Configuring timed loops
• Timed loops are slower
• Timing structure characteristics
• Timed sequences
• Software timing vs. execution timing 

I also went through the examples I could find online as well as the example finder in LV itself.  There was quite a bit of information available.

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

I'll write one more post on this topic of CLD-R review, probably in another week.  Then I'll hopefully get more current with my posts again.

Prepping for the CLD-R (part 1 of 3)

In my previous post I wrote about refreshing my Labview skills before I passed the CLD-R exam.  This post will talk about one of the things I focused on:

Seminar materials

I attended the Labview Developer Education Day back in March.  This accomplished three things related to my study for the CLD-R:

1. Ni will often give out discounts for training or tests at these events, so that saved me some money.   
2. Attending an all-day seminar sparked my memories in an entirely different way than just reading up on Labview tricks or working through code examples.  I think listening to other people talk about code issues stimulates your brain in a different way.
3. I got to see presentations worked out in detail.

Number 3 on that list related to something that I had already been doing on and off since the beginning of the year: going through presentation examples.  Just go to NI.com and search for "Developer Days" or "Technical Symposium."  I did it just a few minutes ago, and one of the first items that popped up were the presentations from the 2013 Developer Days.  In fact, with some digging you can find presentations going back to at least 2009.  Even better, with some more work you can find the examples that go along with those presentations.

So I did exactly that.  I went dumpster diving into NI's archives, digging around until I found about 4 GB worth of data (including actual videos of some presentations).  And then I read through them all, skipping over the duplicates and the presentations aimed toward introductions and hardware-specific issues.  And I worked through every single example, making sure I understood it.  It helped.

So that's the first of three things I did.  I'll try to post the second one sometime this weekend.

Testing and mobile devices

Below are links for two recent articles.  Both articles discuss mobile devices and testing, but they cover very different subjects: testing apps for mobile devices and using a mobile device for testing.

The first article is sort of an editorial lament/challenge about the issues mobile app developers face.  Dr. Dobbs has a top rate rep for covering software development, and I'm not going to try to paraphrase what they published.

The Evaluation Engineering article is something of a mini-survey of software and hardware available for mobile devices (mostly Android and iOS devices).  A couple of these apps I already have on my iPad, but there were some new ones I hadn't seen before.  I particularly liked the spectrum analyzer app and the LogisScope app-and-hardware.  Neat stuff.


Sometimes I bookmark similar articles and read them together when I have time.  After I did that with these articles, it just sort of struck me how the mobile aspect of testing - which didn't even exist ten years ago - is just incredibly new and cool.  And yet it's still the same thing, just in a different (and cooler) package.