Monitor and Configure Time Synchronization on Embedded Devices

Publish Date: Sep 20, 2019 | 6 Ratings | 5.00 out of 5 | Print

Overview

NI-Sync (which now includes the driver formerly known as NI-TimeSync) is a distribution of time synchronization protocols that can be used with compatible NI hardware. These protocol instances are referred to as "time references", and are used by NI-Sync when synchronizing a device's timekeeping clocks. The most commonly used time references in NI-Sync are IEEE 1588 and IEEE 802.1AS. These time references can be used with NI-Sync with little to no additional configuration to synchronize multiple targets; use this guide for advanced configuration of IEEE 1588 and IEEE 802.1AS time references and best practices for system design.

Table of Contents

  1. Time References and NI-Sync
  2. Monitoring and Configuring Time References with the NI-Sync API
  3. Troubleshooting Synchronization Quality
  4. Related Links

1. Time References and NI-Sync

 

A time reference is software on a device which manages synchronization using a supported synchronization protocol. NI-Sync is a driver which can be used to monitor and configure time references on a target. Time references have a few considerations which are helpful to understand:

  • A time reference is associated with an interface that can support it. For example, a TSN-enabled CompactRIO with two ethernet ports that support synchronization may have two 802.1AS time references, two 1588 time references, or one of each active simultaneously. A TSN-enabled CompactDAQ target has two ethernet ports, but they are bridged and effectively function as one. As a result, a TSN-enabled CompactDAQ target may have two ethernet ports but will only have one 802.1AS or 1588 time reference that applies to both ports.
  • A time reference is active when it is enabled. Enabling a time reference effectively turns it on and starts synchronizing time on the associated interface. If more than one time reference is associated with an interface, only one may be enabled at a time. Time references are enabled by default. If a 1588 time reference and an 802.1AS time reference are associated with the same port, the 802.1AS time reference will be enabled by default.
  • A time reference is selected when it is driving time on a device. No more than one time reference may be selected on a device simultaneously. If no time references are selected, the device time is free-running. A time reference can only be selected if it is enabled and acting as a slave. Time references are selected automatically when they become a slave on a synchronization network.

For embedded devices, the two supported time references are NI-TimeSync Time Reference for IEEE 1588-2008 and NI-TimeSync Time Reference for IEEE 802.1AS-2011. These time references may be installed to a supported Real-Time target through the Real-Time Software Wizard, and are available by default on cDAQ 9189/5 and FieldDAQ devices using firmware 18.6 and later. Only TSN-enabled devices support 802.1AS. Devices which are not TSN-enabled are capable of using IEEE 1588-2008 without hardware timestamping, but it will be less precise than on TSN-enabled devices.

 

 

 

The NI-Sync API exposes protocol properties in the LabVIEW programming environment. The NI-Sync API can be used for monitoring and configuring time references starting with the NI-Sync 18.0 release. For instructions on configuring time references using older versions of the NI-Sync or NI-TimeSync driver, please refer to Using NI-TimeSync to Configure IEEE 1588 and 802.1AS Time References

Starting with NI-Sync 19.0, NI-TimeSync features are included in the NI-Sync 19.0 distribution and NI-TimeSync no longer exists as standalone software. The NI-Sync driver provides time references and examples to demonstrate how to monitor and configure time references. To install the NI-Sync API and time references for Real-Time targets, install the latest version of the NI-Sync driver on a host computer. If software older than version 19.0 is required, download the most appropriate version of NI-Timesync

 

Back to Top

2. Monitoring and Configuring Time References with the NI-Sync API

 

The NI-Sync API is the recommended way to monitor and configure time references with software later than NI-Sync and NI-TimeSync 18.0. To monitor or configure properties for a time reference, follow the steps below to open a session with the device and access properties.

  1. Locate the NI-Sync palette in LabVIEW.
  2. Open an NI-Sync driver session by placing an niSync Initialize VI on the block diagram and connecting a reference to a target.
  3. Some properties require the name of the time reference to be configured. To determine the names of each of the time references on the target, use the niSync Get Time References VI to retrieve an array of time references installed on the target.
  4. Properties specific to a time reference require a defined Active Item. The active item is defined by the name of the time reference, which can be retrieved as shown in step 3. of this list. If a property requires an active item, the Active Item terminal should be the first property listed in the property node.
  5. When monitoring and configuration is complete, close the NI-Sync session.

The following table is a noncomprehensive list of useful properties for 802.1AS and 1588.

 

Property Name Property Description
Priority1* The 1st order priority assigned to the PTP clock used by the time reference specified in Active Item. This property is used in the execution of the best master clock algorithm. A lower value increases the priority.
Priority2* The 2nd order priority assigned to the PTP clock used by the time reference specified in Active Item. This property is used in the execution of the best master clock algorithm. A lower value increases the priority.
Offset from TR (ns) Returns the time offset between a slave and a master in nanoseconds. Will always return 0 if a target is the master of a network.
GM Clock ID* Returns the MAC address of the grandmaster. If the target is the grandmaster, returns the target's own MAC address.
Is TR Selected* Indicates whether the active item is selected or not. If a time reference is selected, it is driving time on the target. Time references in master mode will never be selected, because they are not driving time on the target. The master drives time on other targets, a time reference in slave mode drives time on its own target.
TR Enabled* Indicates whether a TR is enabled or not. If a TR is disabled, it is effectively turned off. It will not master or slave with other targets and does not affect time on the target.
Selected Time Interface Name Returns the name of the selected time reference, which can be used to specify the active item. The selected time reference is the time reference which is driving time on the target.

*The user must specify an Active Item to use this property

 

An example of monitoring and configuring some of these properties can be found in the LabVIEW example finder, in the task tree at Hardware Input and Output >> Timing and Synchronization >> Time-based >> Monitor and Configure Time References.vi.

 

Back to Top

3. Troubleshooting Synchronization Quality

 

In applications where synchronization is vital, it should be monitored continuously to validate synchronization quality. There are two important properties which largely define the synchronization status of a device:

  • GM Clock ID - Returns the MAC address of the grandmaster. This property is the best way to confirm that a device is actively synchronized to a master device. All synchronized devices on the network have the same value for this property. This property is useful for determining which device is mastering the netwrok.
  • Offset from TR (ns) - Returns the time offset between a slave and master in nanoseconds. This property is the best indication of the synchronization quality for a slave device.

Users should define their own standard of synchronization quality. An example of how to monitor synchronization quality can be found in the LabVIEW example finder, in the task tree at Hardware Input and Output >> Timing and Synchronization >> Time-based >> Monitor Synchronization.vi.

If synchronization quality is not acceptable or if other processes are being affected by poor synchronization (such as DAQmx), synchronization troubleshooting may be required to track down the issue. To effectively troubleshoot a synchronization issue, simplify the system as much as possible and rebuild the system one step at a time until the problem reappears. There are a few issues that commonly affect synchronization quality:

  • Network Topology - Devices with a large number of network hops between themselves and the grandmaster will have lower synchronization quality because each networking component introduces jitter into communication between devices. Rather than having a long daisy-chain, a star topology or a ring topology may be preferable.
  • Incompatible Network Hardware - IEEE 802.1AS transmits synchronization data at the frame layer of the OSI model (layer 2), and as such requires that networking hardware be compliant with the standard. IEEE 1588 does not have this requirement, but having networking hardware that is compliant with IEEE 1588 (PTP) greatly increases synchronization quality. If two devices are on the same physical network but are not mastering/slaving as expected or have poor sync quality, check that any hardware between them is compatible with the required synchronization protocol.
  • Heavy Network Traffic - IEEE 802.1AS is unaffected by networking traffic because it is a layer 2 protocol, but IEEE 1588 is affected by heavy network traffic. If several devices are connected through a heavily used network, consider moving them to an isolated network or using 802.1AS if possible.
  • Common Networking Issues - Synchronization can be affected by the same factors that cause common networking issues, such as poor quality or loose ethernet cables. It is generally best practice to have all devices that should synchronize together on the same subnet. This makes device management much easier and avoids any unnecessary complications due to crossing subnets.

 

Back to Top

4. Related Links

 

Back to Top

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit