LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What's the best way to read/write data from a file (preferably a *.txt file)?

As in the title.  l have revived a couple of old VIs to read and write three numbers and a 1D array of clusters to/from a *.txt file.  The functionality is not very user friendly, and it would also be useful if one could open the text files (manually - not through LabVIEW) and still be able to see/understand what was there.

 

I was wondering if anyone would be able to come up with a more efficient and/or user friendly method (compatible with lv6.1) 

 

James



Never say "Oops." Always say "Ah, interesting!"

Download All
0 Kudos
Message 1 of 17
(4,331 Views)

There's a couple of ways to do this. Since your basic datatype is a cluster consisting of numerics and an array of clusters, I'm guessing you probably want to keep the data structure. In this case you can write out your data in XML format. You can use either the built-in LabVIEW functions for reading/writing XML, or use JKI's EasyXML Toolkit.

 

Another option is to use the .ini file format, although this may not be viable if the key values turn out to be long, since the .ini file format has a limit on key value lengths. OpenG has a number of functions in the "Variant" toolkit that can be quite helpful in this. 

0 Kudos
Message 2 of 17
(4,335 Views)

The format here is named datalog file. The data log format is convenient for labview users, but for non Labview programmers it is a bad thing. As to my knowledge this fileformat is not documented by NI(I maybe wrong here). But the format is compact and much faster compared with ASCII formatted files. Large ASCII formatted files may take ages to read and format into numeric values. The datalog file format is also easy to use in Labview since it is Record-oriented. So you have to choose Speed and easy labview handling, versus non labview compatibility.

 



Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)
0 Kudos
Message 3 of 17
(4,329 Views)

I have OpenG already installed, and use several aspects frequently, though I've not really had much experience with variant manipulation. Smiley Indifferent

 

Coq rouge, i must confess that i do not really understand what you mean on account of not being very programatically literate!  (Only been using LabVIEW for a year, and only used QBasic before that)

 

I know this may seem like the easy way out (and it is), but I was vainly hoping there'd be a relatively easy modification that someone could explain/do so's I could get on with the next steps in my project! Smiley Happy



Never say "Oops." Always say "Ah, interesting!"

0 Kudos
Message 4 of 17
(4,334 Views)

I just noticed you're asking for something compatible with LabVIEW 6i. That's certainly a big factor. I don't honestly remember if 6i had XML functions.

 

If your primary goal is to have a human-readable file format then you must come up with a format for how you're going to format the text since you have arrays of clusters. The cost, as mentioned, is that you will have much larger files. 

 

As for your other comment regarding the VI: "The functionality is not very user friendly". What do you specifically mean by this? What don't you like, and what do you want to change?

Message 5 of 17
(4,332 Views)

My primary goal is to have something that works and is easy and comprehensive to operate.  Generating a human-readable file is just a bonus but would be nice if it could be achieved.

 

I enclose pictures of the initial file dialog (for both loading and saving the data - referred to as Spec(s) from hence forth), and of the front panel screen seen when  a) loading a spec and  b) saving a spec.  In the file dialog, you have to already know the exact string to input else you'll just be told the file doesn't exist (applies for both loading and saving).  When saving a spec, you cannot see any files previously saved, nor even any previous specs saved within the file.  This means that one can unwittingly overwrite specs without realising it.

 

I'm not sure if I've explained this very well, but the current functionality means that far too much can go wrong.  Additionally, if you forget the file name, you'll have no way of knowing what it should be (the data files are stored on a 'locked' part of our network accessible only by Admin or through the LabVIEW executable



Never say "Oops." Always say "Ah, interesting!"

0 Kudos
Message 6 of 17
(4,306 Views)
I enclose the file generated from this process (includes three saved specs) which can be opened with any *.txt file editor.


Never say "Oops." Always say "Ah, interesting!"

0 Kudos
Message 7 of 17
(4,306 Views)

...any ideas...?

 

...anyone...?



Never say "Oops." Always say "Ah, interesting!"

0 Kudos
Message 8 of 17
(4,298 Views)

I don't have LabVIEW 6i, so my help will be extremely limited...

 


James Mamakos wrote:

In the file dialog, you have to already know the exact string to input else you'll just be told the file doesn't exist (applies for both loading and saving). 


This part doesn't make sense. Are you saying that in the file dialog if you navigate to a folder that has existing .LDS files then they won't show up in the listbox? I don't recall the file dialog VI working like this. 

 


James Mamakos wrote:

When saving a spec, you cannot see any files previously saved, nor even any previous specs saved within the file.  This means that one can unwittingly overwrite specs without realising it.


If I understand this correctly, an LDS file can contain multiple specs. When you select to save a spec you select a new or existing file, and provide the spec a name. If the file contains a spec by that name already, then it gets overwritten. This part also doesn't make sense since the writing of a record to an existing datalog file occurs at the end of a file, so you would end up with 2 specs in the file with the same name.Are you saying that's not what happens?

 

If you want to provide the user with the list of specs that are in the LDS file then you would need to read the contents of the selected LDS file and display the list to the user. 

 

 

0 Kudos
Message 9 of 17
(4,277 Views)

smercurio_fc wrote:

James Mamakos wrote:

In the file dialog, you have to already know the exact string to input else you'll just be told the file doesn't exist (applies for both loading and saving). 


This part doesn't make sense. Are you saying that in the file dialog if you navigate to a folder that has existing .LDS files then they won't show up in the listbox? I don't recall the file dialog VI working like this.


I didn't think it would work like that either, but I am describing what I observe, and you understand me correctly.  No previoulsy created files show up in the listbox, so you have to guess/remember what their names are.

 


smercurio_fc wrote:

James Mamakos wrote:

When saving a spec, you cannot see any files previously saved, nor even any previous specs saved within the file.  This means that one can unwittingly overwrite specs without realising it.


If I understand this correctly, an LDS file can contain multiple specs. When you select to save a spec you select a new or existing file, and provide the spec a name. If the file contains a spec by that name already, then it gets overwritten. This part also doesn't make sense since the writing of a record to an existing datalog file occurs at the end of a file, so you would end up with 2 specs in the file with the same name.Are you saying that's not what happens?

 

If you want to provide the user with the list of specs that are in the LDS file then you would need to read the contents of the selected LDS file and display the list to the user.



You also understand this correctly.  The files can contain multiple specs.  In the second of three pictures i attached in a previous message, you can see a drop-down (can't remember its proper name) which displayes the names of each spec stored in that file.  A mini graphical version of the spec lines for the one chosen is diplayed in the graph next to it.  That is for loading a spec.  However, if you want to save a spec into a file, you have no knowing of what specs are already there (see third picture).

 

I don't know how is the best way to do it, but perhaps something that works a bit like the  'Save As' and 'Load' functions of the Microsoft Office applications...?  Could something along these lines be achieved, or even for the current method to work as you say it should?



Never say "Oops." Always say "Ah, interesting!"

0 Kudos
Message 10 of 17
(4,266 Views)