Embedded version of run-time engine - Python Node

[lukikwiatkowski@gmail.com]

I'm trying to run LabVIEW application as a Linux service. To do that, I need to build the application without a user interface. It's possible and documented here:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019RYlSAM&l=pl-PL

However, if I will build an application which uses Python Nodes functions, it will crash with an unknown cpp error - so it's not supported or it's a LabVIEW bug.

I can imagine that function is not supported - if by choosing "embedded version of the run-time engine" we are choosing to use the run-time engine which is used in Industrial Controller or cRIO .

That makes sense because the feature of calling python code is not supported for targets like Industrial Controller. 

My question is what does that feature do? What is the embedded version of the run-time engine (which target we can use)?

[diman27]

I'm facing the same issue.

LabVIEW crashes when i try to open Python Node inside shared library, compiled with embedded runtime option enabled.

Can anyone help me to choose the right direction on how to use LabVIEW Python node with "dark" version of LV runtime engine?

VI is simple - open and close python session.

In normal RTE working OK, in "dark" version - crashed.

LabVIEW 2020 + OpenSUSE 15.1
Crash log attached...

[mpignati]

Hi,

we had a couple of iterations with NI about the support of Python nodes when using the embedded runtime (available in Linux only). The final answer on that discussion is not yet clear to me, but they did mention that it seems that Python nodes cannot be called with the embedded runtime. This is an undocumented issue and might be short-sighted as it seems that NI is pushing to use both LabVIEW (on Linux) and Python.

An alternative that I can suggest is to uncheck the “embedded version of RTE” when building the shared library (although I assume you checked it for a reason). In our case, we want to run the code as service in Linux. Having the normal run-time engine means that a GUI has to be present in the OS/docker-image, making it unnecessarily big. Additionally, if the GUI has to be loaded before running the service, there is an implicit login procedure that has to take place.

To work around this, we restructured the code in order to have a completely separate python service communicating with our service built in LabVIEW via gRPC (the support for gRPC is increasing in LabVIEW). By doing so, we avoid calling Python nodes when using the "embedded run time engine". I hope it helps, and I hope that NI clarifies the documentation.

[diman27]

Hi, mpignati

Thanks for the help!
I also need to run my program as a systemd service, so using the "dark" version of RTE is preferable.

I rarely need to call external python script from my service, gRPC would be too heavy for that.
After all I completely removed Python Node from my code and now call the python script via shell exec.
Some arguments are passed through shell command line, as described in this thread.

And the data goes through standard input because it's quite large for a command line.

Maybe it will be useful for someone...