Enthought's Python Integration Toolkit for LabVIEW (PITL) is at end of life, and is no longer available to new users for sale / licensing / activation. Enthought will support existing customers for one year from date of purchase, as stated in the PITL license. At our discretion, we may also sell additional activations, unsupported, to existing customers. The Toolkit remains available for download for the convenience of existing customers, but licenses will not be issued to new customers.
Note - PITL is not compatible with Python 3.7 and above. Users have reported that it remains compatible with Python 3.6.8, and with LabView 2018, 2019, and 2020.
We strongly recommend that all users of Enthought's PITL migrate to NI's built-in Python Node, as soon as possible.
When work started on the PITL a few years ago, there was no solid option for people who wanted to use Python and LabVIEW closely together, and Enthought was able to help by providing integration with both Python and the Canopy IDE product.
The landscape now is different... Python has exploded in popularity, and since LabVIEW 2018, customers now have a native mechanism for calling Python from LabVIEW. The built-in Python Functions provide a seamless and low-complexity experience for calling Python from LabVIEW. Because the Python Node is a native LabVIEW component, the process of calling Python is substantially simplified; the Python Node plus two session-management VIs replace all 11 VIs in the Python Integration Toolkit; and there is first-class integration with NI's Application Builder.
See also the Python palette reference in the official LabVIEW documentation. Here is a summary of PITL VIs and their new LabVIEW-native equivalents:
|Python Integration Toolkit||LabVIEW 2018+ Python Functionality|
|New Session||Open Python Session|
|Close Session||Close Python Session|
|Get Value||Python Node plus small Python function|
|Set Value||Python Node plus small Python function|
|Delete Value||Python Node plus small Python function|
|Exec String||Python Node plus small Python function|
|Catch Exception||Handle inside Python|
The main difference here is that a PITL session includes a reference to a single Python module, whereas the LabVIEW built-in Python sessions can have multiple modules per session. Instead of providing the Path to Python Module when the session is created, it should be provided as desired to each Python Node call. There is no longer any need to start multiple sessions for different modules.
Interpreter discovery is also different; instead of the optional "Path to Python.exe" input used by the PITL, ensure that the directory containing the Python DLL is on the system path before launching LabVIEW. When distributing applications that need to call Python, this replaces complex interpreter-discovery code with a requirement that the PATH environment variable be set correctly by the machinery installing Python. LabVIEW will then pick up the DLL and handle further configuration automatically. Be sure to specify the desired version of Python; like the PITL, both Python 2 (2.7) and Python 3 (3.6) are currently supported by the LabVIEW Python Node.
With the built-in LabVIEW Python functionality, it is no longer necessary to Pack function arguments, or Unpack returned objects. Likewise, Clear Objects is no longer needed to recover memory. Instead, simply wire your data directly to the Python Node inputs and outputs, and LabVIEW will handle all format conversion. Like other LabVIEW functions that need to accept a variable number of inputs and outputs, you can resize the Python Node as needed depending on the function you call. The Python Node terminals will also automatically adapt to the LabVIEW data types you wire to them, replacing the PITL requirement that the correct polymorphic VI be selected.
There are also some data type differences. First, sending clusters from LabVIEW to Python is now possible. They arrive as tuples, so be sure to check the order of controls in your cluster to be sure it's what you expect. Second, the LabVIEW Python Node supports arrays via conversion to Python lists. On the Python side, to convert to a numerical array, wrap each array argument in numpy.array(arg) before using. You can then use the NumPy arrays as normal, including passing them to lower-level scientific libraries like SciPy.
Python helper functions
Some of the PITL functionality (Get/Set/Delete Value, Exec String) requires calling a small Python shim function in your module:
def set_value(name, value):
globals()[name] = value
First, ensure you have installed the "six" Python package (for example, by running
python -m pip install six on the command line). Then:
Handling specific exceptions
Instead of using the Catch Exception VI, this should be carried out inside your Python code, using the normal Python try/except machinery.
Thank you for the informative article, Jonathan.
The great downside, in my opinion, of the labview python "Open session" VI is the inability to specify the exact path of the python.exe file you want to run. This was a very beneficial feature in PITL in cases where multiple python installations existed on a computer. With the new labview node, it is a bit of a pain to constantly massage my system path to force labview to use the python distribution I want, but it is doable as a developer. However, sending a compiled app to an end-user is unfathomable. I cannot expect the end-user to go through this business of constantly manipulating the system path, in case they want to have multiple python distributions on their computer. For this reason, unfortunately, I cannot switch from PITL to the labview python node for applications that will be user-facing.
Thanks for the feedback, Tobias. I would encourage you to provide NI with this (and any other) feedback that you have about the usefulness of their current solution.