advice on using a run log file

[BenRup]

Hello,

I'm sorry if this info is out there, but most of the questions on this board are directed at writing instrument data to files.

I am trying to write a program that can keep track of its status from run to run.

During a run, the program can record an initial time stamp, and record some start and stop times.  I would plan on writing those pieces of information to text files.

I would like to be able to keep a log somewhere that includes running information, such as, "the last time stamp was number x associated with run y."

I could write out to a .csv and read it back in, but my experience is that I would have to put all of my information in arrays and I would like to avoid that if possible.  Perhaps I would write a copy of my information to a .csv to provide a human-readable option but that is all.

So I'm thinking I would have to look at the Storage/Data Plugin Pallette or XML.  Any suggestions?

Thanks!

[Dennis_Knutson]

XML can be used. For this sort of thing, an ini file is also often used. There are numerous posts on using this and a palette for reading and writing. OpenG has some handy functions as well.

[Bob_Schor]

You can learn a lot of interesting techniques by building (and looking at) the Sample Projects that ship with LabVIEW.  Something I learned (and have incorporated into my own code) are how to write Error Logs and Reboot Logs by following the example code in the LabVIEW Real-Time Data Acquisition (DAQmx).  I haven't looked at the non-Real-Time examples, but they also probably include the Error Log.

This turns out to be very easy to implement, and very useful.  It basically appends a time-stamped line (that you can easily tailor to fit your needs) to a specific named file, nicely discarding the (older) first half of the file if it grows past a certain size.  The data are simply text, so it is easily Human-Readable (and also easy for LabVIEW to read/parse).  It may suit your needs.

Bob Schor

[mikeporter]

Why the artificial distinction between "instrument data" and "status data"? Data is data and it is all important. In fact it is the status data that tells you its OK to trust the instrument data.

You have all the same options for either "type". Databases, various types of text files, whatever.

Mike...

[BenRup]

Hi Mike,

I made the distinction because I was under the impression that the TDMS file format was tailored to streaming massive amounts of data very quickly, which would be overkill and might introduce more trouble than it is worth, and also might not be as well tailored for doing things such as searching through the "data points" for a particular line number and its associated values.  

Under this assumption, I explained the nature of my data so that suggestions could more accurately match my requirements, if my limited understanding of the options was correct.  

I think that in general computer programming and usage, the different kinds of data storage are definitely NOT interchangable as you suggest.  For example, I would not use a database to store each sample of a 10 kHz data stream with one sample per db entry.

Cheers!

[BenRup]

Thanks everyone for the tips.  My problem is that due to unforseen holdups in other parts of my project, I am limited in the amount of time I can spend investigating the options and going through the samples.  

Thus I was hoping for a "yeah, using X would be a really clean and simple way to do this" so that I wouldn't have to learn the hard way.

Thanks,

Ben

[mikeporter]

Concerning your comment about the data stream, I would still use a database, but not like you indicated. That would be like storing a string in a database one character at a time. The basic datatype of the data needs to be preserved and the basic datatype of a waveform is just that, a waveform, not a single number.

Mike...