Hi Michaal,
Reading the TDM header file with a standard XML function set would be pretty straightforward, though the structure in the TDM file is not drop-dead simple. The good news is that you just need to focus on the "<usi:include>" block declarations in order to discover how to read the binary data. The bad news is that not all TDX files can be read with a DAT header file. The DAT header file uses a "number of values" integer to specify the start position of each channel inside the data file. If the channel data type is an I8 or U8, then you you can specify the start position of these channel values at any byte they happen to start on. If the channel data type is a DBL, though, then you have to specify the start position in multiples of 8 bytes. If the channel data starts at a byte position that is a multiple of 8 you're golden, otherwise you're hosed and can't read that channel's data with the DAT header. So it would be possible to programmatically create a DAT header for some TDX files, but there will be also be some TDX files where only some of the data channels can be read by creating a DAT header. I have a VBScript function library for creating DAT header files, and I also have VBScript code that reads the block information from the TDM file, but I haven't ever combined the two, and that still would only work for some TDM files. If you're lucky, though, it might work for all the TDM files you deal with.
But wait, it gets worse. With TDM files you actually have an XML header file. With TDMS files, which are what come out of SignalExpress, these are pure binary files that have a binaryy header at the top of each buffer written to the file. It's theoretically possible to create a DAT header assuming the TDMS file had only 1 buffer per channel, but as soon as you have more than one buffer per channel the DAT header cannot describe all the data in a channel. Dat headers not only have the limitation of specifying the start position in multiples of the channel data type byte width, but they also have the limitation that they can only describe channels with data in a single contiguous block. It's fine for data values from multiple channels to be interleaved in that one block, but if channelX has half its values in block1, followed by a binary TDMS block header, and the other half of its data values in block2, then the DAT file has no way of describing both blocks. Game over.
For years and years I created DAT header files on the fly to match the structure of data in ASCII and binary files, and I railed against these and other limitations in the DAT header property set, but there was nothing that could be done that enabled the DAT approach to transcend the limitations. You could theoretically use the free downloadable TDM(S) C++ library to build a GPI-DLL that could be used in DIAdem versions earlier than 9.0 to load both TDM and TDMS files, but that would be a LOT of work, and I wouldn't be able to help you with that. You might see if Matthias ["Twigeater"] from this forum or some other long-standing DIAdem user could help you build such a GPI-DLL, though it would probably be a billable project considering the effort.
Sorry for the bad news,
Brad Turpin
DIAdem Product Support Engineer
