LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

The best way to save data in my situation

Hi guys,


First of all thanks for helping me, i am bit new using labview enviroment.

 

I am working with a circuit that is going to return me some data, voltage. I want to save this data like each 5 min or about. My question is:

 

Is it better to use a .txt file that stays opened and the file is recording the data or maybe export to a DB? 

 

My other question is, if i use the .txt column recording, i haven't exactly found how to record in columns. I know how to do after something that has been previosuly written but i haven't achieved writting in columns.

 

I just wanna do the best and less problematic thing to record values.


Best regards!

0 Kudos
Message 1 of 7
(3,587 Views)
Well the decision about text file vs database can be resolved by answering the questions, "What will the data be used for?" and "Does the data have any archival value?"

If the data is just a quick test that in a week will be without value, don't worry about the database.

If on the other hand this data that you are going to be referencing over time and be using to make engineering decisions, go with the database -- andne sure to store adequate context for the data too...

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 2 of 7
(3,567 Views)

If you are writing a Text file, then you are writing data as strings.  If your numbers are integers, you convert the integers to strings (say, the number "23" to the charcters "2" (42 in hex) and "3" (43 in hex).  If you just write this out with nothing else, then when you follow by writing, say, the number "45", you'll end up with the string of charcters "2345".

 

So you need to separate your characters when you write out text.  One way is to write a "separator" character -- comma and Tab (Hex 😎 are common choices.  Files using commas as separators have a special name -- CSV (Comma-separated Variables), a format that Microsoft Excel knows how to read.

 

Another common separator is the New Line character-or-characters.  This is a little bit OS-dependent, but LabVIEW can generally read them all.

 

When you use the LabVIEW Write Text function, you might notice it (sometimes) has a two-arrow symbol in the lower-right corner.  This stands for Carriage Return (the arrow that goes down-and-left) and Line Feed (the arrow that goes down).  With this on, each call to this function should write a new line of text.  Without it, they will all appear on the same line.

 

Hope this clarifies things somewhat.  If you are unclear, write yourself a tiny LabVIEW routine that generates some data, convert it to strings, and try writing various (tiny) Text files and see what you get.  Experimentation on your own is a good and fast way to learn some of LabVIEW's quirks.

 

Bob Schor

 

P.S. -- it's a good thing I take my own advice!  My description of how to write multiple lines is not quite right.  If, for example, you call Write to Text File and give it the strings "1", "2", "3", "4", "5" (generated, say, by a For loop), you'll get "12345", even though a quick read of the Help says that it will write them as lines.  The trick is it writes arrays of strings as lines.  The attached Snippet, in which I added "Build Array", gives me a one-column output.

 

Write String.png

0 Kudos
Message 3 of 7
(3,553 Views)

Hi Mike,

 

The data is going to be used to answer engineering decisions, yes. By the way that was my main issue to determine if using .txt / .csv was strong enough for that purpose. My focus in textfiles was because i am not really used with labview and maybe using database will become a little bit more difficult, i don't really know. Actually, i am gonna think about the database. 


Appreciate your help.

0 Kudos
Message 4 of 7
(3,511 Views)

Hi Bob,


Thanks for your help!

 

I didn't see the arrow of the array, and really thanks for editting after u answered to solve your little mistake. THe problem as i've answered to mike is that i don't know if the .csv will be good enough to my purpose. The data that i will obtain probably is going to be analized graphically and i don't wanna have any problem about file corruption, mistakes in the write action etc...

 

Regards!

0 Kudos
Message 5 of 7
(3,509 Views)

Another alternative is to save your data files to TDMS.  This works well for "sweep" type measurements.  For example, an RF Power gain sweep.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 7
(3,480 Views)

I too am usually a fan of TDMS.  It has some of the features of a database (reading values based on looking up names, not column or row indexes), it has a relatively small file size with ideally just a few kb for index information with data being stored as binary, and is generally easy to work with.  It isn't the only solution, and as others have said, for quick logging a CSV is generally the easiest, with the Write Delimited Spreadsheet allowing to append data easily.  Text is also a format that everyone can read without any extra tools like a TDMS viewer, or database reading tool.  In your situation I'd just stick with a text file, and I'd recommend you get more familiar with TDMS and databases to best understand when to use one over the other in the future.

0 Kudos
Message 7 of 7
(3,454 Views)