LabVIEW Real-Time Idea Exchange

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?

View All (3)

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.

View All (3)

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.

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

View All (4)

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

View All (1)

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?

View All (3)

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.

View All (1)

I really miss the ability to debug reentrant VIs in LabVIEW real-time. Currently there is no way at all, short of indirect probing by programming your own debug functionality (logging of some sort).

I understand there are inherent difficulties in this, since LV RT systems are typically headless, and definitely GUI-less (except for maybe www-access).

But, maybe if we had a way to send a BD reference to a Host PC, the block diagram could be opened there? Something like an Open.BD method with a "destination" input on it? Then the reentrant VI could open its own BD on another LabVIEW instance running Desktop LV.

View All (4)

Sometimes, you really just want a RT front panel. Of course, there is no real front panel, but when you run in interactive mode Labview is automatically setting up network communication to pull data from the RT target and push data to the RT target. Wouldn't it be great if you could just convert that whole front panel into a basic host VI? Right now, you have to manually convert all controls and indicators to shared variables. Granted, this does force you to be very careful about limiting the number of network-shared items that you have, but sometimes you really just want to run the VI in interactive mode...but deployed.

Or, better than that, convert everything into a web service and automatically build a silverlight UI (using Web UI Builder) which is hosted on the cRIO. Anything that provides you with a quick and easy way to convert from the rt debugging UI to a basic host VI would be great.

Hello,

It would be nice to had the ability to create more than one RT target in a project with the same IP address.

For the moment, if you try to use 2 same IP address, The LabVIEW IDE don't let you save your modifications !

You may say WTF !!!! The manu has so curious ideas !!!!

My need is for example to had 2 configurations for 1 only RT CRio.

1 configuration in Scan Interface
1 configuration in FPGA interface

Or an other way to use multiples targets ...

1 project linking to Version 1 sources
1 project linking to Version 2 sources

Yopu may say this can be done by using different build specifications.

I will say yes ... But my need is to separate the two versions of LabVIEW sources !

=> 1 project/target linked to an autopopulating folder in version a

=> 1 project/target linked to an autopopulating folder in version b

=> So my need is to be abble to use RT Targets as "Target versions"

=> To be abble to do this ... i need to create multiple targets with identical IP addresses.

Thanks for reading.

Manu.

Given a project topology like this:

Windows PC Host <-> cRIO-9024 <-> NI-9114 backplane <-> NI-9144 EtherCAT #1 <-> NI-9144 EtherCAT #2 which is run in hybrid scan mode, during development I wish that it were possible to, for example, tell the project to run without EtherCAT #2 being physically connected, instead using virtual/simulated IO. As things stand now, when I try to switch from Configuration to Active mode, I get an error saying that "the slave device cannot be found".

More generally, I often find myself thinking that the project explorer needs a good way to "comment out" various pieces of the project without having to resort to "Remove From Project".

On all of the RT platforms, if the CPU maxes out at 100% the RTOS goes through a sort of "load shedding" and begins suspending non critical threads to lower the CPU overhead and hopefully maintain determinism. One of the first threads that gets suspended is the TCP thread which essentially cuts off the RT target from the ethernet and outside world.

While I understand the concept of the load shedding, I believe that if you have the CPU pushed that hard, then your determinism is out the window anyway. Dropping the TCP thread only serves to disconnect the RT system from the development environment or the built application with no real benefit. I have yet to see a single application that was actually able to accomplish anything substantial after the point that the TCP thread was suspended. In most cases, the high CPU usage happens during the development of the application or when something is critically wrong with the setup of the deployed app. In those cases, it wouldn't matter how many threads you suspended, the CPU will still be maxed out.

It is akin to blowing out a match in the midst of a forrest fire.

I would propose that the RTOS be reconfigured to show the TCP thread as one of the critical threads and keep it from being suspended during high CPU excursions OR give the developer the option to turn this feature on or off throgh the device properties.

If you have an RT target set up with a startup application (ready to be deployed in the field), running a VI on it from the IDE should not change anything permanently.

Today (LabVIEW RT 2013), doing this will not just temporrarily stop the VIs running on the target (from the executable) - as you get warned about, but also cause the RTTarget.LaunchAppAtBoot=True line to be removed from the ni-rt.ini. So the startup application will not be launched the next time the device is started up, rendering your device useless in the field. Why?

- We had an incident where we narrowly escaped such a scenario. The RT target was embedded into a cannister that was about to be sealed, but an unforseen issue made it necessary to run a special test on it, with a VI from the IDE. The startup application in this case provides the only way into the system once the cannister is sealed (no Ethernet access, just RS485), so having it no longer start would be a catastrophy. No one expected running the VI would actually change anything permanently. We tested it of course, and saw that it stopped the startup application (and so we loaded an image of the correct setup afterwards to be sure all changes were removed), but it would be much better and more intuitive if no such permanent and fundamental changes occured (if actually possible to implement in a such a way).

I do not know about most people use cases with RT system, but I have the reflex to click the run arrow to test all my VIs. When I am on site and I do have access to the hardware, everything is rosy. But, when I do not have access to the hardware, and depending on the system complexity, I now have to wait up to over a minutes before I can resume working. It would be nice if somehow once I realized my mistake I could notified LabVIEW (right away) to run my VI in the main application instance instead of attempting to deploy it on the missing target.

Alternatively, once I made the mistake once, LabVIEW could automatically run the VI in the main application instance.

I do not know what is the best approach to fix this, but I know that I am very annoyed every time I make that mistake.

The best thing about Pharlap is that it will run dll's like Windows.

Making shared libraries for VxWorks (*.out files) is quite an arduous process if you don't have Wind River software. The GNU toolchain, that used to be the free alternative, does not work on Windows Vista or 7, leaving those of use who have chosen to upgrade out of luck.

It would be great is LabVIEW could provide a way to compile *.out files from the Application Builder and thereby provide more complete support for development on the CompactRIO platform.

View All (4)

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

Allow management of network, date and time etc. in non-Silverlight web interface

update the SQLite version available via opkg

Implement a Shutdown VI that could be called when restarting a cRIO (e.g. from MAX, Project Explorer)

Allow non default map constants on Real-Time targets

"Reentrant VI Debbugging" Support for LV-Realtime

Missing "Stall Data Flow.vim" VI in RT side

Require password to upload RT application rather than to restart

Don't force a "Save All" prior to RT Deployment

Enable Secure Shell Server by default

Native XML support on Real-Time targets

Debug reentrant VI in LV RT

Convert RT front panel into host VI

Multiple RT target in a project, with the same IP address ...

Simulate (or comment out) EtherCAT devices within a project

Don't suspend the TCP thread when RT gets busy

Build on deploy, if necessary

Running a VI from the IDE should not touch the application launch flag

Smart switching to main application instance.

RT target with C-module in Scan Engine mode to include hi & low pass filters as property by default

Support for Building VxWorks Shared Libraries (*.out files)