From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview not reading csv file properly.

Solved!
Go to solution

I'm trying to use the read spreadsheet file vi to read the attached csv.

 

It does a few things incorrectly:

 

1) the first cell of the resulting array has ÿþ appended to the front of it, seems like labview is grabbing some special character it shouldn't? (Notepad, notepad++ and excel can all open the file without issue and none show ÿþ or anything like it).

 

2) It's mistreating the EOL characters as two line feeds, resulting in blank rows between each data row. (Looking at the csv in notepad++ confirms that the lines are ended with a CR and a LF (same as EOL).

 

3) I'm reading it in as a string, because one of the columns is non-numeric, but then I strip that column out and attempt to convert the remaining string array into a numeric array (this fails). It also fails if I pull out an individual element of the array and attempt to convert it to a number (in both cases using fract/exp string to number), below I have an example of trying to read the 2nd column of the 1st row (index: 0,1) which is formatted as a string: "1.37238168716431" and converting that into a number gives 0 as you can see in the snapshot of the front panel.

 

 

Capture.PNG

 

Capture.PNG

0 Kudos
Message 1 of 17
(5,853 Views)

1. this is BOM (byte order mark), indicates that the string a in unicode.  Notepad, Notepad++, and Excel eat this.  LabVIEW gives you the raw string.  Excel also eats the quotes (" ").

2. if you use Read from Text File Function, right click on it, uncheck Convert EOL.

3. convert the unicode string to ASCII first. If you show this string in "\" mode, it will looks like this: \01\00\.\00\03\00\09\00\05\00

 

 

 

George Zou
Message 2 of 17
(5,838 Views)

Except for the first few characters, every other character is Null (x00). There are no carrige returns (x13) in the file. Linefeeds occur in pairs separated by a Null.

 

The first two characters are xFF and xFE.

 

Was this file created by a program running in a language which uses unicode characters?

 

Lynn

Message 3 of 17
(5,832 Views)

Forgot the Convert EOL mode. Thanks George. The file does contain carriage returns.

 

Lynn

0 Kudos
Message 4 of 17
(5,827 Views)

I guess the file is in unicode, that doesn't help me very much.

 

I don't use the "Read from Text File Function" - at least not directly, although it is called in Read from Spreadsheet File. Where is it called, however, right-click doesn't show an option for Convert EOL, instead it's a terminal and it's default is F and as the terminal is disconnected, I'm assuming it's not converting EOL. So it's already "unchecked" in a sense.

 

No idea how to convert the unicode string to ascii. (no functions show up when i search unicode or ascii in the manager). It displays it just fine in the text box, so I'm not sure why it's able to display it without issue but not read it as a number.

 

Using Labview 8.6, by the way.

0 Kudos
Message 5 of 17
(5,800 Views)

Tried to convert unicode to ascii using tools found:

 

https://decibel.ni.com/content/docs/DOC-10153

 

Didn't work. the string goes from 1.423 (or whatever) to ?.??? after the converter.

0 Kudos
Message 6 of 17
(5,796 Views)

Open the csv file in Excel, and use save as to convert to an ASCII csv file.

Then you code will work.

 

Notepad and Excel are for ordinary users.  They don't need to know BOM, or unicode.

LabVIEW is for programmer.  We need to know the truth.

 

 

George Zou
0 Kudos
Message 7 of 17
(5,792 Views)

Converting in Excel is not exactly a solution.

 

The whole point is to have Labview read the file.

 

If it can read the characters and display them properly, logically it should be able to recognize that "1.395" can be converted to a number.

 

Again, look at the screenshots, it works just fine to display the text, just not to convert it.

0 Kudos
Message 8 of 17
(5,791 Views)

> Converting in Excel is not exactly a solution.

> The whole point is to have Labview read the file.

 

I know.

Just to prove the concept.

 

 

George Zou
0 Kudos
Message 9 of 17
(5,784 Views)

Okay,

 

I did that and you're right, things got better.

 

It still can't convert 1.3956 to a number though (it loses everything after the decimal even though I'm using Fract/Exp String To Number.

 

But at least now the line feeds are properly interpreted.

 

So, how can I convert the file using Labview or have it properly read in a unicode csv file?

0 Kudos
Message 10 of 17
(5,781 Views)