LabVIEW Real-Time Idea Exchange

Top Authors

User

Kudos

Post an idea

LabVIEW provides an interactive front panel when running an RT application in the LabVIEW development environment. However, once you deploy this front panel is no longer available. I think it would be helpful to make the front panel look differently or somehow give a visual warning/indication that this is a debug feature and will not be available at deployment. (This could be something as simple as a watermark, similar to the evaluation watermark that LV employs). Many new users get confused and run into problems by using lots of front panel controls/indicators and then finding out later these are not applicable at deployment.

In some critical installations, it is absolutely unacceptable for the cRIO to be able to "go to sleep" (as it can do now) and be unreachable via its Ethernet connection, especially when it runs out of real-time in the software. Currently when a cRIO becomes unresponsive, it requires manual intervention to kill power, push buttons, and/or set DIP switches, etc. to bring it back to life. Our company is dealing with cRIOs that are located in places that are very difficult, expensive and time consuming to reach.

I strongly recommend that NI add, Ethernet accessible, hardware based reset/restart functions to the cRIO. These functions should be completely separate from current cRIO software and hardware and should allow remote control of the cRIO power supply, and setting of the dip switches and reset buttons mounted on the cRIO front panel. NI-MAX should be enhanced to allow a user to remotely control cRIO reboots via these functions.

Many networks have NTP (network time protocol) time servers locked to a GPS signal with claimed accuracy of better than 1 millisecond. NTP seems to be the de facto standard for distributing accurate time to systems accross a network. I would like to see a VI that can use this widely available protocol to set the system time with as much accuracy as possible. The RT Set Date and Time VI only permits specifying the time down to 1 second.

A forum contributor has provided a VI to read the NTP protocol, but uses the RT Set Date and Time VI to set the RT target system time losing any resolution beyond the second. This VI eliminates the greater precision available using the NTP protocol. The contributed VI also does not implement any of the advanced algorithms to improve the accuracy of using NTP over a network which are described at NTP.org and at links that may be found there.

Very tight synchronization (millisecond or better) of many RT targets is possible when the NTP protocols are fully implemented. I need accurate millisecond resolution on many RT targets over a wide (several thousand square miles) area. These RT targets recieve their data streams via radio telemetry so signal propagation time over the area is essentially zero. Processing of the data relies on the relative accuracy of time-tags generated at multiple sites.

View All (3)

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.

Update and extend NI System Monitor

One common request for production systems is some kind of monitoring/surveillance.

The current NI System Monitor 1.1.1 lacks official support for the recent LabVIEW versions and the most recent RT controllers.

For an updated version I would love to see some kind of S.M.A.R.T. support (including wearout indicators for SSDs).

If the access of the S.M.A.R.T. is technically not possible during normal realtime operation, then it would be nice to get that feature when running in save mode.

Android target option for TPM

I know there has been some discussion in other areas about an "Android build" of LabVIEW, but I am thinking specifically about the Touch Panel Module. An option to target and deploy an HMI onto a low-cost, readily available Android tablet would be tremendous for RT projects, in my opinion. I've got 2 different projects right now that require expensive Win7 tablet PCs, but all they are doing is running a custom LV application to be used as a basic HMI, which is complete overkill. I know the webserver is an option, but it has some limits, and I'd like to have multiple varieties of HMIs available to show varying degrees of system data and performance, which gets dicey with a webserver situation (at least, in my experiences so far).

It just seems like expanding the TPM so that it's keeping up with the times (Android and iOS dominance) seems like a win/win for NI and developers.

View All (3)

If you right-click on the RT target in the project and select Utilities you can:

-View in system manager

-View in browser

-etc...

It would be useful to have a View in FTP Client there as well. I seldom need to access the web interface, but I often want to delete files prior to a new deployment e.g. and this would be a quick way to do it.

Yes, you can use the web interface to access the files as well, but that's much more cumbersome than to just open an ftp connection.

If you try to select "Run As Startup" before having built the application you are stopped by LabVIEW with the phrase "The Real-Time application has not been built. You must build the application before deploying."

This is bad behaviour. Instead LabVIEW should silently do the requested task, including any prerequisite ones (the build), or at least offer me to grant it access to do so. The Run As Startup choice already includes the deployment option (no complaints from it if I have not done that yet), there is no reason why it could not do the build as well.

I've been attempting to perform a relatively simple homing routine on a motion axis where there are two limit switches (forward and reverse) and a home switch located somewhere in the middle. The homing routine starts by advancing forward and if it does not see a home switch, it will continue in the forward direction until the forward limit switch is activated. At this point, the routine will reverse the direction of motion and continue searching for a home switch until it would eventually see it (thus it is guaranteed that the home switch is found.) Once the home switch is activated, the routine performs a fine tuning procedure by slowly backing away from the home switch (in the forward direction again) until it is no longer active.

When using a c-series servo interface module, there is a Stop Mode property that one can set for each limit switch to either stop immediately, decelerate or disable the drive (See fig. Axis Properties and Limit Stop Mode ). When the stop mode is set to Disable drive, the homing routine fails upon triggering a limit.

There are property nodes available to read the stop mode however the nodes are read only. (see fig. PropertyNode)

It would be nice to have the ability to programatically change the stop mode depending on the motion being performed. Our application requires that the drives be disabled upon activation of any limit switch under regular motion. However, during a homing routine since the disable drive stop mode impedes the routine, it would be benefitial to be able to change the stop mode to decelerate for the duration of the homing routine, and then change it back to disable drive once homing is complete.

Convert RT front panel into host VI

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.

I have been recently tasked with porting a Windows DLL to Phar Lap. So, code is not my own, there's a lot of it, and the DLL is crashing with stack overflows. Recursion is not a problem here, so it's obvously a local variable space. The default thread stack size is 128k, which is a bit on the low side. An ini setting that would allow to increase this would be most welcome. Especially if you're not getting errors in your own thread, but in the LabVIEW ones.

I need a simple way to stop, from a PC, the startup application (if any) running on the RT system. This would work without prior knowledge of what is running on the RT.

This could be VI based solution that I could use in developing a startup upload application.

This would allow me to FTP new application files to the RT system as new startup code. Currently, if there is a startup application running on the RT system I cannot replace the application file since it is in use and I cannot stop the application without having access to the LV development system. I want too make this upload process into a user run software application for a PC connected to the RT system - without the user having access to the LV development software.

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.

I'd like to create a timing source from an RT FIFO reference to drive a timed loop. The timing source would tic whenever there an element is placed into the RT FIFO, facilitating a timed loop to be configured for reading elements from the RT FIFO as they become available. This would only be available for blocking mode on read. Once the loop awakes, the user can then read the FIFO with a 0 timeout to get the data.

This would provide all the nice features of timed loops to loops that need to be timed by data showing up in the FIFO. Right now you have to place a while loop that blocks on the RT FIFO and wrap it in a timed sequence for CPU assignment and priority.

Also, combined with the idea posted for multiple timing source for a single timed loop, could be very powerful.

View All (6)

I propose having the timed loop accept one or more timing source(s). The loop would wakeup and execute if any of the chosen timing sources tic'd. If multiple sources tic'd, then the 1st timing source would execute first.

This would ease the creation of more complex timing schemes on the host. For example, application needs to wake up every 50ms and whenever a timing source tics. Both wake up events need to operate on the same data and neither should happen at the same time. Typically this means you write two timed loops and a lot of handshaking overhead... or a single while loop with a lot of timing structure built into it and probably encompassed by a timed sequence structure so you get priority and CPU assignment.

All of this would be much easier if a single timed loop could handle multiple timing sources. All of your data would be in the same shift register(s) and you don't have to write any handshaking code to prevent simultaneous execution.

Obviously the GUI for this would be somewhat complex, but for the programmatic inputs you can simply turn most of them into arrays.

View All (5)

LabVIEW Real-Time Idea Exchange

Warning or different look/feel for RT front panel

cRIO Remote control of reboot or restart

Allow setting RT target system time using NTP time server with high accuracy

Dual ethernet ports should have identical features

Shared variable export to .csv should work with virtual folders

Update and extend NI System Monitor

Android target option for TPM

Connect to FTP server option under Utilities

Make it possible to select "Run as Startup" without having to build the app first.

Windows 7 64-bit Driver for Reliance File System

Have the ability to set the stop mode for a limit switch from within LabView for NiSoftmotion

Convert RT front panel into host VI

Add ni-rt.ini setting for thread stack space

Add LabVIEW UNZIP to the RT target

Add Reliance NITRO to the list of supported file systems

Ability to programatically stop any application running on RT system

Don't suspend the TCP thread when RT gets busy

Create a timing source from RT FIFO reference

Drive a timed loop with multiple timing sources

Control Reference and Property Node Support in Built Executables