From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, 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

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

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.

A number of times, I have found the Real-Time Clock configuration screen in Measurement & Automation Explorer to be very limited. With only the options to set the Time-Zone/Daylight Savings Time/UTC, I feel like there could and should be more!


Adding a feedback to show what the current RTC is set to similar to the Windows Clock configuration would be GREAT! Additionally, add the functionality of the RT Set Date/Time VI to Measurement & Automation Explorer.


We frequently run into issues where the Daylight Saving Time value is different between the US and the rest of the world (frequently=twice a year).


I believe all of this can be resolved by adding 1 layer of abstraction to translate a base RT system clock to the user-specified specifications to be added to timestamp data, schedule tasks, and so-forth.




it would be very nice if i could give users in the Web-based configuration more specialized filesystems rights.

In the moment i only can give the user the right to write on the whole filesystem or on nothing.

In my case i would like to sent our customers updates of the startup.exe, which they can install their self via ftp. Without them having access to everything on the filesystem.

Please vote if you would like to have this option,





I understand that the FE vi's needed to be optimized for speed so that they could be put inline without disturbing RT timing.  But it would be nice to be able to send a string description

with the fault so that it would show up in the DSM.  An example would be a fault due to trying to send an invalid remote message.  It would be nice if the invalid message string could be logged with the fault event.

I think making it optional would still preserve the determinism when needed.

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.

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.

Ability to create a GUI (with touchscreens) using the graphics capability on desktop PC's. Maybe something like PEG (portable embedded GUI). For small testers, I don't necessarily want a PC or touchscreen PC running CE or XPE. The PC's involve a lot of setup, virus concerns, etc that I don't need on some testers. Support would be much easier also. Plus, in a lot of organizations, they don't understand the difference between PC's for desktops and PC's for production stands. You end up getting a "standard" PC with a lot of restrictions on it that requires several different groups to support when it fails.

At the moment Labview RT does not support high speed USB 2.0 (EHCI) functionality on PXI-8xxx controllers even if the controller has supporting hardware.  We implemented a copy operation to transfer data files from a harddrive on the PXI chassis to an external USB connected flash drive using the copy VI, and only obtained speeds at USB 1.1 (OHCI) levels.  We also tried a move version using the Move VI with similar results.  The controller used in our tests was a PXI-8186, which has USB 2.0 ports.


My discussions with NI Support and the R&D team indicate this a limitation imposed by the ETS RTOS from Phar Lap that Labivew RT runs on.  This is inline with the fact that VxWorks supported controllers have access to EHCI speeds as per this faq:


Could we get high speed USB support implemented in Labview RT/ETS?


Here are some benchmarks that we obtained:



Size (kB)



Laptop to USB




Labview Copy VI Laptop to USB




Laptop FTP to RT




Labview Copy VI RT to USB




VI Server nodes are asynchronous nodes.  I would like to be able to get the VI Name in a subroutine.  This could be done now with an XNode. Or, it could be a compiler optimization.  Since VI Server nodes are a shared resource, they can cause a priority inversion.

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



I think it would be a solid improvement in LabVIEW if the real-time development module and other modules available to the Windows OS are available to the Mac OS.


Some of these modules that are needed are the real time development module, vision development module and CVI.



At my company for all of our real time work, we are starting to use Veristand a lot. It is great that there are so many already available primitives on the Veristand palette within labview which are very useful. However, there is currently no Veristand primitive in Labview, that actually starts the Veristand.exe program itself. You have to use the System Exec to do it. I think adding a Veristand primitive that performs this function would be great.


RT Engine it does not include the front panel in built executables, see link. Control references are only supported when the development system is connected to the RT target. It would be nice if there was an option to keep the front panel in some of my VIs when built into an executable and run without a user interface.  This can be a powerful tool.  One could parse a cluster and creating files based on properties of controls.