Uwe

The file structure is flexible enough to allow defining the "data type" of a row at the time the file is written. Actually, the input to the SubVI is a variant, and the VI parses the type descriptor and then decodes the variant and writes it to a file. The restriction is that the control wired to the variant must be a cluster, and cannot be a nested cluster. But for the sorts of things we do here, that is a very minor (even logical) limitation. In addition to writing the data to the file, a header is written that completely describes the data type of a row. So, while you may not know what is in the file, it can always be figured out just by reading the header.

So, to read an arbitrary one of these files into labview, you would first have to look in the file, understand the header, and build a cluster of the appropriate type, to give to the "Variant to Data" function. If it is possible to do what I have asked here (which does in fact seem possible) then I can make a tool that would parse the file header and create a cluster of the appropriate type automatically. Indeed, if scripting becomes a little more powerful/mainstream, it would even be possible for me to programmatically create most of the code that you would need to read these files into labview, just by providing the tool a sample file.

All this is geared towards "code hacks"... code we write on the fly out in the lab to look at some random data file in some particular way that seems useful at the moment. But that is okay, because a lot of our data acquisition gets written that way too. It is pretty popular among the scientists here to want to grab three or four instruments, put them in some control loops, and write the data to file. Hitherto, this has meant dreaming up a file format (usually ASCII) on the spot. However, this was pretty irritating when it came time to read the files later and we could not remember exactly how we had written them.

So the fact that the new file format will let us write these nearly arbitrary clusters to disk the same way independent of cluster type is a BIG win. Now I am just tackling the problem of how to read the files back in a way that is also largely independent of cluster type.

Hope this answers your question!

George

At 04:36 AM 5/18/2004, you wrote:
Hi there,

"George Gatling (Contractor)" <[EMAIL PROTECTED]> asked on Mon, 17 May 2004 11:58:56 -0400 a Q about programmatically and dynamically creating data types in LV depending on given data feles including data descvription.

I have an file format that lets me store nearly arbitrary (though not nested) clusters in tabular (and binary) form... Now, I know I have some runtime limitations, but my question is aimed at the editing environment. Is there a way to build a cluster using the VI server? I imagine the executing VI creating a new VI and then performing operations on it that can only be done in edit mode (like define a cluster). The idea being that if someone gave me on of these files, I could use this tool to build the cluster and then in a second pass, use that cluster to read the file.
Allthough this seems to be possible one or the other way, I have no imagination to what this might be good for. If I get those file be read into any given ore dynamically created subVI, its data must be processed anyway. And this depends on the data type. And if I could do some assumptions on the data type(s) the whole procedure is determined.
Could someone please enligthen me?


--
Mit freundlichen Grüßen!
Greetings from Germany!
--
Uwe Frenz


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr. Uwe Frenz Entwicklung getemed Medizin- und Informationtechnik AG Oderstr. 59 D-14513 Teltow

Tel.  +49 3328 39 42 0
Fax   +49 3328 39 42 99
[EMAIL PROTECTED]
WWW.Getemed.de


George Gatling Applied Technology Division, SFA Inc. Space Physics Simulation Chamber US Naval Research Laboratory 202-404-5405 (phone) 202-767-3553 (fax)

If trees could scream, would we be so cavalier about cutting them down?
We might, if they screamed all the time, for no good reason. --Jack Handy






Reply via email to