Controlling LabVIEW GUI from Python - Any Easy/Official Way

[FrancisGohier]

Hi all,

Is there an easy or official way to control the LabVIEW GUI/software from Python that I might have overlooked? I came across the repository python_labview_automation, but it seems to have been inactive for about 9 years. Should I look into using LabVIEW "Shared Network Variables" ?

NI has clearly integrated Python into their ecosystem with several actively supported libraries for controlling NI devices from Python. However, my challenge is different: I have devices (not necessarily from NI) that already provide a LabVIEW interface. While I can communicate with most of them directly via SCPI, I’m looking for a way to control the LabVIEW interface to avoid having two entry points and duplicating logic (GUI vs remote automation).

I run my automated scripts and Python calls from RobotFramework, and this is a constraint that cannot be changed.

Any insights or suggestions on how to approach this would be greatly appreciated!

Thanks,
Francis

[Yamaeda]

None is 'easy', but:

- Shared variables can work

- TCP/IP or UDP and send commands

- If the GUI isn't absolute necessary you can turn it into a DLL and call it from Python

- Same as above but .NET dll.

- write commands to a file that you monitor

[santo_13]

---

@FrancisGohier wrote:

Hi all,

Is there an easy or official way to control the LabVIEW GUI/software from Python that I might have overlooked? I came across the repository python_labview_automation, but it seems to have been inactive for about 9 years. Should I look into using LabVIEW "Shared Network Variables" ?

NI has clearly integrated Python into their ecosystem with several actively supported libraries for controlling NI devices from Python. However, my challenge is different: I have devices (not necessarily from NI) that already provide a LabVIEW interface. While I can communicate with most of them directly via SCPI, I’m looking for a way to control the LabVIEW interface to avoid having two entry points and duplicating logic (GUI vs remote automation).

I run my automated scripts and Python calls from RobotFramework, and this is a constraint that cannot be changed.

Any insights or suggestions on how to approach this would be greatly appreciated!

Thanks,
Francis

---

You can make them a gRPC service and use it from Python.

[avogadro5]

---

@Yamaeda wrote:

None is 'easy', but:

- Shared variables can work

- TCP/IP or UDP and send commands

- If the GUI isn't absolute necessary you can turn it into a DLL and call it from Python

- Same as above but .NET dll.

- write commands to a file that you monitor

---

The .net dll can sound intimidating but it's dead easy to use in Python, C#, C++, or even directly in PowerShell.

Here's one that might do what you need. It exports one VI that connects to LabVIEW development or RTE via VI server and sets a single control value by name. It uses the JDP json library to adapt JSON to LabVIEW Variant.

The python side is pretty easy

import sys
import os
import clr
import json

path_to_dll_folder = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'build')
sys.path.append(path_to_dll_folder)
clr.AddReference('SetValFromPython')

from SetValFromPython import *
       

SetValFromPython.SetVal('localhost',3365,'SetVal.vi','MachineName',json.dumps('hello world'))

Using pythonnet

[FrancisGohier]

Firstly, thanks for your answers and the extended example.

Given I would like to keep the GUI operational for use by a local user, and that I would like to remotely control the device/GUI from another machine on the network. I assume I can not use the DLL solutions.

The remaining options are:

- Network Shared variables

- TCP/IP or UDP and send commands

- write commands to a file that you monitor
- gRPC service

I would like to pick the most simpler and native one.

My understanding is that network shared variables is the most "native", but not so easiest to interact with from a Python script.

I assume that going through a file, is not as efficient as it relies on monitoring rather than listening for update.

Am I right?

Then I have to choose / try:
- TCP/IP or UDP and send commands
- gRPC service 

What are the pros and cons of each method?

Do you know of any example/article on the topic?

Thanks
 

[avogadro5]

---

@FrancisGohier wrote:

Firstly, thanks for your answers and the extended example.

Given I would like to keep the GUI operational for use by a local user, and that I would like to remotely control the device/GUI from another machine on the network. I assume I can not use the DLL solutions.

---

That DLL is using VI server to actually talk to the LabVIEW program, which works over a network. In your case the DLL would exist wherever the python script is running.

https://www.ni.com/docs/en-US/bundle/labview/page/creating-a-vi-server-application.html

[avogadro5]

---

@avogadro5 wrote:

---

@Yamaeda wrote:

None is 'easy', but:

- Shared variables can work

- TCP/IP or UDP and send commands

- If the GUI isn't absolute necessary you can turn it into a DLL and call it from Python

- Same as above but .NET dll.

- write commands to a file that you monitor

---

The .net dll can sound intimidating but it's dead easy to use in Python, C#, C++, or even directly in PowerShell.

Here's one that might do what you need. It exports one VI that connects to LabVIEW development or RTE via VI server and sets a single control value by name. It uses the JDP json library to adapt JSON to LabVIEW Variant.

The python side is pretty easy

import sys
import os
import clr
import json

path_to_dll_folder = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'build')
sys.path.append(path_to_dll_folder)
clr.AddReference('SetValFromPython')

from SetValFromPython import *
       

SetValFromPython.SetVal('localhost',3365,'SetVal.vi','MachineName',json.dumps('hello world'))

Using pythonnet

---

Word of warning, I spent an entire day trying and failing to make this work with a 64-bit assembly+python. It hangs on the SetVal() call for a few seconds and then python just exits. No exception or anything. No issue with built in assemblies like System. So I only recommend this using a 32-bit assembly and 32-bit python.exe unless someone knows what's going on with it.

[rolfk]

There is another option but it is Windows only (well the .Net assembly from the LabVIEW VI is too, but that aside). LabVIEW also provides an ActiveX automation server interface to VI Server. It is not as extensive as the native VI server interface but offers the necessary methods to do what the shown .Net version does.

There are a few drawbacks to this:

- ActiveX is a legacy technology according to Microsoft (despite that the entire Windows Shell is actually based on COM, the fundamental technology used in ActiveX).

- ActiveX automation server needs to be explicitly enabled in the LabVIEW VI Server options (or the according INI keys need to be added to the INI file of build applications).

- Python has full support to access COM interfaces through the pywin32 module, but I'm not sure how well maintained it is, since the entire world moves to .Net and the according Python COM interface may be getting more and more into limbo. 

See here for the basic principle to this:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015BKpSAM

While the native VI Server is simply binary TCP based, its protocol is unfortunately not openly documented. I did in a long ago past (LabVIEW 6 and 7) experiment with it and was able to talk to VI Server using native LabVIEW TCP nodes, but I never felt comfortable to publish that for various reason.

[Jay14159265]

The increased complexity of dealing with two applications ( labview and python ) might warrant looking at writing your own interface native to python. Out of curiosity which instrument are you working with that has a labview api? Do they provide a c++ or .net api? 

[Jay14159265]

---

@FrancisGohier wrote: Then I have to choose / try:

- TCP/IP 

---

Yes,  TCP/IP is the one you want.