Hello Fellow developers and engineers.
Based on the discussion in this thread I would like to propose the following:
My suggestion is to open support for execution of python nodes on Labview Real-Time targets. This is currently not supported by LabVIEW 2018 Current Gen, even though this version supports executing a python node using the new "Connectivity -> Python"-support.
This should be possible to do on the targets using NI Linux Realtime as the operating system, since Linux treats python as a native application language.
I understand that the execution of Python scripts are not deterministic, which will prevent an implementation in time critical code. That I can follow, but it should be possible to use the python node in lower priority threads or non real-time code, for communication with a REST-API, downloading/uploading files, connectivity to online services and so on.
It has been shown that python can be compiled and executed on real-time targets, here on the forums by Sev_k in this thread: Getting the Most Out of your NI Linux Real-Time Target
Therefore I propose to simplify this implementation and open the support for Python3.
Some additional implementations are essential for the success:
- Selection of Python runtime should be fixed to python3, since python 2 will be without further support or active development from 2020-01-01 going forward.
- It would gain the best momentum if it was possible to deploy python from the Device Software installation as part of the build specification of the real-time application.
- Python developers can specify their external requirements for additional code by defining a "requirements.txt" or "pipfile.lock" depending on the virtualization method and choice of development style. If the project manager or build specification could read/parse this for the starting point of the application to prevent manual labour and possible errors.
Support for this should be from LabVIEW 2018 and forward, since these have support for the python nodes.