Showing results for 
Search instead for 
Did you mean: 

Labview Application Web Server: a service launching Python node or an exe

Go to solution

Hi all,

I have some services published with Application Web Server in LabVIEW 2018 and W10.

I need to call a published service which contains a Python node, so I used two different approaches:

1) The web service .vi works fine when in LabView environment, but after deploying a call to the service gives an error in output.

I checked out that the error comes out directly from the "Open Python session" vi, so it is not directly retated with the .py code.

2) After this failure, I tried to compile an exe with the Python node call. The exe works fine.

Then I tried to call this exe inside the web service (through the system exec command), and again this works fine when running the .vi, but not when it is published as a web service.


So it seems that a web service cannot call external executables nor external interpreters (such as Python).

Is it related with some security issues? Is there any workaround?


Many thanks


0 Kudos
Message 1 of 7

Without knowing more, it's really just a guess, but perhaps your web application runs as a different user (to your IDE, which typically runs as the logged on user unless you run as Admin) and this changes your PATH, or a similar environment variable.

It could also be that the NI Web Service service has a reduced path intentionally to prevent pulling in all sorts of other things.


What is the error you get from the Open Python Session VI?

0 Kudos
Message 2 of 7

Thanks for your reply.

The error coming out from the service call (such as: http://localhost:8080/WS/python_call) in which the .vi opens a Python session is the following (I have packed it inside the JSON reply coming out from the service call by the browser):

Python returned the following error: Error creating host process.

This error never comes out when running the .vi from LabVIEW or from an EXE.

The .vi published as a service simply opens and closes a Python session, without executing any .py code, at the moment.

Calls and executions (service, browser and Application Web Server) are in the same machine, at the moment, and I am logged as Administrator.

Installed Python is 3.6 with Anaconda and OS is W10Pro.


0 Kudos
Message 3 of 7

Update: I tried to compile a .dll with LabVIEW including the Python call  and I've put the call inside the web service vi.

Again, the .vi works fine in LV environment, but, once it is published as a WS, I have a dll error after the call  (error 1671).



0 Kudos
Message 4 of 7

@Marco_Ge wrote:

Installed Python is 3.6 with Anaconda and OS is W10Pro.


Aha! So, I haven't tried using Anaconda, but I have seen a few posts around the forum about using it with LabVIEW. It seems to often be a problem... 😞

You can try reading through these and see if anything jumps out, but I'd also wonder if you might have better luck if you're able to use a non-Anaconda version of Python... (that being said, I don't know enough about Anaconda to say it's definitely the issue)

Integrate Conda Python Environment with LabVIEW (claims not possible)

Labview 2018 Python Node and Anaconda Environment (looks like they gave up, although 2nd page has some points on a workaround)


Admittedly, since it's working in the dev environment, I'm not convinced it's a Python problem. I still suspect some change in environment settings when the web server runs compared to LabVIEW IDE being run as your local user (with or without administration rights, via UAC).

0 Kudos
Message 5 of 7
Accepted by topic author Marco_Ge

Hi cbutcher,

I think I've found the issue...

After uninstalling and reinstalling various versions of Python, I found that the call of the service works fine only with Python 2.7, while it is not working with 3.6.5 or 3.6 versions!

Many thanks for your interest in solving this issue.

Have a nice day.



0 Kudos
Message 6 of 7

Hi Marco,


I'm glad you got it fixed, so go ahead and use 2.7 if it suites your needs, but if you'd prefer to use 3.6, I'd guess maybe this bit:

@Marco_Ge wrote:

After uninstalling and reinstalling various versions of Python...

is more relevant than the version.


In any case, good luck 🙂

Message 7 of 7