LabVIEW Real-Time Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

When creating an image of an RT target e.g. we currently rely on it to be able to store a temporary copy of the image prior to transfering it to the host PC. This can often cause the operation to fail (especially now that system images are way bigger than before) because the target does not have sufficient storage. If you have an application/config that is large too and you want that included in the image this requirement can mess thing up too.

This could have been avoided by streaming the image data to the host instead, with little or no intermediate storage.

The new web interface offered when you install a system image to an RT target is very rudimentary, it offers almost none of the configuration options that we had in the Silverlight-based version. You cannot edit the network card settings, you cannot change the date and time etc. All it does is refer you to use NI Max, which kind of defeats the point of having access to basic config without the need for anything but the web browser.

 

Are there any plans of an update to the web interface any time soon? 

As MS windows plan to dismiss IE in the next years ,

 

It should be very useful to have the same  Web-based configuration and monitoring features to other browsers or App than IE

 

in order to have an easy controlled access to RT file system , RT external storage devices , Event log and so on also in pc without any NI software installed ( MAX , ecc ).

 

Alternative methods today are not as easy and all in one as IE.

Hello  Everyone, 

 

I apologize if I repeat this topic, but I need help with a particular application. I have read a lot of discussions but it seems that I don't find the solution.
I have a cRIO-9068 with 5 modules of analog inputs (NI9215), and I'm using the Labview '13.
I have to read in real-time simultaneously 6 signals (3 voltages and 3 currents) and save them on the PC. The saving process works fine (I'm saving the data using TDMS functions), but I have an issue with data transfer from FPGA to RT VI. I don't know why, but no matter what I do, I don't read all the data, or I read them wrong. The FPGA reads all the 6 channels once at 50us (20kHz).
The FIFO settings are: -Requested number of elements: 1023; -Data type: FXP, Signed, 26bits/5bits.

 

I have attached both programs (FPGA and RT).

 

I will be grateful for any guidance or advice! 

I wish you the best!
Martin Adrian.

RT VI.png

FPGA VI.png

 

propose to integrate filter function when adding RT target with Scan Interface into project. disabled by default but can be enabled and configured (type, frequencies, method, etc) in edit mode or programmatically through DSC 

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

There are 2 LabVIEW libraries available to create HDF5 files, the problem is, there is no version of the HDF5 library available for NI Linux RT systems, so everyone that wants to use this, and doesn't have enough experience to build the HDF5 library on their own can't use this.

Sorry if this is a duplicate idea I searched and couldn't believe it hasn't been posted.

 

This idea is to add Linux RT deployment support for desktop PCs.  NI in the past has had a process for purchasing an Phar Lap RT license, then deploying it to a normal x86 based PC.  Here are the System Requirements, and a manual.

 

This opened up the door for desktop PCs to become embedded PCs, controlling NI hardware, but allowing for an upgrade path where embedded cDAQ devices, and even PXI controllers don't have many options.

 

At the moment there are unofficial ways to get Linux RT on an x86 based desktop with limited success, but no support.  These options are outlines in the comments of an idea to allow for a VM of the Linux RT environment.  NI could go with a similar route to Phar Lap and sell a license with a list of supported hardware.  

A recent forum post discussed possibilities for "Securing a cRIO":  Securing CompactRIO, and identified that LabVIEW project access allows the project to upload new rtexes without a password.

 

You are then prompted for a password to reset the cRIO, but this can be somewhat similarly achieved with a screwdriver and the reset button... (of course, this assumes physical access to the cRIO, whereas project access does not - but I suspect in the forum users' case, the two were approximately equivalent).

 

Would it be possible to move the login prompt before the new rtexe and accompanying files are uploaded, rather than for the restart?

I can currently write code that uses the SysConfig Restart VI to run some cleanup operations and then shutdown a cRIO.

 

However, if I rebuild my startup application in LabVIEW, and then want to deploy it (or want to restart from MAX) then I have no easy way to call this code when restarting - the cRIO restarts and any handles are left open/half-open until the other end clears them up.

 

Could we have the ability to register a shutdown VI that is called whenever the target is programmatically restarted (e.g. by LabVIEW's Project Explorer or MAX)?

I understand that in the case of failure and a hard reset via the Reset button then probably this is impossible/implausible, but in the "normal" workflow, this would be a useful addition.

As explained in this post, the most recent version of SQLite library via opkg is 3.22.

 

This version is so old that it doesn't support all the features available via the SQLite Library publish by Dr Powell.

 

as explain in the post above, compiling a newer version from the source code available at sqlite.org is doable (I did it for v3.34).

Please support UEFI and newer processors such as i9 for deployment. If possible, changing from PharLap to Linux is also preferred.

Currently, non default map constants (like the one shown below) are detected as fatal insanities when deploying to Real-Time targets and crash the LabVIEW development environment.

tannells_0-1581614386711.png

There is a workaround, which is to build the map from other data structure constants. The map constant above was built from the code below. However, it takes longer to execute, and it takes more code. That is okay in some cases, but it would be better if there was an option to simply use the map constant above.

build map.png

 

Hello LabVIEW Enthusiast,

 

NI has introduced malleable VI function since LabVIEW 2017. It is a great function to have in advanced LabVIEW application development.

But "Stall Data Flow.vim" function is missing in Real-Time Target OS from timing function palette since 2017.

It is not like you can not use malleable VI in RT side, I have copied same VI from desktop VI to RT VI. It works fine without any error or broken arrow.

 

NI should include this types of VIs in RT package by default.

RT has Type Specification Structure too, which creates question for me on this missing VI.

 

If you have any reason(s) to share on this why it is not included on RT side, Please share your thoughts.

RT Side.JPG

Host Side.JPG

Thanks,
Vinal Gandhi

Download All

Could we have SSL on by default in the standard software sets for RT targets? It is not like there is much security in the default setup anyway, so having SSL active as well as the web interface with default passwords is just more practical (if that is the rationale for not having it on...(?)).

Background:
Whenever I have loaded a default software package onto an RT target using NI MAX, I run into this little snag; I try to log onto it using SFTP or PuttY - only to rediscover that this is disabled. So then I have to go to the web interface or NI MAX to enable it. Most of the time we use RAD to replicate PACs anyway, but this is still another little thing we have to remember every time when dealing with the very first setup.

cRIO with embedded UI enabled allows us RTEXE front panel interactivity, with the ability of front panel objects' properties being changed programmatically. However, when connected with PC via Remote Panel, only object values are updated, but not the objects property (for example: table headers string arrays). This could lead to miscommunication of information as the Front Panel from embedded UI differed from the Remote Panel. 

 

I was informed though, if we looped the write property node continuously, the property can be updated from the Remote Panel end. This, however is counter-intuitive as we usually initialize the GUI objects programmatically once at the beginning (or if necessary due to change) and not continuously. Nevertheless, if Remote Panel can update the front panel objects during first launch and property change, similar to "Is Value Changed.vim", that would be great feature to have.

Softmotion 2018 disabled the function "write position setpoint" for a NI 9514 module axis.

This was a useful function and will always be useful. ex.: Application like a tracking system need those functions.

 

Please put it back. Stuck with LabVIEW 2016 and windows 7 now.

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

LabVIEW Real-Time 2018 on a PXI target with PharLap does recognize a NI USB-232 adapter as a USB-RAW device.That's bad. (e.g. you can't set Baud rate etc.)

 

It should be recognized as an additional RS232 port like VISA "ASRL3::INSTR".

(like same way, when I connect the USB-232 adapter to a Windows-PC)

Hello,

It would be nice to add a filename Check in the Crio executable process generation, in order to detect accentuated characters !Smiley Happy

When you use accentuated file names, the generated Crio Linux executable does not work ... it crashes without any message !!! Smiley Mad => NI Linux does not support accentuated file names !!!

=> The problem is that the Debug mode works fine, and doesn't work like the executable !

 

It should be nice to add a file name verification to the generation processus in order to highlight the problem .   Smiley Wink

 

Thank for your help.

 

Manu.