DAQmx tdms logging and wf_start_time

[xl600]

I am using the DAQmx TDMS logging functionality (LV2015) on a PXIe-8135 RT controller.  When I compare the first sample's actual T0 to the T0 in the resulting TDMS file, they do not match.  The tdms file appears to round down the wf_start_time timestamp to the nearest whole second.  Is this a known behavior?

Thanks,

XL600

[crossrulz]

I see two possible issues here:

1. Your RT time is not synchronized with the PC time

2. You have a display issue on the timestamp.  How are you looking at the start time for both the waveform and TDMS file?  LabVIEW?  DIAdem?  Excel?

[xl600]

The PC to RT synchronization shouldn't have any effect here.  The TDMS file is being created by the RT system so all I'm doing is reading the wf_start_time as written by the RT system.  My RT time is actually synchronized with a different network so all timestamps would be based on that timebase.

I'm not looking at the TDMS file time at all.  Just the wf_start_time property.  I looked at it in Excel, but the TDMS importer often does weird things there so I generally only use Excel to look at the raw data.

I'm actually looking at the wf_start_time property as read back by the LabView TDMS read property function.  To my surprise, it was exactly the same as Excel even when the display was set to show micoseconds in LabView.  The fractional seconds seems to be getting truncated before the wf_start_time property is being written to the TDMS file.

I write timestamps all the time in another part of the application, not using the DAQmx TDMS logging functionality) and this hasn't been seen there.  The timestamps manually written always match the expected timestamps.

[JÞB]

I'm goint to go out on a limb and guess here.  The default absolute time format specifier for Timestamp data types in DAQmx is %<%X\n%x>T so, does your machine specific prefered Time Format (%X) enclude fractional seconds?

[xl600]

%<%X\n%x>T produces the following in a simple timestamp control:

6:51:36 AM

10/7/2016

So it doesn't appear to include fractional seconds.  Does that affect the actual storage of the underlying timestamp data in a TDMS file when using DAQmx TDMS logging?

[JÞB]

---

@xl600 wrote:

%<%X\n%x>T produces the following in a simple timestamp control:

6:51:36 AM

10/7/2016

So it doesn't appear to include fractional seconds.  Does that affect the actual storage of the underlying timestamp data in a TDMS file when using DAQmx TDMS logging?

---

The short answer is I do not know.  Worse, the help file is silent and the DAQmx logging code is buried in "dll_hell" TDMS Attribute for wf_start_time is read only and again the help is silient on if the display format property of the Timestamp is configurable and the guts of the code is unavailable to mere mortals.

SO, I devised an experiment

Where I had MODIFIED [CAUTION: Involves modification of NI supplied Driver-  USE a copy rather than corrupt yopur DAQmx Install]  DAQmx Read (Analog 1D Wfm NChan NSamp).vi by changing the Display Format of Data.t0 to 

%<%.3X\n%x>T

and.... Ta-Da! (insert trumpet and harp fanfare here)

wf_start_time displays mSec resolution!  Cool!

NOW the bad news.  To verify I reverted the DAQmx vi and I still see mSec resolution in Excel using the TDMS importer Add-on 

So, it begs the question- what version of DAQmx are you using?

[xl600]

I tried your solution and did't see an effect on the 1Chan NSamp 1D waveform read VI.  I wouldn't have believed it if I did though given the display format for the read VI is on the output of the DLL call.

[JÞB]

---

@xl600 wrote:

I tried your solution and did't see an effect on the 1Chan NSamp 1D waveform read VI.  I wouldn't have believed it if I did though given the display format for the read VI is on the output of the DLL call.

---

Not too surprising since I was unable to observe a difference between the modified and original DAQmx function as it displayed in Excell via the TDMS file viewer.  I've seen stranger "Under-the-hood" behavior than that though!  The simple fact that expected resolution of Timestamp data in TDMS is undocumented tingles my 8-Ball special LabVIEW analog to a "Spidey Sense"  Undocumented expected behavior gives the brainiacs at NI the choice to change the behavior between releases.  That is good and bad at the same time.

So how are you displaying the attribute wf_start_time?  and what version of DAQmx Device Driver are you using (16.0.0f0 here)? What is the hardware acquiring the data?

[xl600]

DAQmx 15.0.0 for LabView RT on a PXIe-1082 chassis using PXI-6281 cards.  I have 16.0.0f but I was waiting to get to a good baseline before trying to move to LabView 2016.  I display the timestamp after reading using TDMS read property using a normal timestamp with a format of:

%<%I:%M:%S%6u %p
%x>T

As an interim solution, I've created a gating trigger on PXI_TRIG7 which I am using for the task and full-device sync.  I set the start trigger to PXI_TRIG7 and also use that as a pause trigger so it can stop the acquisition on an arbitrary sample boundary.

PXI_TRIG7 is a copy of a PFI port (Routed so I can test this using a DO task) and I have that PFI physically cross connected to P0.7 and P0.6.

I then use a RT loop with a change detection timing source on P0.7 (Since PXI-6281's only support change detect on P0).  This does three things:

1. Capture the RT loop global start time as the high accuracy timestamp
2. Read P0.6 to determine the polarity of the trigger signal
3. Send a notifier out to the world so SW loops can get notice for whatever they need to do

I think that will give me a very high reolution start time regardless of the wokyness of the wf_start_time.  I'll have to do a TDMS write property to overwrite the bad wf_start_time after capture.

It shouldn't have to be this hard though, and I shouldn't have to waste a counter and my only DI task just get an accurate waveform start time on a RT controller.

[JÞB]

wf_start_time is read only that won't play

Here is what I have in LabVIEW 2016.0 (32 bit)

I'm not reproducing your problem as you can see