Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
Watch as the community gives your idea kudos and adds their input.
As NI R&D considers the idea, they will change the idea status.
Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
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.
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.
The SVE on a windows based platform acts as a OPC-DA server. Due to the requirements for DCOM, this is not possible on real-time target. However, as OPC-UA is gaining traction, I would find it very useful to have the SVE act as an OPC-UA server for integration with 3rd party systems (SCADA, IIoT).
I know that there is the OPC-UA API palette, however, this takes more time to setup than creating a shared variable (i.e. a tag) and moving on with the application development. If update rates are slow enough (500-1000ms), I have found the shared variable to be more than adequate for my applications (500-800 NSVs), so I'm not looking for granular control over how I send data out of the cRIO system. Ease of use is my primary concern.
We could solve a lot of our designs with sbRIO and LabVIEW RT if the sbRIOs' CAN interface was designed to be a slave, and there was a DS301 compliant CANOpen slave API available for LabVIEW RT.
I'm a bit surprised that only the master side is covered today, as I'm sure a lot of people will utilize sbRIOs in devices that are more natural to define as slaves, not masters.
Throw in a dual set of equivalent network interfaces and the sbRIO platform and RT is an ideal platform for subsea instrumentation, with SIIS Level 2 (CANOpen) and SIIS Level 3 (Ethernet) communication capabilities, at least as long as the power requirements are kept low.
Similar to NI's Visual Studio 2008 support, it would be great if NI installed the Visual Studio 2010 run time to the Real-Time target and supported it officially with tools such as the DLL checker.
I know that currently, I can statically link in the 2010 run time to my built libraries if I want to run them on RT... but it would be nice to not have to. This would also enable products like LabVIEW Simulation Interface Toolkit and NI VeriStand to officially claim 2010 support on their readme's... as by default the make files used by these NI products do not statitcally link in the run time and I have to hack the make file to enable support.