DAQmx Multidevice Synchronization with PCI Synchronization Using the Reference Clock

[migration-bot]

Description

Description-Separate-1

Part of the M Series Synchronization with LabVIEW and NI-DAQmx Example Set

The RTSI bus offers the ability to share signals between independent devices in the system. Traditionally, synchronizing data acquisition devices required sharing a common timebase clock source among the devices. M Series devices have an internal timebase of 80 MHz, which is too high a frequency to pass accurately to other devices through the RTSI bus. Typically, 10 MHz is a more stable clock frequency to route between devices and is used as a standard for synchronization in PXI systems with the 10 MHz PXI clock built into the backplane of the chassis. Therefore, M Series devices generate a 10 MHz reference clock to be used for synchronization purposes by dividing down their 80 MHz onboard oscillator. To synchronize acquisitions or generations across several PCI M Series boards, one board acts as the master and exports its 10 MHz reference clock to all of the other slave boards. The NI-STC 2 ASIC on each M Series has PLL circuitry that compares an external reference clock to its built in voltage-controlled crystal oscillator clock (VCXO) to output a clock that is synchronized to this reference. Thus each device in the system can input a 10 MHz reference clock and synchronize its own 80 MHz and 20 MHz timebases to it. With this technology, all devices are synchronized to the same 10 MHz master clock, but can use their individual faster 80 and 20 MHz timebases generated onboard. Note that due to the way signals are divided down, the 100 kHz timebase will not be in phase with the input to the PLL. Refer to Figure 1 for an overview of the timebase routing for M Series devices. Figure 1 shows how the PLL and a reference clock are used to synchronize two high-speed clocks, 100 MHz in this case.

Figure 1 Concept of Synchronization Using a Reference Clock

When routing its 10 MHz reference clock out for other devices to synchronize to, the master device can set the source of its reference clock to "OnboardClock". This option will take the 10 MHz reference clock of the master device, which has been routed out to RTSI, back to the source of its own PLL. The master device then sees the same delays that the slave devices phase locking to the 10 MHz reference clock over RTSI will see. Note that by default, the source of an M Series reference clock is set to "none". This will cause the M Series device to use its onboard oscillator as the source of its timebases.

Figure 2 shows an example of multidevice synchronization of two M Series boards using the reference clock of the master device. The labels on the figure correspond to important parts of the program and a description for each is given below.

Figure 2 PCI Synchronization with 10 MHz Reference Clock

1. In Step 1, virtual channels are created. Each one of the virtual channels in question here is used to acquire from an analog voltage signal. Notice that they are from independent devices – M Series Master and M Series Slave.
2. In this step, the timing information is entered. Both channels are set for finite acquisition of 1000 samples/channel at a rate of 1000 samples/s. The source of each sample clock is left to the default value, which is just the internal analog input sample clock that will be derived from dividing down one of the internal timebases of the device.
3. The reference clock of the master device is set to OnboardClock. This will cause the master device to output its 10 MHz reference clock to RTSI and back into the source of its own PLL to synchronize its PLL oscillator with the same 10 MHz reference clock that the slave devices will use. The source of the master reference clock is then queried and used to set the source of the slave reference clock, which causes the 10 MHz reference clock to automatically be routed through RTSI to the input of the slave device PLL as a reference to phase lock its timebases to. Using this process, the two devices can each use its own timebases, but then be synchronized indirectly through the reference clock. By choosing OnboardClock, the master incurs the same delay encountered by the slave receiving the signal through RTSI, making the whole synchronization process more accurate.
4. As with the simultaneous start example, the Get Terminal Name with Device Prefix VI is used to programmatically extract the Start Trigger signal of the master device and route it to be used to start the slave device. This step is the second phase of the synchronization – making sure that they start at the same time.
5. The task from the slave is started first, but will wait to receive a trigger signal from the master Start Trigger that was routed in the previous step. When the master is started, the Start Trigger signal is generated and triggers both tasks at the same time. The sequence structure is used to ensure that the slave is started before the master and to avoid race conditions.
6. At this step, the samples are read by both tasks. Each task will provide 1000 samples and display them on a waveform graph.
7. After the acquisition is done, the tasks are cleaned in this step. This step ensures that the resource is freed and can be used by another task.
8. This last step handles the errors that might have occurred during the acquisitions. Error clusters from both tasks are merged into one error cluster and wired into the error handler.

Description-Separate-2