LabVIEW Real-Time Idea Exchange

Currently, when you add a new (not existing) cRIO controller and chassis to a LabVIEW project, there is no check as to whether this is a valid configuration or not. For example, you can successfully add a cRIO 9072 controller with a 9112 chassis to a project, even though the 9072 is a controller with an integrated chassis. I believe that the LabVIEW Project interface should notify the user (via dialog box) that this is not a valid configuration before they can add modules and start developing code to use an invalid configuration.

I think this would be a good option since I have run into the problem during debug where a previously used Network Stream did not get destroyed and then when the code tries to reopen the stream you get an error that the stream is still in use.  Since the refnum is lost there is no way around this dilemma.

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.

Hello,

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,

Cu

Westgate

Every Fixed-Point number allocates 64 bits (8 bytes) or 72 bits (9 bytes) if you include an overflow status. Working on a cRIO project that I need to acquire and save a large amount of data to process later when the RT CPU has free time to do it (is not acquiring more data nor transmitting data). Since the data is acquired in 12 channels, 51.2 kS/s, with 24 bit each point, the fixed-point allocates 64 bits but uses only 24, wasting 5 bytes (62,5%) for every single data point acquired.

As a workaround, I developed two VIs one to compact the data removing the 5 unused bytes of every Fixed-Point, number keeping the 3 bytes with the data. The second VI does the reverse job. With this I reduced the information to 37,5% of the original, saving space and time to save the information in non volatile memory. Maybe there's a way to do it directly, but I didn't figure it out.

My idea is to add, in some way, the possibility to use the minimum amount of bytes needed by the data, at least for storage purposes. It would be nice if NI add an option to have fixed point in two memory allocation modes:

• Standard: the current way with 64 or 72 bits (probably faster)
• Packed: the number of bytes allocated will be the minimum to hold all information. For a 16 bits data the each data will use only 2 bytes.

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.

If I have variable library with virtual folders and I choose "Export to..." only top level variables are exported to the file. I suppose that also variables inside virtual folders should be exported. I think virtual folders make structure clear and export/import is useful if you are working with several projects in different computers. I would like to see them work together.

The Distributed System Manager does not allow one to see the values for a cluster in a deployed process.  It would be nice to view and edit values in the cluster.

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.

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.

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:

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:

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.

1. Right Click on Blank Cursor Column will crash DSM

2. Make cursors Max and Min actually work

In the Distributed System Manager add the capability to export Historical Data.

Also, in the DSM Allow Historical Traces to be deleted.