TDMS and Time Alignment - How?

[CoastalMaineBird]

LV 2010.0

I'm trying to figure out TDMS files, specifically how to handle config chanegs in mid-stream.

For example:

I setup the config as  TIME + channels A, B, C.

I record some data.

I then change the config to TIME + channels A,B,C,D

I record some more data.

When I extract the data from the file and plot A vs. Time and D vs. Time, I expect to see the D plot delayed with respect to the A plot.  After All the start of D occurred AFTER the start of A.

But I can't make that work.  I've tried interleaving / not. It just doesn't seem to associate the D trace with the time that it was taken.

Here's the result I get:

What I'm EXPECTing is for that bottom plot to be on the RIGHT side.  As it is, it's lying to me.

Here's the code that's WRITING the file:

Here's the code that is READING the file:

Attached are the VIs themselves.

So.... what am I missing?   How do I plot D vs. Time and have it come out accurately?

[Wayne.C]

TDMS file is sample driven.  Each channel is a 1D Array of information.  Normally the proper relationship between the timestamp and all the channels is maintained by logging everything all the time.  In your case, I would log each channel to a separate file and include the time with each sample saved.

[CoastalMaineBird]

Normally the proper relationship between the timestamp and all the channels is maintained by logging everything all the time.

Yes.

But I would expect that if I WRITE a pair: value V at time T, that I would get back out the same data.

What it's doing is actually disassociating V from T and telling me something false: V goes with time T-x, some earlier time.

In your case, I would log each channel to a separate file and include the time with each sample saved.

That's not realistic in my real project.  I have 250+ channels.  I need to accomodate the (rare, but non-zero) possibility that the user stops recording and adds (or deletes) a channel.

I don't want to have 250 files open. I don't want to have 250 copies of the same TIME signal.

I can start a new file if the config changes, but I was wondering if I could avoid that.

I wonder if SET WRITE POSITION on the new channel would help.

[Wayne.C]

---

Normally the proper relationship between the timestamp and all the channels is maintained by logging everything all the time.

Yes.

But I would expect that if I WRITE a pair: value V at time T, that I would get back out the same data.

What it's doing is actually disassociating V from T and telling me something false: V goes with time T-x, some earlier time.

---

You consider them a pair but TDMS does not think that way.  It just sees the next sample for two seperate channels.  Each sample then goes in the next available spot in the array for its channel.  There is no relationship between the channels.

I'll agree that with 250+ channels my idea is not feasible.

[CoastalMaineBird]

I can make it work by recording in two separate GROUPS.

If I read the two groups and then concat them, I get what I want:

But I have to do a lot of juggling:

And there are assumptions in that code that won't work for other cases. (If I delete channel B and substitute channel E, it will concat B & E).

[CoastalMaineBird]

You consider them a pair but TDMS does not think that way. 

--- Yes, that's becoming obvious.

Looking at the code, there's nothing special about the TIME channel.  It's just another channel, so there's nothing to go on, as far as the TDMS innards are concerned.

[Wayne.C]

I suppose you could start a new group everytime something changed in the channel count.  Since the juggling on the back end is the same for each group, a FOR loop could handle the repetition.

Give it an array of group names to read and turn it loose?

[CoastalMaineBird]

Trying to use the SET NEXT WRITE POSITION function on just channel D, I get nothing but errors: "Invalid Group / Channel Name" at that function call.

Don't understand how that works - it doesn't accept an array of names, only a single one.

The one I just gave it.  No data is written for that channel yet, though.

[CoastalMaineBird]

I suppose you could start a new group everytime something changed in the channel count. 

Well, yes. That's not too much different from having a separate file when something changes.

I don't see how to look at the whole file in that case though.

I have to do the transposing and re-transposing myself, though performance on the READ side is not critical.

See above.  But there are cases that won't handle: If I delete channel B and substitute channel E, then the data should NOT be concatenated, but it will be.

If I force the user to look at one segment at a time, it'll be OK.  But as far as using the Technical Data Management System for actually Managing my Data, it's leaving an awful lot up to me.

[Wayne.C]

I don't think you will be deleting channel B, you will just stop logging to that channel in the TDMS and start logging to channel E.  In the end you should have data for every channel you ever wrote data to.   The problem would occur if you stopped logging to "B" and then resumed at a later time.