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.