Sunday, July 6, 2014

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.

No comments: