Choosing a CompactRIO Synchronization Technology

Overview

Choosing synchronization technologies depends on distance between nodes, synchronization accuracy requirements, platform support, technology availability, and more. This article describes synchronization recommendations for CompactRIO and details the breadth of options available on CompactRIO.

Contents

Signal-Based vs. Time-Based Synchronization

There are two types of synchronization:

  • Time-based—All system components have a common reference to time. Events, triggers, and clocks can be generated based on this time. For example, consider a CompactRIO controller that has its time set to 5:05 p.m. Using time-based synchronization, another CompactRIO controller 100 meters away also has its time set to 5:05 p.m. Data points that are acquired on both CompactRIO controllers can be timestamped and correlated together.
  • Signal-based—Clocks and triggers are physically connected between systems using wires or cables. This method is the most precise for components that are close to each other.

 

Timing Considerations Specific to CompactRIO

In CompactRIO systems, it is important to recognize that there are up to three timed components: the FPGA, the real-time processor, and hardware-timed IO points such as NI-DAQmx tasks or DSA modules. Each component has a different clock that needs to be synchronized. CompactRIO controllers that support Time Sensitive Networking and are using hardware-based IEEE 1588 profiles (IEEE 802.1AS or default profile) for synchronization will automatically synchronize these clocks. However, on other CompactRIO controllers, these three components are not automatically synchronized. Additionally, if there is a host application, which typically runs on a PC, the host clock may need to be synchronized as well.

 

General Guidelines

The following table provides a comparison of the synchronization technologies available on CompactRIO, listing the maximum distance allowed between nodes, typical synchronization accuracy, time server requirements, cabling requirements, timestamp support, recommended hardware, and the subsystem that they will synchronize. This table is intended only as a general guideline, and all technologies will be explained in more detail below.

 


Technology

Physical Distance Between Nodes

 

Accuracy1

Global Traceable Time?

 

Cabling

 

Timestamp?

Recommended Hardware

Synchronized Subsystem

Signal-Based5

<100 m

Varies (Refer to the manual)

No

Varies

No

NI-9469, trigger, or NI-9402

FPGA, and NI-DAQmx/DSA3

IEEE 1588 with hardware support (IEEE 802.1AS or default profile)

Within subnet

<1 µs

Optional

Standard Ethernet

Yes

Built-in Ethernet port on TSN enabled cRIO controllers

System Clock, FPGA, and NI-DAQmx/ DSA4

IEEE 1588 with software support (default profile)

Within subnet

1 ms

Optional

Standard Ethernet

Yes

Built-in Ethernet port on all Linux RT cRIO controllers

System Clock

SNTP5

Global (access to NTP server)

10's of ms

Yes2

Standard Ethernet

Yes

Built-in Ethernet port on all Linux RT cRIO controllers

System Clock

GPS5

Global

100 ns

Yes

N/A

Yes

NI-9467

FPGA

IRIG-B5

Varies

100 ns

Optional

Varies

Yes

NI-9402

FPGA

 

 

1This is an accuracy estimate for a typical system. Accuracy varies depending on the system.
2There are a variety of NTP time servers publicly available on the web. A time server is required for (S)NTP synchronization.
3DSA sync only available with NI-9469
4The synchronization of the NI-DAQmx subsystem is only available on CompactRIO with NI-DAQmx controllers
5For cRIO-904x controllers, there must be at least one instance of an NI-TimeSync IEEE 1588 or IEEE 802.1AS time reference running in order for NI-DAQmx tasks to start for NI-DAQmx versions 18.1 and later. This may prevent the use of a 3rd party time reference if NI-DAQmx functions are required.

 

Time-Based Synchronization Methods


In time-based synchronization, all system components have a common reference to time. Often there are no additional cables required between the systems. It also scales easily as more targets are added to the system. The data from the new target can be correlated with other targets on the system once the system is synchronized to a time source. However, depending on your application, you may not have access to a given time source. For example, GPS is not accessible underground.


A)  IEEE 1588

IEEE 1588, also known as the Precision Time Protocol (PTP), is an Ethernet-based synchronization method designed for cabled, local networks. The benefit of IEEE 1588 is that it allows you to synchronize your targets over a standard network. It works by determining a master clock automatically from the network and having all other clocks slave to this master clock*. IEEE 1588 is also a relatively fault tolerant synchronization option. If the master clock is disconnected from the network, a new master is dynamically determined.

IEEE 1588 has many different profiles, each of which use different features. Because the profiles are not interoperable with each other, make sure you are aware of which profiles your device supports.  Some profiles are supported in software only, but others require hardware support to achieve higher levels of time synchronization.

 

1588 with hardware support (IEEE 802.1AS profile and default profile)

Devices and networks with hardware support for IEEE 1588 can provide high accuracy simple synchronization of systems.  TSN-enabled CompactRIO controllers provide hardware support for IEEE 1588 and support both the default profile and the IEEE 802.1AS profile.  IEEE 802.1AS was selected for time synchronization within Time Sensitive Networking (TSN) infrastructure. TSN is a series of additions and updates to the IEEE 802.1 standard, which is a local area networking standard for bridges. One of the aspects of TSN is defining a common sense of time between network components within the TSN subnet. This profile provides a set of optimizations to assure high reliability and high accuracy in PTP networks.  It is the recommended profile for CompactRIO controllers.  However, the controllers can also support the IEEE 1588 default profile (layer 3, end to end).  To synchronize multiple CompactRIO controllers, you need to connect them using a switch that supports the necessary PTP profile.

The typical accuracy of this type of synchronization between controllers is less than 1 μs, but this can be greatly reduced to the 100s of nanosecond range, depending on the configuration of the system. The controllers that support TSN will automatically servo the Operating System Clock and FPGA clock to the network time. CompactRIO controllers supporting NI-DAQmx will also servo the NI-DAQmx task and DSA modules to network time.  You can read the current time in RT and through an I/O node if LabVIEW FPGA allowing you to precisely time stamp events and define start triggers for when an acquisition or task will start, and the NI-DAQmx driver will allow you to configure certain triggers and timestamps to be specified in terms of time of day. 

 

Software-Based IEEE 1588v2

All CompactRIO controllers support a software implementation of IEEE 1588. Once the driver is installed from MAX, multiple CompactRIO controllers can be connected over any standard Ethernet network, and they will automatically synchronize their system clocks. The typical accuracy of this type of synchronization between controllers is about 1ms. While there is no specific network hardware (Ethernet switches) required to support IEEE 1588, an IEEE 1588-enabled switch is recommended to obtain the best synchronization performance. These switches mitigate the impact of network loading that can adversely affect synchronization on standard switches.


Synchronizing to other 1588 devices

In addition to synchronizing a network of CompactRIO controllers, you can also synchronize CompactRIO controllers with other devices that support IEEE 1588. If you are trying to synchronize your CompactRIO controllers with third party products, you will need to ensure that they use the same PTP profile (IEEE 802.1AS or default L3E2E).

To enable IEEE 1588 synchronization on your CompactRIO system, you will need to install NI-TimeSync on each CompactRIO controller. This can be done through the software installation process in NI MAX. IEEE 1588 settings can then be configured through NI MAX for PharLap and VxWorks targets. For NI Linux RT targets, you will need to configure these settings through file modifications. For details on configuring and monitoring the IEEE 1588 synchronization status on Linux RT, please see Using NI-TimeSync to Configure IEEE 1588 and 802.1AS Time References for more information.
*ARM-Based Linux RT targets are currently not supported as IEEE 1588 grandmasters.

B)  Global Positioning System (GPS)

Global positioning systems (GPS) determine locations on earth by receiving precisely time-stamped signals from geostationary satellites, determining distance from each satellite, and then triangulating to determine position. Because the GPS satellites provide precise timing information and are accessible anywhere on or near Earth where there is an unobstructed line of sight to four or more GPS satellites, this infrastructure can be used to create largely distributed synchronized systems. GPS is supported on CompactRIO using the NI-9467 module. The module has an SMA antenna connection that can be connected to a GPS antenna placed with a clear view of the sky. The module has a typical synchronization accuracy of 100 nanoseconds.

The NI-9467 I/O and GPS information is only available on the FPGA, and must be passed to the real-time host to synchronize the real-time clock to GPS. The GPS timestamp can be accessed via property nodes which return a timestamp in TIA format. Using these same property nodes, additional parameters about the quality of the synchronization, such as number of satellites and status information, can be obtained. The following image shows a screenshot from the Getting Started example for the NI-9467, which can be found in the Example Finder of LabVIEW.



The NI-9467 GPS Module is typically used with the FPGA Timekeeper API to synchronize the FPGA clock with GPS.

 

FPGA Timekeeper API

The FPGA Timekeeper API is a set of VIs that allows a developer to synchronize the absolute time of the FPGA target to a time reference. It has the capability to correlate absolute time with system events at an accuracy of ~100 ns. It is commonly used for timestamping I/O, scheduling I/O according to a future time, and getting and sharing accurate time. The FPGA Timekeeper API is available on the Sync Labs NI Community Page.

 

C)  (S)NTP* – (Simple) Network Time Protocol

(S)NTP is a time synchronization method for clocks located on the Internet. The current time is obtained from public NTP servers. It uses a distributed network of NTP servers and synchronizes clocks within the network to national time standards via Ethernet. Many industries, such as government and oil, prefer (S)NTP because it is a mature and well-tested standard that only requires a network connection. The major tradeoff with (S)NTP is that it is less accurate than the other time-based technologies described in this article. It has typical accuracy on the order of tens of milliseconds. (S)NTP is not officially supported on LabVIEW Real-Time targets, but there are methods to enable it, as described below.

On Linux RT targets, NTP can be enabled through the use of an open source Linux NTP daemon. There is community documentation available on the NI Developer Community that details how to install this daemon to a Linux RT target. One important thing to note is that you should not install NI-TimeSync to your target if you choose to use this daemon. Both NI-TimeSync and this daemon adjust system time, and your systems may not synchronize properly if both NI-TimeSync and the NTP daemon are attempting to modify time on the target. 

Because NI-Timesync should not run at the same time as an (S)NTP daemon, and because a IEEE 1588 or IEEE 802.1AS reference is required for NI-DAQmx tasks to start on cRIO-904x controllers using DAQmx 18.1 and later, (S)NTP and other 3rd party time references should not be run on these targets if NI-DAQmx tasks need to be executed.

*NTP and SNTP are indistinguishable from each other on the network level. SNTP has a smaller footprint in terms of memory and CPU usage while still being good enough to achieve system clock synchronization for typical desktop usage.

D)  IRIG-B

IRIG-B is a common time format whereby time of day information is encoded as a serial formatted time code.





IRIG-B dates back to the 1950s and is commonly seen in military applications. The CompactRIO platform does not have a dedicated hardware solution for IRIG-B decoding. To use IRIG-B on CompactRIO, one needs to use a digital C Series Module such as the 9402 to decode the IRIG-B signal. There is an example of an IRIG-B 000 variant implementation in LabVIEW FPGA, which can be used in its entirety, or as a starting point.  This code can be combined with the FPGA Timekeeper to provide time on the FPGA.  
IRIG-B is supported on the PXI Platform using the PXI-6683(H) module.

Signal-Based Synchronization Methods


In signal-based synchronization, devices are wired directly together, and a master device exports timing signals to slave devices. In this paradigm, all systems acquire together, but one does not necessarily know the data point’s time. Typically, either trigger signals or sample clocks are shared. The following is a list of signal-based synchronization options for CompactRIO.

A) NI-9469 Synchronization Module

The NI-9469 is a C Series Module specifically designed for sharing clocks and triggers between chassis. It has a software-configurable multi-port interface that enables distribution of triggers and clocks from a host chassis, and it has an onboard DDS and PLL for clock generation and synchronization capabilities.

For sharing the triggers and clocks, the NI-9469 has three RJ45 connectors on the front panel, which use standard CAT 5e cabling to pass DIO signals to other NI-9469 modules. Although this is standard Ethernet cabling, these modules only pass timing signals and cannot provide general communication. Each port is software-configurable and can drive or receive four differential signals through the cable. Each port can carry either four triggers/FPGA derived clocks, or three triggers/FPGA derived clocks and one oversample clock.

The NI-9469 was also designed to synchronize modules with simultaneous delta-sigma ADCs for high-channel-count systems that require more than one chassis. Delta-sigma modules require a separate oversample clock to operate. Delta-sigma modules are also referred to as DSA devices, and include accelerometer and microphone data. Each delta-sigma module has an onboard clock for normal operation that is physically routed through the CompactRIO chassis to synchronize all delta-sigma modules within a single chassis. For multi-chassis systems, the NI-9469 generates the required oversample clock for delta-sigma modules and routes it to both the local CompactRIO chassis and any other CompactRIO chassis connected by an NI-9469. In addition to delta-sigma synchronization, you can program the input and output lines (four per port) of the NI-9469 for custom trigger schemes.

The NI-9469 module allows for a flexible network topology. See the NI-9469 Operating Instruction and Specifications for more information on the possible network topologies. The NI-9469 is supported on both CompactRIO and CompactDAQ platforms. However, it is not designed to interface the NI-9469 with the PXI platform. For example, the Ethernet port on the PXI-6683H timing module will not interface with the NI-9469.

B) Custom Programming with Digital I/O

It is possible to configure custom triggering and sample clocks using manual FPGA programming. For example, one could use a clock input to a C Series digital input module to trigger an acquisition. This is the equivalent to providing an external sample clock in NI-DAQmx. Below is a simple example where a digital input is checked periodically. In NI-DAQmx, this concept is the same as using a start trigger. Once a rising edge is detected, the first loop exits, and acquisition starts.