LabVIEW vs. Python

Software Stacks

Anyone already familiar with Python - particularly from the data science perspective - will already be familiar with the majority of the contents of this brief article. In short, this article will introduce some of the software that will be utilized during your test development.

numpy
pandas
matplotlib
pyvisa / pyvisa-py
pyserial
threading / multiprocessing
GUI, tkinter / Qt

Plotting

Use matplotlib. There are other packages out there, but none have as much documentation or maturity and the publication quality is second to none. I prefer to use the object-oriented interface, but if you are coming from MATLAB, you may prefer the state-based plotting.

I haven't used Qt charts - or Qt for that matter - but I see that, in some cases, they may make a competent replacement for matplotlib.

Data Processing

numpy logo

The standard packages for data processing are numpy and pandas. You can store millions of points along with gaining functionality such as fft and a host of other functions provided specifically for processing data quickly. Like matplotlib, numpy was originally created to replicate some of the array processing of MATLAB in an open-source package and, thus, has become the core of hundreds of packages. pandas can be thought of as a spreadsheet-like abstraction, but is actually much more powerful than spreadsheets in its capabilities.

Serial Port Access

pyserial logo

Try as they might, USB will never fully obsolete the ease of use of the good old serial port. Of course, it has been relegated - on most machines - to the virtual COM port, but its simplicity still reigns supreme in the hardware space.

I use pyserial on nearly every project somewhere. The project is simple, useable, and mature. In most cases, code built on linux works just as well with windows, which is unusual in the hardware space.

The fact is that manufacturers continue to utilize the FTDI chips for USB serial interfaces, so knowledge of PySerial is simply required.

Hardware

As previously suggested, you should try to find hardware that has a good serial interface. If you find that you can't find a great serial interface for your chosen instrument, then it is likely supported through some VISA implementation. When I'm being perfectly honest, I usually struggle a bit to find the right instrument drivers. Sometimes the vendors drivers work quite well... and sometimes not. Either way, once you get the right drivers installed, you will want to use pyvisa to interface with the hardware.

There are two flavors of pyvisa available: pyvisa and pyvisa-py. There are some common authors between them. The -py flavor is a pure python implementation. Either should work for most instruments, but pyvisa is a bit more mature.

Threading

Of course, the threading and multiprocessing modules are part of the standard library. There are some cases in which the interface needs to be polled or maintained independently of any other process. Up to this point, the threading module has been up to the task of maintaining the test functionality. I expect that, one day, it won't be. When that day comes, I will push some of the high-demand tasks to multiprocessing, which will actually allocate an independent true thread to the task.

If you don't understand communications between threads, it is best to stick with threading.

One potentially significant advantage of LabVIEW is that it uses a data flow model, meaning that processes are not running until all inputs are satisfied. This data flow model means that users are rarely exposed to threading and processing realities since the LabVIEW runtime engine takes care of the processor load in most cases.

GUI

One aspect in which LabVIEW shines is in the ease of GUI creation. The drag-and-drop interface that was created for the user makes programming in LabVIEW deceptively easy. As a result, if you are looking for a replacement, you need to be familiar with some sort of framework for creating user interfaces.

My preference is tkinter primarily because I have clarity on the license. The tkinter packages comes bundled with Python and deployment is easy.

On the flip side, flavors of Qt, such as Qt5 and Pyside2 always make me feel nervous when I read their licensing terms.

As we will see later, there are ways to make your program create a majority of its own GUI so that the user only sees "pass" and "fail" blocks. This is the way that I was taught to write test programs and I am happy that I have gone down that route. Again, we will revisit GUIs later in the article stack as there is much more to discuss.

Deployment

As with any production test, deployment considerations take front and center as soon as your code moves from your lab to the production floor. With LabVIEW, you are required to install the correct runtime engine for the environment. With python, we can deploy the runtime engine with the executable as a package using pyinstaller. We will talk more about this at a future time.

Bonus: Test Framework

Early on in my test development efforts, I tried to come up with frameworks that made testing easier. Automated test frameworks such as pytest are great for hardware testing, but they don't really seem geared towards manufacturing tests, which are repetitive and tend to save the same data set each time around. In my efforts, I eventually came up with the Manufacturing Automated Test Suite (MATS). This is essentially a console tool that creates a test thread which executes and coordinates the test itself.

In addition, I created tkMATS which will automatically create the GUI and put a nice face on the front end.

We will discuss the test framework later, but this is one of the keys to developing production tests quickly since it removes the burden of boilerplate from the user while ensuring a safe and consistent test product.