Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
Watch as the community gives your idea kudos and adds their input.
As NI R&D considers the idea, they will change the idea status.
Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
The real-time controllers have a "Time server" IP input in their setup. That is great, but it is not great that the time server has to be a piece of NI software (Logos). If it was possible to specify an NTP server for example (and/or other standard protocols), this feature would be much more useful.
Most of the time we need the PACs to be synced with a third party system.
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. TheRT 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.
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.
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.