NI Home
Cart Cart | Help
Hello Events Academic NI Developer Zone Support Solutions Products & Services Contact NI MyNI
You are here: 
 NI Home > NI Developer Zone > NI Discussion Forums

LabVIEW Real-Time Idea Exchange

turn on suggestions Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Announcements
The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea
Options
Mads

Support industry standard time server (NTP e.g.)

Status: New
by Active Participant Mads on ‎03-07-2013 02:49 AM

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.

Labels:
  • Timing & Synchronization
dwisti

Setting the time and date with MAX

Status: Completed
by Member dwisti on ‎03-09-2010 08:42 AM
Allow MAX to set the time and date to RT targets
Status: Completed
Labels:
CyberSmith

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

Status: New
by Member CyberSmith on ‎10-02-2011 05:48 PM

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.

 

 

Labels:
  • Timing & Synchronization
StephenB

Create a timing source from RT FIFO reference

Status: New
by Active Participant StephenB on ‎02-10-2011 10:30 AM

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.

Labels:
StephenB

Drive a timed loop with multiple timing sources

Status: New
by Active Participant StephenB on ‎02-10-2011 10:07 AM

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.

Labels:
About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. 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!
  3. 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.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
Idea Statuses
Top Kudoed Authors
User Kudos Count
2
2
1
1
1
View All
By using this web site, you accept the Terms of Use for this web site. Please read these Terms of Use carefully before using any part of this site. Please go here for information on ni.com's copyright infringement policy.
My Profile | Privacy | Legal | Contact NI © 2011 National Instruments Corporation. All rights reserved.    |    E-Mail this Page E-Mail this Page