Experimenting with embedding the Python Interpreter into LabVIEW. This is mostly a proof of concept to see what is possible and worthwhile.
import numpy as np
class MovingAverager:
depth = 5
insertAt = 0
sampleSize = 0
def __init__(self, sampleSize : int):
self.memory = np.zeros(self.depth * sampleSize)
self.sampleSize = sampleSize
def add_sample(self, sample : np.ndarray):
end = self.insertAt+self.sampleSize
self.memory[self.insertAt:end] = sample
self.insertAt = end % (self.depth * self.sampleSize)
return self.memory.mean()
- Evaluate Python Code from Strings and Files with all the normal module features
- Call functions, class constructors and class methods without a wrapper
- Pass LabVIEW Multi-Dimensional Arrays and IMAQ Images as Read-Only
numpy.ndarrays
- Create and Cast Python Objects to and from LabVEW types (in progress)
Python and LabVIEW are natural frenemies but what if you could call Python Scripts in LabVIEW? Wouldn't that be great? I certainly think so.
Then, what if we could also bring C++ to the party? Why that would be the ultimate trio:
The ease of programming C++, the performance of Python and the massive potential user base of literally tens of LabVIEW developers.
So why not just use the the Python Integration Node?
If I understand this properly, the Python Integration Node executes in a separate process which means any data you pass needs to be bundled/packaged up and sent over some inter-process interface which can really slow things down when dealing with large arrays and images.
But... the Python Interpreter is written in C and supports being built into another application so we can construct a DLL which wraps up the interpreter and LabVIEW's memory manager functionality. The upshot is Python directly interacting with LabVIEW-managed-memory 👏.
Working directly with Python's C interpreter interface is tricky so we are going to use pybind11 to make life a bit easier.
- LabVIEW 2020 SP1 for Windows or later
- Python 3.10 (other versions supported but require building of binaries) - usage of environmental managers (anaconda?) not tested.
- Caraya Toolkit
- LabVIEW IMAQ and IMAQdx (for IMAQ based examples)
- CMake (3.21 or later)
- MSVC build tools (2017 or later)
- vscode (recommended) with C/C++ and CMake extensions
- Dependencies (recommended) to check binaries can load their dependencies
- clone this repo with submodules
- Use cmake to configure, build and install. The
.vscode-example
directory contains the settings for vscode C++ and CMake extensions - Debugging
- If you have issues building the binaries in the Debug configuration, try the alternative Release-With-Debug-Info. This can happen when some of the Python dependencies attempt to load both the Release and Debug versions, causing conflicts. Unfortunately any Release-type build will optimize unused code which makes debugging more difficult; Installing the Debug Files during Python installation may help.
- Settings for debugging the DLL in LabVIEW are provided in the vscode
launch.json
. Build theinstall
target to update the binary in theLabVIEW/bin
directory.
Very welcome. Open an issue to discuss anything or to put me right on how the Python Integration node works.
- Setup Build System and Dependency Management
- Simple Working Example - Evaluate Python Script and Call Functions
- Explore Passing Python Objects back to LabVIEW (Done but adding more types)
- Explore Passing LabVIEW managed buffers and IMAQ images to Python (Done but considering a Python-writable option)
- Explore Passing Python allocated buffers back to LabVIEW
- Explore making it easy to add the LabVIEW and C++ code to handle custom LabVIEW/Python types
- Explore Multi-Threaded Operation (Results: Managing the GIL and object lifetimes leads to more crashes)