@Jay14159265, do you have any information on the performance implications of calling Python from the command line versus from within a session in LabVIEW? I can see why you would want to do this for the flexibility of the versions, but then why would NI invest in making the Python Node at all if this “older” approach was a better solution? Asked another way, what does the Python Node get you that the command line does not? Perhaps only easier argument/data passing?
I will say that the method for calling python described in the previous post is the *easy* way to do it that was used before LabVIEW had python nodes. That being said, it is not the only way to do it. On the performance topic, when you call a python script directly, it has to launch the python interpreter then load all the modules then run the code. All this takes a long time so if you are worried about performance this is not a good way to call a simple python script that returns some value that you are expecting to use in your next bit of logic in your program. But if the python code you call continues to run in another process and you pass it data and it returns data, it can be as efficient as is possible, but it is lot more involved in programming on the Python side.
For the Python nodes in LabView it is stated:
LabVIEW 2018 introduces the Python Node, which provides native capability to intuitively call a Python script from a LabVIEW Block Diagram. It uses LabVIEW primitives, providing a way to interoperate between the languages with low latency.
I don't know how they implemented this but I would imagine LabVIEW launches a python interpreter in the background on the first call to a python node then for the next n calls, it just attaches to the running interpreter and runs the code. The advantage to this is that you can now easily call Python in LabView. the disadvantage is that you are required to use the LabView Python interpreter (2.7 or 3.6 last time I checked) that they set up in their own virtual environment. So using a LabView Python node can be fast, is easy to set up, but is restrictive. Calling Python directly can be fast, is much harder to set up, but is not restrictive. So I would say that the Labview Python nodes are great if you have a *small* script that runs on 2.7 or 3.6 but once you start getting into large scripts that have more complicated dependencies you have to move out of the Python nodes to the direct call, unless you want to develop your Python code around the restrictions of the LabView Python node.
more info:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015C6tSAE&l=en-US#:~:text=LabVIEW%20201....
______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
