From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Time sync problem of DAQ cards in RT PXI.

Hi,
 
I'm doing a remote monitoring project using several RT PXIs at remote sites and a server for data processing. Each PXI has M-series PXI-6220, S-series PXI-6143 and DIO PXI-6514. The server will sync each PXI per hour by sending the time stamp through UTP. There are two problems when I want to log the time stamp of the signal at PXI.
 
1. I log the data for each 100ms and take the time stamp using "Get Date/Time in Seconds" function. I found that the time stamp was fluctuated that was not 100ms of each sample.
 
2. I log the time stamp using the waveform t0 for each sample and it's more accurate. However, when the server syncs the PXI and the time is changed. The t0 value took from the M-series PXI-6220 will not be affected but S-series PXI-6143 and DIO PXI-6514 t0 will change according to the time changed. The M-series PXI-6220 seems using its own clock once started the acquisition and I have to start the DAQmx task again to reset its clock.
 
Could anybody suggest a better way to log the timestamp for the acquired signal in RT PXI?
 
Bill
0 Kudos
Message 1 of 4
(2,982 Views)
Hey Bill,

The problem is that when the real-time OS runs code set for time-critical priority, the real-time OS ignores its bookkeeping routines.  One of the bookkeeping tasks of the real-time OS is to keep system time.  In LabVIEW Real-Time, this is done with interrupt service requests, which get ignored when the real-time OS is busy running time-critical code.  Take a look at the Verifying Correct Timing Behavior section of the LabVIEW Real-Time User Manual for more information.

Maybe you could try manually synching all your PXI controllers at the start of a test.  The following example program illustrates how to do this programmatically:

Setting Date and Time on a LabVIEW Real-TIme Target Using Network Time Protocol (NTP) Server from N...


Does this sound like a viable option?

Also, you can share clock and trigger signals across multiple chassis using a National Instruments Timing and Synchronization module.  Information about these module can be found here:

KB 2WF8F22L: How Can I Synchronize NI PXI-4472 DSA Devices Across Multiple PXI Chassis?

This option requires that your chassis be close enough to one another to physically connect the timing signals.   This sounds like it might be impossible for you.

Regards,
Travis G.
Applications Engineering
Message 2 of 4
(2,967 Views)
Hi Travis,
 
Thanks for your reply and it is helpful for me. I tried to use the Read Time Stamp Counter (RDTSC) but I found that it can't be changed to the date/time timestamp I want. I have to find a way to sync the PXI in a fix period (maybe 1 hour) and log every timestamp for each sample. I read many messages about the problem I concerned. It seems that there is no way to do the synchronization and log the date/time timestamp accurately. Is it better to initialize the DAQmx task again after time sync? Of course some of the data points will be lost in the initialization period. Could anybody suggest some examples?
 
Bill
0 Kudos
Message 3 of 4
(2,937 Views)
Hello Bill,

Did you try using the 'Setting Date and Time on a LabVIEW Real-Time Target Using Network Time Protocol (NTP) Server from NIST' example?  I really think that this program should allow you to get accurate timestamps from multiple PXI chassis.  You could place this code in a lower priority loop of your program, with your data acquisition in a higher priority loop.  In the higher priority loop, you could get a timestamp for each acquisition with the 'Get Date/Time in Seconds' function, which pulls its timestamp from the real-time OS clock.  The lower priority loop would constantly synchronize the real-time OS clock with the NIST time server, to guarantee that all the real-time OS clocks don't fall behind.  This solution sounds like it would give you an accurate timestamp universal to all your PXI systems.  Does this sound like a viable solution?

Regards,
Travis G.
0 Kudos
Message 4 of 4
(2,926 Views)