From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Real-Time Idea Exchange

Post an idea

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.

Backwards Compatibility:

Support for this should be from LabVIEW 2018 and forward, since these have support for the python nodes.

Best Regards

Jesper

View All (1)

View All (3)

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.

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.

View All (4)

right now version 3.10 of CMake is available in the OPKG, but some libraries need CMake 3.12 or higher to build. The current version of CMake is 3.21

The way to update CMake is to follow this short tutorial

1. Make sure you have you device prepped with the following commands:

opkg install packagegroup-core-buildessential
opkg install cmake
opkg install openssl-dev

2. After this we're going to download the latest version of cmake from their download page: https://cmake.org/download/

Select the Unix/Linux source and copy the url

3. Create a build folder on your home directory and move into that folder to download the cmake source and unpack it there

mkdir build
cd build
wget https://github.com/Kitware/CMake/releases/download/v3.21.1/cmake-3.21.1.tar.gz
tar -xf cmake-3.21.1.tar.gz

4. Go into the source folder and run the bootstrap file

cd cmake-3.21.1
./bootstrap

5. After completion you can run make

make

6. After compiling you can install it

make install

7. Check the correct version by executing

cmake -version

View All (1)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

LabVIEW Real-Time Idea Exchange

Python Node support on LabVIEW Realtime systems

Update and extend NI System Monitor

update the SQLite version available via opkg

Add LabVIEW UNZIP to the RT target

CAN slave interface - with CANOpen Slave API

Visual Studio 2010 Support

Allow Shared Variable Engine on RT target to act as OPC-UA server

Update the CMake version in OPKG

HDF5 library via OPKG

Support for OPC UA NodeSet files