LabVIEW vs. Python

Strategies for Choosing Hardware

Much of this document is strategized to reduce your time developing harware APIs.

Ask a Friend

My strategy for choosing hardware: ask a friend! If your friend can save you a few hundred dollars and a couple of days of effort, go for it! Ask for a loaner and a working API!

There have been many times that a friend has solved the problem in the recent past and have a nearly ready solution already in production.

Choose Hardware with Serial Ports

One of the items that all of my preferred hardware has in common is having control via USB Virtual COM Port (USB Serial). Why?

Driver availability - drivers often install automatically since many are FTDI-based
Well-documented APIs - often text-based (Python excels at text analysis and manipulation)

Standardize Your Hardware

If you don't standardize on a few pieces of hardware, you will spend all of your time developing APIs rather than tests! If you have an application that requires a 5A power supply, it may be worth dedicating a 7A power supply if you have other applications that may use similar hardware. Have a few goto pieces of hardware that you always use and your development time will be minimized.

An additional benefit of standardized hardware is the ability to create a buffer stock from which you can pull more stock as more tests come online. I typically try to keep enough hardware to deploy 2-4 test setups based on standard hardware and requiring only the test-specific tooling to move on. This also reduces time to test since I can start working on the framework and initial test sequence while tooling is being made. At this point, I can put together a competent basic test sequence within half-an-hour, assuming standard hardware.

Shoe-ins for standardization:

power supplies
data acquisition cards
temperature sensing
oscilloscopes

Some equipment that I'm currently evaluating for standardization:

HiPot machines
LCR meters

When choosing candidates for standardization, buy one and give it a good shot. Prove it out. Make sure it works well. Time invested up front is painful to lose, but if you standardize on an awkward piece of hardware, you will find that you always have to deal with that awkward piece of hardware. Choose wisely!

Bonus: Use the Same Manufacturer!

Many manufacturers use the same API between instruments of different ratings. This means that you have minimum work required to bring up a new instrument. Less time dedicated to APIs. This is NOT universally true, so be sure to check!

Use Inheritance/Interfaces in your APIs

I usually write the API for the hardware before actually interacting with the hardware. In some languages, this is sometimes called writing an interface. In this way, I ensure that my actual implementation abstracts away much of the awkwardness that may be inherent in the instrument. Additionally, using inheritance, I can have more than one instrument utilize the exact same API. I have switched power supply models by simply changing the hardware acquisition line because both power supply classes inherited from the same abstract parent class.

My favorite abstract class is for power supplies.

class Psu:
    def set_voltage(self, voltage: (str, float, int)):
        raise NotImplementedError

    def set_current(self, current: (str, float, int)):
        raise NotImplementedError

    def on(self):
        raise NotImplementedError

    def off(self):
        raise NotImplementedError

    @property
    def voltage(self):
        raise NotImplementedError

    @property
    def current(self):
        raise NotImplementedError

Starting with the above abstract class, I start with a complete target of functionality for a relatively simple set of concepts to implement before I can proceed to test development.

My Favorite Hardware (thus far)

Data Acquisition

DATAQ DI-2008

My favorite DAQ is the DATAQ DI-2008. When I'm being perfectly honest, the serial API is a bit awkward, but I took a lot of trouble to abstract the awkwardness away with a pip installable package. Once past the API, the features more than make up for the awkwardness and I'm glad that I stuck it out with this one:

configurable analog inputs from +/-10mV to +/-50V... how is this possible?!
analog inputs may be configured as thermocouple inputs... directly... up to 8 of them!
digital inputs/outputs - pretty standard
dedicated rate input
built-in analog filters

The DI-2008 has more features, but I haven't used them all yet. Feel free to contribute to the di2008 package!

There are only a couple of drawbacks to this device:

speed isn't great at 200 samples/second
no analog output

Thus far, these haven't hobbled my manufacturing-oriented test setups, but I'm sure that is a matter of time before I have one of these requirements bite me.

When not using the DI-2008, I like to use the National Instruments USB-6001 or similar. The API isn't great since you have to drop down to the C documentation, but it is usable. Recommend spending some time to tune the API since it is somewhat non-intuitive.

Power Supplies

AimTTI

Thus far, I have worked exclusively with AimTTi power supplies. Both of the supplies that I have utilized started as a result of a recommendation from a friend.

The CPX-series of power supplies is available for 60V applications up to 20A. Supplies are easy to operate, have a remote-sense mode, and have exhibited ease of use and stability. I can now get one of these up and running in a couple of lines and I couldn't be happier. Be sure to look for models with USB option.

When I want a bit less voltage/current/dollars, I look to the EX-series. Specifically, the EX355P-USB.

Both of these supplies are rock-solid choices for their range. I will definitely look to AimTTI for the next application that is beyond the range of these devices before looking anywhere else.

Oscilloscopes

Rigol DS1000Z

Recently, I have been replacing setups which require an operator to evaluate and make judgements about oscilloscope waveforms, even for basic measurements. I have been quite happy to use the Rigol DS1000Z series.

Using an oscilloscope is likely overkill for many tests that we execute; however, I am often replacing legacy tests which require a user to make judgements based on the oscilloscope plots and replacing those with similar instrumentation tends to increase confidence in the methods.

Your Hardware

We have discussed "standard" lab equipment, such as power supplies and oscilloscopes, but haven't talked about your device! If your device has a communications interface, it is just as important to have a good API for controlling your hardware as it is to have a good API for your devices. For one, it makes tests written on your hardware much more readable, but it also allows the generation of multiple tests of the same product much easier. Don't neglect your device!

Concluding...

Having a few lego blocks from which to build tests will make your life easier. Again, spend time making your API simple and repeatable across multiple instruments and you will be rewarded with superpowers such as the ability to construct a competent test in hours instead of days.