- Posted on: 2024-03-01
LabVIEW and Python are two very useful tools to achieve typical tasks for engineers and scientists. They have different benefits and trade-offs at development and at run-time.
LabVIEW is a graphical programming language designed to offer scientists and engineers easy access to recording measurements and controlling their instruments. It can easily take advantage of parallel processing and multi-threading, a critical element to achieve determinism. LabVIEW can easily analyze and store a large amount of data from multiple different sources at once.
Python is an open source, text based, interpreted language that is very popular and widely adopted for both simple and complex tasks. It benefits from a large range of extensions, modules and routines readily available to complete a broad range of custom data analytics functions.
In the end, both are programming languages and for the most part, can typically accomplish a given task. Without going into the details at this point, Synovus believes that LabVIEW is better suited for the deterministic portion of an application including:
- The drivers communicating with the instruments
- Supervisory and protection functions
- Real-time modeling of a digital twin
- Datalogging
We believe LabVIEW is also better suited as a user interface for typical Automated Test System (ATS).
On the other end, Synovus believes that Python is better suited to perform functions that will typically evolve with your application such as:
- Post analysis processing
- Reporting to database or emails with custom content
- Test executive
Since the Python code can easily be modified at run-time, it is important to keep safety functions and logic that must be performed in a given sequence in the main application, within the LabVIEW code.
Out of the 3 examples listed above, the first two can be seen as “independent” from the LabVIEW application. The script is called, performs its function and possibly returns a value as it completes. Parameters can be passed between the 2 but only at the beginning and at the end.
The third application is very different. As a simple test executive, Python code offers the programmer the ability to quickly modify the flow without affecting the drivers, UI, etc.. However, this means that Python needs to be able to interact with LabVIEW while both programs are running independently on the same (or even different) computer(s).
Use case #1: LabVIEW calling Python script
The original way of calling Python from LabVIEW was to rely on the command line interface. The LabVIEW code generally looks like this:
This method still works today but it presents disadvantages in performance and exchanging data is more complicated than the new Python node in LabVIEW. It has the benefit of working with any version of LabVIEW and any version of Python.
Use case #2: LabVIEW calling Python with parameters
The Python node was added in LabVIEW 2018 and made it more intuitive to call a Python function within a Python script, exchange multiple parameters and handle Software exceptions from the Python interpreter. This new code generally looks like this:
This is calling the same function as in the previous example but in a much more intuitive way for a developer. Less risk of typos in the command and it’s easier to retrieve the returned data.
Use case #3: Python interacting with LabVIEW
The most useful case, in our opinion, is to allow Python and LabVIEW to interact while both programs are running. This requires a different approach because there is no native communication between two different tasks/processes on the operating system. In a Linux based system, named pipes could easily be used but the easiest approach across all OS is to use a TCP/IP communication method.
As we can see on the image above, an interesting advantage of this approach is that Python can run on the same system as LabVIEW is running on or it can run on a different computer. It is possible to dissociate the data acquisition and control (LabVIEW) from the Python routines performing analysis and test executive. This is pretty handy to run different test plans, try different permutation while the core application runs on a Real-Time (such as NI CompactRIO) target.
Give it a try today
If you can think of routine, analysis or reporting that would benefit from being configured at run-time by a developer, you should consider using the Python node (unless it’s simply changing one or two values and easily done on a user interface). This will open up a large number of routines that can be found online as Python code but would take a long time to program in LabVIEW.
Symplify™ supports running Python scripts that can interact (over TCP/IP) with any Tag in the application. This makes it a great solution to act as a test executive as well as running analytics or reporting routine that can more easily be modified and updated at run-time. If your ATS is primarily geared for engineering development, this flexibility at run-time can save weeks of development and reduce the risk of unintentional changes in the code.