python What is the state-of-the-art of Python-LabVIEW integration?

[drjdpowell]

I am just starting on trying to be able to use Python code from a LabVIEW application (mostly for some image analysis stuff).  This is for a large project where some programmers are more comfortable developing in Python than LabVIEW.  I have not done any Python before, and their seem to be a bewildering array of options; many IDE's, Libraries, and Python-LabVIEW connectors.  

So I was wondering if people who have been using Python with LabVIEW can give their experiences and describe what set of technologies they use.

[Neil Pate]

Nice question James! I have tried to go down this route myself and had a very similar journey.

In the end I have decided to stick with VS Code for Python dev work as it seems to be gaining so much traction and is improving at a great rate.

None of the python connectors I tried worked very well. I would prefer to use the native one but it does not seem to support virtual environments which is what seems to be the preferred way of doing things in Python. In the end I rolled a simple TCP/IP client/server solution and was planning on using that to get data to/from Python.

But. I have no real experience with this so am going to shut up now for the rest of this thread and read every one else's answers with interest.

[drjdpowell]

I've been investigating this: 

But I failed to get it to work.

[ShaunR]

My tuppence ... choose one, LabVIEW or Python.

You can create services which interact through TCPIP or REST API's but keep them separate.

If you have 20 python devs and one or two LabVIEW developers then you are on a hiding to nothing. Python won the war a long time ago and it's time to learn Python.

Not the answer you were probably looking for but you'll end up mostly doing IT and configuration trying to get your LabVIEW python stuff to work anywhere except your dev machine. 

[drjdpowell]

6 hours ago, Neil Pate said:

I would prefer to use the native one but it does not seem to support virtual environments which is what seems to be the preferred way of doing things in Python.

Can you say more about that?  What do you mean by a "virtual environment"?  I experimented with the native node in LabVIEW 2020 and I'm liking it so far.

[X___]

8 hours ago, drjdpowell said:

I've been investigating this: 

But I failed to get it to work.

What is the problem? As far as I remember I just had to tweak a path constant... However this is more than python. It's python in a Jupyter notebook (which is getting very popular in many circles)

[bjustice]

I've been a big advocate for the Enthought Python integration toolkit in the past.  Unfortunately, the product was discontinued when LabVIEW introduced the native python node.
I'm still scraping by on this product as I've not found a good alternative, and the built-in LabVIEW python node doesn't meet my needs.
Under the hood, the Enthought product was just a TCP link to Enthought's flavor of python called Canopy... which has also been discontinued. 
This product was fantastic for a few reasons:

• Canopy environment could be packaged into a lightweight Python runtime engine, which can be zipped up and passed around with LabVIEW executables.  Made it easy to deploy the code to many machines.
• 32/64 bit LabVIEW compatible
• fast read/write of large data to/from Python

Relevant link:
https://support.enthought.com/hc/en-us/articles/360035630192-Toolkit-End-of-Life-Porting-to-LabVIEW-s-native-Python-support

I recognize that this probably isn't helpful... but a datapoint

 

[X___]

9 minutes ago, bjustice said:

I've been a big advocate for the Enthought Python integration toolkit in the past.  Unfortunately, the product was discontinued when LabVIEW introduced the native python node.
I'm still scraping by on this product as I've not found a good alternative, and the built-in LabVIEW python node doesn't meet my needs.
Under the hood, the Enthought product was just a TCP link to Enthought's flavor of python called Canopy... which has also been discontinued. 
This product was fantastic for a few reasons:

• Canopy environment could be packaged into a lightweight Python runtime engine, which can be zipped up and passed around with LabVIEW executables.  Made it easy to deploy the code to many machines.
• 32/64 bit LabVIEW compatible
• fast read/write of large data to/from Python

Relevant link:
https://support.enthought.com/hc/en-us/articles/360035630192-Toolkit-End-of-Life-Porting-to-LabVIEW-s-native-Python-support

I recognize that this probably isn't helpful... but a datapoint

 

It was not free and indeed was carrying along a few MB of extra payload in each executable/distro. That link will not be usable by new users (as far as I understand) since they don't sell licenses anymore.

[bjustice]

Correct, they don't sell licenses anymore.

Just trying to be helpful and provide another datapoint.  I'm in the same boat at the moment - looking for a good Python/LabVIEW integration solution, but there doesn't seem to be anything that has been able to eclipse the capabilities of the Enthought toolkit.

[Neil Pate]

13 hours ago, drjdpowell said:

Can you say more about that?  What do you mean by a "virtual environment"?  I experimented with the native node in LabVIEW 2020 and I'm liking it so far.

So again I am definitely not an expert but my understanding is that a virtual environment is like a small sandboxed instance where you can install packages and generally work without affecting all other python code on the system. I guess it's like nuget.

If you don't use a virtual environment when you install packages it affects the global python installation on your machine.

Seems like pretty sensible stuff (and hopefully what Project Dragon will do for LabVIEW). However I have not been able to get the native python node to work with a virtual environment.

[ShaunR]

5 hours ago, Neil Pate said:

So again I am definitely not an expert but my understanding is that a virtual environment is like a small sandboxed instance where you can install packages and generally work without affecting all other python code on the system. I guess it's like nuget.

If you don't use a virtual environment when you install packages it affects the global python installation on your machine.

Seems like pretty sensible stuff (and hopefully what Project Dragon will do for LabVIEW). However I have not been able to get the native python node to work with a virtual environment.

Are you referring to Docker? Does this ring any bells?

[Neil Pate]

1 hour ago, ShaunR said:

Are you referring to Docker? Does this ring any bells?

Docker? Nope that's not at all related to this. I mean Project Dragon.

[X___]

Project Dragon LabVIEW: Announcing Project Dragon - Managing LabVIEW Virtual Environments with VIPM - YouTube

Project Dragon Sign Up - VIPM 2021 (jki.net)

Edited March 6, 2021 by X___

[drjdpowell]

On 3/6/2021 at 6:25 AM, Neil Pate said:

So again I am definitely not an expert but my understanding is that a virtual environment is like a small sandboxed instance where you can install packages and generally work without affecting all other python code on the system. I guess it's like nuget.

If you don't use a virtual environment when you install packages it affects the global python installation on your machine.

Seems like pretty sensible stuff (and hopefully what Project Dragon will do for LabVIEW). However I have not been able to get the native python node to work with a virtual environment.

Though I see the value in that, I don't think that is a significant advantage in my case.  Actually a disadvantage, as my client is already overburdened with "too many things" complexity and would benefit from a standardized python environment.  I also want to minimize the complexity of install on a fresh computer, and I think the native node only requires python itself.

 

[Neil Pate]

3 hours ago, drjdpowell said:

Though I see the value in that, I don't think that is a significant advantage in my case.  Actually a disadvantage, as my client is already overburdened with "too many things" complexity and would benefit from a standardized python environment.  I also want to minimize the complexity of install on a fresh computer, and I think the native node only requires python itself.

 

Sure. But doing dev work on your own PC could then be potentially problematic if you have to support multiple different projects and implementations.

I do expect the native node to get better as time progresses and python slowly strangles all other languages.

[drjdpowell]

On 3/7/2021 at 2:22 PM, Neil Pate said:

Sure. But doing dev work on your own PC could then be potentially problematic if you have to support multiple different projects and implementations.

Hey, I haven't got even one project using python yet.   And my Dev PC uses virtual machines, which I already use for issues like developing with or without Vision installed.

[drjdpowell]

Side note: I am definitely going with the native node, in LabVIEW 2020.  I think NI is underselling it by providing examples that are far too simple (including no examples of cluster-to-tuple or how to hold state data in your py module).  I prototyped my analysis template py module yesterday and it went easy.  No head banging frustrations at all.

[Neil Pate]

2 hours ago, drjdpowell said:

Side note: I am definitely going with the native node, in LabVIEW 2020.  I think NI is underselling it by providing examples that are far too simple (including no examples of cluster-to-tuple or how to hold state data in your py module).  I prototyped my analysis template py module yesterday and it went easy.  No head banging frustrations at all.

Would love to see your more sophisticated testing, especially the holding state data.

[drjdpowell]

7 hours ago, Neil Pate said:

Would love to see your more sophisticated testing, especially the holding state data.

Not sure it is sophisticated, but here is a simple implementation of an Example that increments a counter (state variable), with an error thrown if count exceeds a MaxCount (state variable).  The py Module is called from a LVOOP Object that encapsulates the Python instance.  The Class has methods that call the corresponding py-module functions.

Python Incrementer.zip

py module is this:

# Demo of a Python Module, to be called by LabVIEW

# Notes on Errors:
#  Return errors in a form matching the LabVIEW Error Cluster.  Examples:
#    Error = (False,0,"") # No Error
#    Error = (True,1,"MySource<Err>MyDescription") # 1==Error in input

import time  # used for sleep()

# Example of having global data (global just to this module):
Count = 0
MaxCount = 10

def Initialize():
        Error = (False,0,"") # No Error (change to indicate an error)
        return(Error,)

def GetCount():
        global Count
        return (Count);

def Increment():
        Error = (False,0,"") # No Error (change to indicate an error)
        global Count
        global MaxCount
        if Count >= MaxCount:
                Error=(True,1,"Increment<Err>Can't Increment as at MaxCount")
        else:
                Count += 1
                time.sleep(.3)  # Wait, to count slow enought to see
        return (Error,Count);

def SetMaxCount(NewMaxCount):
        Error = (False,0,"") # No Error (change to indicate an error)
        global MaxCount
        MaxCount = NewMaxCount
        return(Error,)

 

[ShaunR]

3 hours ago, drjdpowell said:

Not sure it is sophisticated, but here is a simple implementation of an Example that increments a counter (state variable), with an error thrown if count exceeds a MaxCount (state variable).  The py Module is called from a LVOOP Object that encapsulates the Python instance.  The Class has methods that call the corresponding py-module functions.

Python Incrementer.zip 66.65 kB · 2 downloads

py module is this:

Just be aware:

Quote Python version specifies the version of Python in which the Python session runs. This function supports Python of version 2.7 and 3.6 only. Although unsupported versions might work with the LabVIEW Python functions, NI recommends using supported versions of Python only.

[drjdpowell]

8 hours ago, ShaunR said:

Just be aware

Can't tell if that is just NI being overcautious, or there is an actual reason for that.  Python 2 was sunsetted  at the start of this year, so no one should use that.  I'm guessing the NI's testing was done against 3.6, as the latest available version when they originally developed the python node. 

 

[Darren]

I've worked a bit with the node and Python 3.9.1 and have had no issues so far.

[hooovahh]

On 3/5/2021 at 9:17 PM, bjustice said:

I've been a big advocate for the Enthought Python integration toolkit in the past.  Unfortunately, the product was discontinued when LabVIEW introduced the native python node.

Very neat thanks for the background on a toolkit I didn't know existed.  I'm sure NI was in a "damned if you do/damned if you don't" situation, but this can be seen as another example of NI's first party solution, stifling 3rd party toolkits.  Also I generally don't mind bundling in stand alone binaries in cases like this if it means an easier experience for users, similar to bundling in the SQLite DLL in the build.