Time track incorrect do to failure to read offset about nptdms HOT 6 CLOSED

Would you have an example file (as small as possible) that we can look into?

from nptdms.

I uploaded the file to https://github.com/boiler42/npTDMS

My code is:
from nptdms import TdmsFile
tdms_file = TdmsFile('data.tdms')
a = tdms_file.object('Test Group', 'Channel A')
b = tdms_file.object('Test Group', 'Channel B')
print(a.time_track(absolute_time=True))
print(b.time_track(absolute_time=True))
print(a.time_track())
print(b.time_track())

b should lag a by 3 seconds. Absolute time is correct. Relative time is not correct

from nptdms.

I think it's best that @adamreeve looks at this. My knowledge of TDMS files is kinda bad :-)

from nptdms.

Your file has offsets of zero for each channel but has different absolute start times. The output from tdmsinfo looks like:

/
properties:
name: Test TDMS data
  /'Test Group'
    /'Test Group'/'Channel A'
      data type: tdsTypeDoubleFloat
      properties:
      wf_start_time: 2015-11-20 20:13:43.596313
      wf_start_offset: 0.0
      wf_increment: 1.0
      wf_samples: 10
    /'Test Group'/'Channel B'
      data type: tdsTypeDoubleFloat
      properties:
      wf_start_time: 2015-11-20 20:13:46.596614
      wf_start_offset: 0.0
      wf_increment: 1.0
      wf_samples: 10

So when you want to plot the data you could plot each channel against an absolute time or calculate the offset based on the absolute times. If you want to get a time track with absolute times for your channel you can set absolute_time to true in the time_track method, eg. t = tdms_obj.time_track(absolute_time=True).

from nptdms.

Understood. For the real work, I am getting absolute time for each channel and then relativizing them by subtracting the min across all channels. I think your current code is correct and this is more of a peculiarity of the file I am using. It would be nice to print a warning if you get relative times from channels with unequal "true start times", which I am considering to be equal to wf_start_time + wf_start_offset. It would be even better if the extra functionality I described above were built in, basically a third option for time which would be something like "global_relative".

Thanks for the quick replies and the helpful library! I am a python guy but where I work all test data is NI/TDMS so nptdms is perfect.

from nptdms.

Hmm so re-reading NI's documentation on wf_start_offset, they say "This property is used for the LabVIEW Express Dynamic Data Type. Frequency-domain data and histogram results will use this value as the first value on the x-axis."

So this is probably always zero for time-series data. It's just that the time_track method can also be used to get an array of x-axis data for non time-series data, so needs to account for this attribute if it's present. This is kind of an unfortunate naming choice, and maybe this method should have just been named "independent_axis_values" or something.

I will update the documentation to clarify what these parameters mean, and note that wf_start_offset will be zero for time series data, and the start time should be used to align time-series data.

from nptdms.