From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com 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

Post an idea

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)

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.

View All (6)

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:

http://digital.ni.com/public.nsf/allkb/BE80D012BB933B54862572D6004FE5F9

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

Here are some benchmarks that we obtained:

	Size (kB)	Time	MB/sec
Laptop to USB	55,535	14	3.97
Labview Copy VI Laptop to USB	55,535	14	3.97
Laptop FTP to RT	55,535	17	3.27
Labview Copy VI RT to USB	55,535	73	0.76

I was replying to a message thread someone had about question marks showing up for the times in the I/O channels for a compact Fieldpoint system. While investigating, I notice on my system that I had timestamps for data that occurred later in the day than the current time. So I know those timestamps were from a day prior than the current day. Actually, the test stand had been idle for quite a few days, so I pretty much know those I/O channels had not been updated for a while. But I could not tell from the timestamp when exactly that data was from.

In the attached screenshot, the current time was about 1:44 pm. Some data shows it had just been timestampled. Some data was from 7am, other data from 2:19 pm or 4:19 pm. I know that that data had to have been from yesterday or older. The 7am could be from today or older, but there was no way to tell. Based on my usage of that test stand, I'm pretty sure all of that data is at least 3 days old, and perhaps 6 or 7 days old. That is okay and not a problem. But there is no way of knowing how old that data actually is based on this screenshot.

I think MAX should show the date as part of the timestamp when looking at the I/O data.

Message Edited by Ravens Fan on 10-20-2009 11:48 AM

Message Edited by Laura F. on 10-22-2009 01:32 PM

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

View All (5)

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.

The Set System Image VI (and by extension, the Replication and Deployment Tool) have a deployment blacklist. Currently, files on that list are never deployed. It would be helpful if instead, those files, if they exist in the image, were deployed only if they do not already exist on the target. That would make it easier to create a single image that could be used for both an upgrade, where you do not want to overwrite existing configuration files, and for initial setup, where you want to install a default configuration file.

Did I misunderstand something about the way the deployment blacklist works? The documentation says "Files on the blacklist will not be copied from the image to the target" which makes me wonder why you would ever want to include those files in the image at all.

The RAD tool is not a perfect fit for all cRIO deployments. If you are unable to use the RAD utility to deploy a new version of drivers to the cRIO the process to get the Network Variable Engine onto the cRIO goes something like this: Install LabVIEW and LabVIEW Real-Time, install NI CompactRIO drivers, install NVE and other driver software to the cRIO and then uninstall the LabVIEW components from the host PC. This assumes that an executable will be installed to the host computer as the UI to the cRIO. Seems like a lot of work for something most people would be using on the majority of cRIO deployments and might assume is a part of the CompactRIO drivers.

At the very least it would be great if the documentation found on the website were explicit as to what software needs to be installed for each of the install options available to install on to the cRIO.

When using the "Open FPGA VI Reference" function you can configure it to reference the FPGA build/bitfile in three different ways:

- Build specification

- VI

- Bitfile

In development mode I often use "Build spec", for deployment I switch to "Bitfile". When using this function it behaves different, depending in which mode it is configured! This makes for a bad "User eXperience"…

In "Build spec" mode:

- when double clicking the pink border of the function it opens the referenced FPGA VI

- you need to right-click the "Open FPGA VI reference" and select "Configure…" to open the configuration dialog

- when selecting the "Build Spec" radio button it opens a selection dialog (probably a listbox) but you can't double click the build spec you want to use, you need to select the build spec and then click on "OK" button

In "Bitfile" mode:

- when double clicking the pink border of the function it opens the configuration dialog, (you don't need to right-click the "Open FPGA VI reference" and select "Configure…" to open the configuration dialog)

- when selecting the "Bitfile" radio button it opens a file dialog and but you can double click the bitfile you want to use

(All this relates to LabVIEW2014SP1. Haven't tested this with LabVIEW2015 so far.)

I propose the idea to make this behaviour consistent, independent of the selected mode in the configuration dialog!

I wish this behaviour:

- double click on pink border of the functions opens the configuration dialog

- double click on the FPGA VI icon shown inside the "Open FPGA VI reference" function opens the FPGA VI

- double click on an item in the "Build spec" selection dialog selects the build spec

View All (2)

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

Drive a timed loop with multiple timing sources

Real time display

Support events for graphic objects in RT target VIs

Improve performance of Copy/Move VIs in Labview RT on PXI-8xxx controllers

Get the VI Name in a subroutine

Improve Distributed System Manager Hypertrend Cursors

Distributed System Manager Historical Trend

Can MAX show date as well as time in the timestamp for I/O channels?

Extend RT Web-based configuration and monitoring features to other browser than the dismissing IE

Real-Time data transfer issue, from FPGA to RT

Remote Panel update FP object properties on connection or change (for embedded UI PACs)

Softmotion function "write position setpoint" with Ni 9514

NI USB-232 Adapter should work with PharLap as additional RS232-Port

Set System Image should deploy files from the image that are in the blacklist and don't exist on the target

Support for Real-time Module on Mac OS

Add the Network Variable Engine Installer as a part of the NI CompactRIO Driver software

"Open FPGA VI Reference": change to consistent behaviour

Porting VI from cFP to cRIO?

Add support for the "Exist" function in the Mathscript RT Module for the LabVIEW RTE

New LabWindows/CVI editor based on eclipse