LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TDMS: Unwanted untitled groups and channels; and Transpose array.

Hi I've neem making my first steps with TDMS files this week, and being mostly resistant to change, I'm using a 2D array of doubles as my data and creating TDMS files successfully mostly.  However I've noticed two things that seem wrong to me, both of which I can't find mentioned here so I'll ask in case it's just me:
 
1) When using 2D arrays of doubles, I always seem to get an unwanted group at the beginning of the file, no matter how many other groups I specify, And, to add insult to injury, each group I did specify has an unwanted channel in it.
It doesn't cause a problem as such as everything I set, and all the data, all appears assigned in the right places and can be brought out correctly, but it makes a mess of the TDM file when opened in Excel with an unwanted (untitled 0) first sheet, and and untitled 0 fake channel on the sheets for the groups I want.
 
When I'm writing to the TDMS file I write to two channels in 3 different groups.  The end result is that I get 4 groups, the first unwanted, untitled is empty, and for the 3 groups I want I get an extra untitiled 0 channel with no data in in addition to the 2 channels I've written.  Anyone seen this and is there a cure?  This behavior is present in the TDMS file when it is viewed, so is nothing to do with the TDM creation of loading into Excel etc.  I'm using LabVIEW 8.20, on Windows XP SP2.
 
2) I've noticed another problem with using 2D arrays with TDMS, and this one isn't me!!  
When using 2D arrays (DBLs), if you transpose the array before it is written into the TDMS file the results become skewed, with the items apparently written diagonally across.  I know what you're all thinking, I've got rows and columns transposed.  Try this yourselfs if you don't bbelieve me:
 
Create a dataset with 6 rows ansd 10 columns, first row all values are 1, second row all values = 2 etc. (last row all value 6).  If the 2D array is created directly like this then TDMS works fine.  If you create it the other way around and then use the transpose 2D array (to give exactly the same 2D array) then it goes wrong.  I'm not confusing rows and columns here, it is the same data when displayed in a 2D array indicator just before it's written.
 
Interestingly, if you convert the data to "Dynamic Data type"  before you send it to the TDMS write, then it doesn't matter how the data was created.......  It's similar to a but that existed in charts or graphs (can't remember which now) some years ago.
 
Cheers
 
0 Kudos
Message 1 of 7
(3,391 Views)

Hi Timpy,

Can you post some vi's that show this behaviour?

Thanks
Hannah

0 Kudos
Message 2 of 7
(3,368 Views)

Hi Hannah

A vi for point 2 I can attach easily, the other first one will take a little more time.  I've stuck instructions into the vi for running it but I very much doubt you'll need them.

Thanks for the reply.

Cheers

 

0 Kudos
Message 3 of 7
(3,360 Views)
The issue with transposing arrays has been reported to R&D for further investigation (CAR# 42BCLT3Q). A possible workaround is to add zero to your transposed array before writing it to file. The TDMS functions get "confused" by transposed arrays, and adding zero forces LabVIEW to reconstitute the array data. The conversion to dynamic data type was probably doing something equivalent, but hopefully this workaround is less processor intensive.

Message Edited by Jarrod S. on 12-15-2006 12:07 PM

Jarrod S.
National Instruments
Message 4 of 7
(3,351 Views)
Thanks.
0 Kudos
Message 5 of 7
(3,320 Views)

I just spent 2 hours trying to figure out why my data wouldn't come out right, even though I did the same steps as in a DAQMX example.  I finally found this thread on the forum.

This transpose problem needs to get fixed ASAP.  TDMS is for high-speed streaming, and I'm sure many of us cannot afford the performance hit taken by using the workaround.  A Transpose Data boolean on the TDMS Write and Read functions would be much appreciated, if it will improve performance over doing it in the app.

0 Kudos
Message 6 of 7
(3,276 Views)

LabVIEW representatives have been pressing how much better/faster they are.  I liked the data and database technology of the files. My old files are text.  So I had decided to convert my old data to TDMS and combine the environment files into one (environment files are the properties and sensor information of the old text files).  So I built a nice user interface to make it possible for the user to make decisions and then write the file.  After twelve hours wasted of my life, I find this one lone thread explaining the workaround.  That is a fast workaround BTW.  And was that the only problem? NOOOOOOOOOOOOOOOOO!  I also had the pleasure of experiencing another bug in the same VI at the same time.  You know the all confusing sub array of array thing.  I like that one.  So lets recap-2 bugs on first attempt.  My first thought was "were these even tested?". 

Sorry about my rambling.  I think I broke a couple of blood blisters and now I'm potential for stroke.

All being said, WHEN you fix this crap, they WILL be the next best thing to sliced bread!!

Any more bugs I should know about?

Chris Co 

0 Kudos
Message 7 of 7
(3,206 Views)