Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx and PXI-6683H

Right now, I use a PXI-6683H synchronized to an external IRIG time source.  To synchronize my PXIe RT system controller, I use the Sync Labs custom time reference TimeSync function.  This produces roughly a 10:1 worse system clock sync than the 6683H is maintaining to the IRIG time source.

 

Am I doing something wrong here?  My intent is to have the system clock follow IRIG so that DAQmx WFM T0's are as close to the IRIG source as possible.  Somewhere I recall hearing that DAQmx can interact with NI Sync (6683H) directly, but I can't find any actual documentation mentioning how this works.

 

Does anyone know if DAQmx can actually timestamp WFM data using the 6683H?  It's easy enough to use the NI Sync timestamp functions for other timestamping needs, but not for DAQmx.

 

Thanks,

 

XL600

0 Kudos
Message 1 of 6
(2,782 Views)

Hi xl600,

 

I have a couple questions about your setup:

 

Are you using the Sync Labs custom time reference or are you using the Sync Labs TimeSync for NI-Sync Hardware time reference? If you are using the former, you may get better results using the TimeSync for NI-Sync Hardware one as it would be more tuned for your use case.

 

How are you testing that you are seeing 10:1 worse system clock sync? What synchronization are you seeing? Generally, the synchronization would be somewhat worse than what the 6683H is maintaining (since the 6683H is synchronizing to the IRIG time source and the system time is synchronizing to the 6683H = two layers of synchronization instead of one). Internally, we've seen system time synchronization on the order of 100 ns off from the 6683 (this is beta software so that's definitely not guaranteed, but I'm just wondering how it compares to what you're seeing).

 

If you are just testing based on the t0 of DAQmx, this is going to add an additional lack of determinism. That t0 is software timed and should not be used to evaluate/verify synchronization: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9Q9SAK

I don't know of a way to make the t0 of the DAQmx waveform more closely tied to the time on the 6683.

 

What is your overall goal here? Are you trying to make sure that your DAQmx tasks (actual signals) are synchronized via the IRIG time source or are you trying to record data that proves the signals are synchronized (using the DAQmx waveform data)? Or something else entirely?

0 Kudos
Message 2 of 6
(2,755 Views)

I'm using the custom time reference because when my IRIG isn't available, I have to sync to a UDP time packet coming from the same server the IRIG source comes from (It can take upwards of an hour to get IRIG stabilized... I wish it were better, but it's not my design).

 

I've never heard of TimeSync for NI-Sync.  Does it have a custom time source capability like the old Sync Labs TimeSync?  It's been two years since I implemented all of this and I haven't kept track.

 

The 10:1 is simply the ratio I see between the 6683H offset and the TimeSync offset.

 

I find the T0 of DAQmx is pretty good, but it bugs me it's not more accurate.  I keep very few high priority loops running so that this T0 doesn't get hammered.  All of my DAQmx tasks are started based on a PXI trigger.  The time difference between this trigger (I capture the time of the trigger using the 6683H) and T0 is always < 1 sample clock so I figure it's valid.

 

What I am doing it trying to ensure my analog data is aligned to the timestamps of UDP packets coming in from the external system.  It's complex and involves multiple non-NI hardware systems.  The time is generated in those systems and all I'm trying to ensure is the PXIe chassis is as close to their system time as possible such that I can trust my T0's and timestamps are directly relatable to the timestamps those other system are generating to within about 100us.  Even now, I think I'm attaining that, but the TimeSync drift does have a bad habit of overcompensating for periodic glitches in the IRIG stability (Like if IRIG drifts a few us, TimeSync can go unstable).

 

I still have to be able to fail over to UDP though and be able to free run without IRIG or UDP.  I can't get around those needs.

0 Kudos
Message 3 of 6
(2,752 Views)

BTW: Both of those links point to the same place:

 

http://ftp.ni.com/support/softlib/Timing_Sync/Labs/NI-TimeSync/NITimeSync1_2_d15.exe

 

That's what I've been using.  Is there something different that adds 6683H to system clock direct sync and some documentation of it all?

 

Thanks,

 

 

0 Kudos
Message 4 of 6
(2,747 Views)

It's the same 1.2b install. The difference comes when you install the time reference to the real-time target (you can choose the "Custom Time Reference" or the "NI-Sync Time Reference" (not sure on the exact names)). However, with your need to fall back to UDP packets, the custom time reference is probably your best option. Unfortunately, there's not a lot of documentation at this point. Just the page I linked earler: https://forums.ni.com/t5/Sync-Labs/TimeSync-for-NI-Sync-Hardware-Getting-Started/gpm-p/3543807

 

You say the offsets have a 10:1 ratio. Can you give an example of the offsets that you're seeing? I'm just curious if they match about what I would expect.

0 Kudos
Message 5 of 6
(2,742 Views)

So, when I am updating TimeSyncAdjustTime (custom), I update with the NI-SYNC clock time.  When NI-SYNC tracks IRIG to within say 5us, the variation in the TimeSync offset ranges +/-50us.  About 10:1.  It's not always 10:1 though.  It varies quite a bit.  The subvi I use to sync when in IRIG mode is attached.  I call this at 4hz since that's the speed the UDP packets come in when in UDP mode.

 

The timed loop is an attempt to reduce interfering processes during the get time calls.

 

 

0 Kudos
Message 6 of 6
(2,714 Views)