LabVIEW Real-Time Idea Exchange

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

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? 

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.  

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

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).

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.

Scenario

Suppose that we want to start coding my Real-Time application, but the hardware hasn't arrived yet.

 

We can't Discover the chassis + modules, so we need to add modules manually.

 

 

Current editor

cseriesedit_old.png

 

To add N modules, we need to launch this dialog N times:

 

  1. Right-click on Chassis in the Project Explorer
  2. Hover over "New"
  3. Click "C Series Modules…"
  4. Click "New target or device"
  5. Click "C Series Module"
  6. Click "OK"
  7. Wait for LabVIEW to fetch module list (wait ~1 second)
  8. Select Type (2 clicks)
  9. Select Location (2 clicks)
  10. Click "OK"
  11. Go to #1 to add a new module

 

How tedious!

 

 

Proposed Editor

Wouldn't it be nice if we could set up all the modules in 1 dialog?

 

cseriesedit_proposed.png

 

Features

  • Table auto-fills itself with modules already in the project
  • Number of rows is determined by the chassis model. No need to select Location
  • Ability to leave rows/slots empty
  • Editable Name field (with default name) appears upon selecting Type
  • Description appears upon selecting Type

 

 

Feel the difference

Adding N modules (using default names) requires...

  • Current dialog: 10N clicks, N hovers, waiting N seconds
  • Proposed dialog*: (6+2N) clicks, 1 hover, waiting 1 second

 

So, adding 8 modules requires...

  • Current dialog: 80 clicks, 8 hovers, waiting 8 seconds
  • Proposed dialog*: 22 clicks, 1 hover, waiting 1 second

*Assuming that steps 1-7 and 10 need to be performed once

 

64bit has been the dominant architecture for a decade; any computer with more than ~2.5GB of RAM must use it after all. It is inevitable that 32-bit machines will cease to be made - maybe not tomorrow, but let's be realistic. Let's get ahead of the times and convert modules to support 64 bit support. Please!

 

 

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

 

Hi,

 

I noticed there seem to be no way to guarantee the state of an output module controlled by a scan engine in case the RT Application (or the Host Application, depending who is controlling the chassis) crashs. With FPGA one can program some kind of watchdog setting back the output values of a module in case the RT Exe fails. With Scan there just seem to be no possibility.

 

This is why I think adding a FailSafe Value for a Scan I/O node could be a creat idea. in ase the RT application got aborted  or stops  without cleanup, the output value would not be random no more but set back to their FailSafe value. I imagine it could look like that:

 

failsafe.png

 

What do you think about it?

The real-time controllers have a "Time server" IP input in their setup. That is great, but it is not great that the time server has to be a piece of NI software (Logos). If it was possible to specify an NTP server for example (and/or other standard protocols), this feature would be much more useful.

 

Most of the time we need the PACs to be synced with a third party system.

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

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
It is allmost impossible to find errors in "Reentrant SUBVI's" without the debugging possiblities.
 
 
 
 

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?

During LabVIEW Development was a PXI Real-Time System connected (LAN) next to my Laptop and process Build/Deployment was no problem.

Now the RT has been shipped far away to customer site and i have no longer access to that network.

 

So I need an other way to distribute and

here is my IDEA #1:  (below is another IDEA #2)

 

Offline RT-Distribution LabVIEW Idea Exchange.GIF

 

FACT : Most of all customers have no knowledge about "How to find the Real-Time System and update the Application on it".

 

So the new item will built an "Offline Installer.exe" and will run on any customer PC to a full automated update job automatically.

 

Features:

 - create a detailed installation report which can be stored and send back to the developer.

 - In case of the Real-Time System isn't connected to any LAN, the customer could use the "Offline Installer.exe" to prepare an USB-Stick which has to be plugged into the Real-Time System. Then a reboot will launch the full automated application update process. (the "RT LEDs" will give feedback when the process is finished)    

 

 


 

I tried also another way but without success:

 

Step 1: Add a ZIP File into the Project Explorer : "My Zip File"

Offline RT-Distribution 1.GIF

 

Step 2 : Configure the "My Zip File" => Add "My Real-Time Application" 

Offline RT-Distribution 2 zip.GIF

 

Step 3 : Build "My Zip File"...but the Result was bad :

Offline RT-Distribution 2 Build My Zip File.GIF

 

But anyway, if the would be successful there are a lot of more steps needed:

 - sending the ZIP to the customer

 - unpack ZIP

 - find Real-Time System at customers network

 - a FTP tool is needed to update the system.

 - There is no way to stop the running Application (from a PC without NI-Software)

 

Conclusion:

The update with "ZIP" is far away from a comfortable solution. 

 


 

IDEA #2

If the Real-Time System has a running webserver (the thing which is using Silverlight),

then the application could be updated by using a webbrowser.

So, first we have to update the webserver on the Real-Time System (as difficult as updating the application)

 

Spoiler
(But who the f..k has Silverlight installed  )

 

 

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.

Many measurement and process control application run at relatively slow rates (<100Hz). Using SCAN Engine on the CompacRIO for data acquisition is ideal for these applications because you don't need to program the FPGA and all the measurement and control logic can be implemented on the Real-Time controller.

 

 

In many cases you want to process your data before you analize it. Currently you only have the ability to get the raw measurement data from the AI modules, so you need to add the data processing code to your existing LabVIEW program. It would be helpful if the SCAN engine could offload some of the data processing (ex. lowpass filter or sample average) to the FPGA and provide the user with already processed data. For example, this functionality can be added to the module configuration page:

 

SCAN Engine.png   

Dual network interfaces is often part of the requirements for redundancy, however in such cases it is also very common to specify that the behaviour of borth of these should be identical. You see it in subsea control systems where they have an "A" and "B" channel, you see it topside where the device might need to be on two networks etc.

 

Unfortunately this is not the case for any of the dual port RT targets from NI. The secondary port is really a second class NIC. It has limited configuration options. It does not support DHCP, you cannot specify a gateway for it - and the code to do programmatic changes to its configuration is not easily available.

 

Please make the two ports fully interchangable. Port 1 or 2? It should not really matter which one you use.

 

 

When running a VI in development mode while targeting an RT device, you must "Save All" prior to deployment. This is annoying, especially when using SCC. I'm sure that SourceOnly will minimize this effect in LV2010, but the concept still remains: I don't want to be forced to Save All when I don't want my edits (or automatic linking edits) to persist.

Currently, on the cRIO-903x series controllers, the Chassis Temperature and the USER1 push button are only available on the FPGA http://digital.ni.com/public.nsf/allkb/75E039282A8B691886257E450049C7B6 and require the chassis to operate in a Hybrid Mode in order to use both the Scan interface and those chassis I/O options.

 

The cRIO-902x series allowed for both of these I/O options to be accessed in the real-time OS directly. This small feature would add convenience on the cRIO-903x series controllers.