Write to file Question

[JÞB]

Smercurio_

Good points all!  and no- I like XML fine but chose not to use it for data the I may want to re-use in other development enviornments.  If I worked eslewhere where we didn't code in just about any language well.  I'd probably flip sides.

And yes- my opinion of openG could be applied to any open source community.  my SSP is a good investment for my companies needs.

[smercurio_fc]

---

Jeff Bohrer wrote:

Smercurio_

Good points all!  and no- I like XML fine but chose not to use it for data the I may want to re-use in other development enviornments.  If I worked eslewhere where we didn't code in just about any language well.  I'd probably flip sides.

---

Not to belabor the point, but this makes absolutely no sense. XML can be read in every language - it's just a text file. Modern languages make it easier by having libraries specifically suited for reading XML using a DOM. For instance, I can create an XML file in LabVIEW and read it using, for example, C# just fine. The converse is also true.

I suspect your decision/bias is based solely on the LabVIEW XML schema, which is what is used if you use the Flatten to XML String functions. The XML file that is generated can still be read in with other programming languages. They won't have an equivalent function such as Unflatten from XML but that doesn't matter since you can simply read the XML file using the standard functions. In the reverse, if you create an XML file from, say, C# (or C, or VB, or whatever), the XML can be read in LabVIEW using the XML Parser VIs. The latter is more akin with what you do in "just about any language" anyway.

[DFGray]

I am late to this party but would like to bring up a few more options, and why they should be considered.  Text based files are cross-platform and (usually) human-readable, but they also have major disadvantages.

1. Text based files (e.g. INI, XML, CSV, etc.) require conversion from the original binary to ASCII before being saved.  Very often, resolution is lost.  The double data type has about 15 digits of resolution (54 bits).  Most text-based solutions save around 6 digits.  You lose almost two thirds of your resolution.  I having been burned by this and seen others burned by this multiple times. 
2. Text based files are very inefficient.  You must convert all data to binary before use.  They take up a lot more space than the original binary.  For example a double data type takes up eight bytes in a binary file, but can take up to 20 bytes in a text files, if stored in full resolution.  This is probably not an issue for you, since your data sets are small.
3. It is difficult and inefficient to seek to an arbitrary data point in a text file.  XML makes the problem worse, since you have to parse the structure of the file as well as the elements.  This may be an issue, but only if you don't read everything and cache it in memory.

What are the alternatives for structured data?

1. TDMS was created as a streaming data log format.  It has limited hierarchy capabilities, similar to INI files, but is sufficient for your purposes.  It is native to LabVIEW and has plug-ins to allow reading from most major analysis packages.
2. HDF5 is the culmination of decades of experience by the National Center for Supercomputing Applications. It is a highly flexible, hierarchical, binary file system.  It is my file type of choice for this type of application.  However, it has a very steep learning curve and the released DLLs cannot be easily called from LabVIEW, requiring some sort of wrapper code.  NI offers such a wrapper, but it is old (I am still using it, however). A Google search will produce several other HDF5 APIs for LabVIEW.  HDF5 is supported by most commercial analysis packages. It is about as close as anyone has come to a universal binary format.

I would try TDMS first, since it is much easier to use.