E Series and X Series Card Synchronization with RTSI cable

[vvesley]

E Series and X Series Card Synchronization with RTSI cable. Help I have a PCI-6024E card and a PCIe-6320 card plus a RTSI cable to link them together can someone help me with some code to get their timing aligned. Thanks

Wes Callahan

[Kevin_Price]

1. You'll need to go into MAX to configure it to know you have a RTSI cable in your system and that those 2 devices are attached.  DAQmx uses this configured info when it figures out what signal routing it can do automatically on your behalf.

2. After that, it may be as easy as making a distinct AI task for each device, but configuring timing for "Dev2" (or whatever) to use the signal "/Dev1/ai/SampleClock" as the sample clock for Dev2.   DAQmx can then do the signal routing work over RTSI for you automatically.

   The only other thing to do is make sure you start the Dev2 task first, so that when Dev1 is started later and makes its first sample clock, Dev2 is already looking for it.  That'll keep sampling aligned.

-Kevin P

[vvesley]

Please check this link 

http://www.ni.com/tutorial/3615/en/

Thats how its setup years ago with TWO 6024E cards but now i have only 1 PCI slot available in the new computer...

So when i did this the time isn't syncing and i think it has something to do with the 10MHz vs 20MHZ..

Please give me input thanks,

Wes C.

[vvesley]

Special case – E Series and M Series Synchronization
E Series devices have been leading the market for data acquisition products for many years, and with the introduction of the new NI M Series devices, we feel strongly that NI multifunction data acquisition devices will continue to lead the market. As a result, it is important that current E Series users be able to use both E and M Series devices simultaneously. For this reason, this section presents the recommended method for synchronizing E Series and M Series devices.

E Series and M Series devices employ slightly different techniques for synchronization. To synchronize operations across multiple E Series devices, one device will export its 20 MHz master timebase to be used as the master timebase for the other devices. Although an E Series device can input a slower signal, such as 10 MHz, for its master timebase it cannot multiply that timebase up to re-create a 20 MHz timebase. Therefore, the resolution of the internal sample clocks that the E Series device could create by dividing down this external master timebase would be decreased. M Series devices cannot directly route out their internal 20 MHz timebase over the RTSI bus. M Series devices are able to directly route out only their 10 MHz reference clock. Therefore, the E Series device should be used as the master device when synchronizing an E Series and an M Series device. In this case, the E Series device can route out its 20 MHz master timebase to be used as the reference clock source for the M Series slave. The timebase on the M Series device would then be in phase with the 20 MHz master timebase of the E Series device.

Another behavior difference that must taken into account when synchronizing E and M Series devices is the difference in the default sample clock delay. The sample clock delay is the delay between when the AI Sample Clock occurs and when the first AI Convert Clock pulse for that scan occurs. With E Series, this default delay is 2 ticks of the master timebase, which is the minimum value allowed. With M Series, the default delay is 3 ticks of the timebase being used. Therefore, to more precisely synchronize an E Series device with an M Series device, change the E Series device to have a sample clock delay of 3 ticks. Figure 8 below demonstrates this behavior.

Figure 8 Default DelayFromSampleClk of E Series and M Series

Figure 9 is an example on how to synchronize an acquisition between an E Series and an M Series device.

[vvesley]

Delay with Trigger and First Sample on M, X, and E Series MultifunctionDAQ

Updated Jul 18, 2019

Issue Details

I am performing an analog input with an analog/digital trigger. What is the delay between receiving the trigger and the first sample?

Solution

The trigger delay or latency on our E-series (NI 60xxE), M-series (NI 62xx), and X-series (NI 63xx) DAQ boards is very close to the same delay regardless of whether you are using an analog trigger or digital trigger.  The main difference between the two is when the trigger is actually detected.

When using an analog trigger, you must either use one of the analog trigger pins (APFI for M and X series, PFI0/AI Start Trig pin on E-Series) or one of the analog input lines.  These boards then use an analog trigger detection circuit which is typically much less accurate than the analog inputs of the device.  For example, the M-series comparator circuitry typically contains four less bits of accuracy than the ADC of the device. For more information, please refer to KnowledgeBase 2W3D230T: E Series, M Series, and X-Series Analog Input Trigger Resolution.   For analog triggers on these boards, your accuracy of the trigger circuitry will affect when the analog trigger is detected. This will in turn affect the delay between when your signal crosses the trigger threshold and when your first sample is taken.

In addition to accuracy, there is a short delay internal to the DAQ cards.  This delay is going to vary on E-series, M-series, and X-series boards.

The delay is comprised of two elements:

1. the delay from when the trigger occurs and when the sample clock is generated
2. the delay from the sample clock to the convert clock (the clock used to actually take samples on our multiplexed cards).

 

1. Delay from Trigger to first Sample Clock:

This delay can be configured through a DAQmx Trigger property node (Start » More » Delay).  The default delay varies from device to device. E-Series: 2 Ticks of the AI Timebase
M-series: 2 Ticks of the AI Timebase
X-series (Multiplexed and Simultaneous): 4 Ticks of the AI Timebase

2. Delay from Sample Clock to First AI Convert Clock Pulse: 

This delay can be configured through the DAQmx Timing property (More » AI Convert » Delay from Sample Clock » Delay).  Again, the delay varies from device to device.

E-Series: 2 Ticks of the AI Timebase
M-Series: 3 Ticks of the AI Timebase
X-series (Multiplexed): 3 Ticks of the AI Timebase
X-series (Simultaneous): 0 delay.  There is no AI Convert Clock for our simultaneous X-series cards.

For more information, please refer to the appropriate user manuals in the related links section below.

Finally, the propagation delay from when a valid trigger condition is met to when the analog trigger circuitry emits the Analog Comparison Event may have an impact on your measurements if the trigger signal has a high slew rate. 

If you find these conditions have a noticeable impact on your measurements, you can perform software calibration on the analog trigger circuitry by configuring your task as normal and applying a known signal for your analog trigger. Comparing the observed results against the expected results, you can calculate the necessary offsets to apply in software to fine tune the desired triggering behavior.

The two properties mentioned in this article are used to manual synchronize your M-series, E-series, and X-series devices.  To ensure that a triggered or non-triggered acquisition is properly synchronized, you need to ensure that these delays are matched on each system.  Remember, the timebases are different between boards and you will need to determine the appropriate number of ticks depending on the AI timebase that you are using.

[vvesley]

Delay with Trigger and First Sample on M, X, and E Series MultifunctionDAQ

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019M5PSAU&l=en-US

[Kevin_Price]

I'm gonna let you in on a secret.   Ok, well, *secret* really isn't the right word because I've been half-shouting about it for probably 15 years around here.

The secret to DAQ sync is *often* very much simpler than what a lot of the official docs recommend.  The docs aren't *wrong*, but some of the things being advocated are simply *overkill* for many normal needs.

When I'm syncing tasks, I very commonly do it via shared sample clock alone for tasks with the same sample rate.  When they have different sample rates, I derive one sample clock from the timebase used by the other.

No trigger config, no reference clock mucking about, no PLL frequency settings.  Just shared clocks.

I've only once ever dealt with reference-clock based sync, and that was a system that had a couple dozen DAQ boards spread across 2 PXI chassis, some of which were very special purpose and could *only* be tied in to the master timing system by phase-locking on a reference clock.

In many of the cases where triggering is required, I still don't share the trigger.  I just treat the triggered task as my master task, share its sample clock to other tasks, and make sure I start all the slave tasks before the master.

There's so much discussion about sync here on the forums that I'm having trouble finding one that's especially good and clear.  In the meantime, here's a small example I posted that illustrates how I did sync via shared sample clock alone.  They were AO and counter tasks, but the exact same DAQmx timing-related code would apply to AI.   There's better examples around, I just can't seem to unearth one at the moment.

Your old method for sync is very likely to be overkill, more complicated than what you really need, and you probably didn't reap any benefits from that excess.  I strongly suggest simplifying the sync *method* as the first step toward resolving the errors.  The simple stuff I advocate is more universal with fewer device-specific exceptions or quirks.

-Kevin P