Waveform file versionitus

[10Degree]

Dear All,

Can someone please enlighten me on the finer points of reading and writing waveforms to files?  Every new LV version brings the dreaded "you must convert your datalog file and make it unusable in previous versions of LabVIEW" message.  I know that you can modify your INI files to include the "do the conversion without asking" flag to avoid the dialog boxes, but the conversion and compatibility problem still exists between versions.

Why does this go on?  Is it because the waveforms are being stored in datalog files and the file format is changing from version to version?  I don't think that the waveform datatype has changed since 7.1.

Since the waveform datatype doesn't change, wouldn't it make sense that the read and write waveform vi's and the files that they create remain unchanged as well? 

NI seems to love breaking file compatibility from version to version of their products.  I can *kind of* forgive them for doing this to code files (vi's, project files, etc - although I don't like it) but it sure makes life as a developer / distributor / user a bit of a living heck.

This post has turned into a bit more of a commentary than a question - and I apologize for that, so let me end with a question:  Is anyone aware of a third-party option for reading and writing waveform data to files that will not break between LabVIEW versions?

-cb

[Ben]

---

10Degree wrote:

Dear All,

Can someone please enlighten me on the finer points of reading and writing waveforms to files?  Every new LV version brings the dreaded "you must convert your datalog file and make it unusable in previous versions of LabVIEW" message.  I know that you can modify your INI files to include the "do the conversion without asking" flag to avoid the dialog boxes, but the conversion and compatibility problem still exists between versions.

Why does this go on?  Is it because the waveforms are being stored in datalog files and the file format is changing from version to version?  I don't think that the waveform datatype has changed since 7.1.

Since the waveform datatype doesn't change, wouldn't it make sense that the read and write waveform vi's and the files that they create remain unchanged as well? 

NI seems to love breaking file compatibility from version to version of their products.  I can *kind of* forgive them for doing this to code files (vi's, project files, etc - although I don't like it) but it sure makes life as a developer / distributor / user a bit of a living heck.

This post has turned into a bit more of a commentary than a question - and I apologize for that, so let me end with a question:  Is anyone aware of a third-party option for reading and writing waveform data to files that will not break between LabVIEW versions?

-cb

---

The attribute "Name of Digital Line(s)" attribute was added between LV 7.1 and LV 2009.

So everything should make sense.

Ben

[10Degree]

The waveform datatype did not change.  Attributes are stored in the variant that is part of the datatype.

[Ben]

---

10Degree wrote:

The waveform datatype did not change.  Attributes are stored in the variant that is part of the datatype.

---

I'l leave that as a symantics issue.

I'd stioll suspect that what gets written to file has been changed to allow the attributes to survive a save/restore.

Ben

[10Degree]

I don't want to debate semantics, but I appreciate your insight into the internals.  My point is that since the waveform datatype has not changed, the serialization to and from files, and the file format should not need to change.

I am looking for a version-independent way of reading and writing waveforms to binary files so that I don't encounter this issue in the future.  I attached some hack code.  I know it will require some fortification, but do you think that this would accomplish a version-independant serialization?

Thanks,

-cb

[altenbach]

It could be more generic how clusters are flattened. I think there was a change once....

[Ben]

---

10Degree wrote:

I don't want to debate semantics, but I appreciate your insight into the internals.  My point is that since the waveform datatype has not changed, the serialization to and from files, and the file format should not need to change.

I am looking for a version-independent way of reading and writing waveforms to binary files so that I don't encounter this issue in the future.  I attached some hack code.  I know it will require some fortification, but do you think that this would accomplish a version-independant serialization?

Thanks,

-cb

---

I don't think so.

Burried inside the read and write is (probably, but not sure because not NI) either a flaten to string or a type case that use the data type taht you specify. Since the nature of the data is dictated by NI and the version, it can break durring an upgrade. The most non-volitle method that comes to mind would requiring pulling out each part and writting them to file as an array of U8 or whatever. Using that approach you get control over the file structure as well as responciblity for it. I don't think that would be near as fast as what you have illustrated.

Another approach would be to write the data to TDMS which is theoretically immune to file versions changes. The new TDMS add-on for Excel even lets you open them striaght from Excel.

Just trying thelp out,

Ben

[10Degree]

Ben,

I did a little test where I used the method I presented to write 8.6 and 2009 waveforms to files, and then was able to read them back in 8.6 and 2009 (and visa versa).  Not a thorough test, but would suggest that a version-independant method could be created.

-cb