Read from Delimited Spreadsheet File is merging cells

[Dhouston]

Hello all.  We are using Labview 2016 and are using the Read From Delimited Spreadsheet File function to read values from a spreadsheet and input those values into controls on our program.  Some values are text and other are numerical.  The spreadsheet is laid out that all data is in two rows; the first row is text data (descriptions) while the second row is mostly numerical values.  We chose the String polymorphic instance for the function and used the String conversion functions to convert the numerical values to strings for the front panel controls. 

However, we kept getting errors when running the program.  We used probes and saw that the Read From Delimited Spreadsheet function was actually merging cell values.  So if cell 1 has the value "Setpoint" (a string)  and the next cell has the value 4 (a number), the probe is showing the value Setpoint 4, which doesn't work for us because our program is set up to get a value in each cell of the spreadsheet.  So the program would never see that the setpoint is 4 because the 4 got sucked into the "Setpoint" descriptions.

We used this same setup in another program, but set the Polymorphic instance of the Read From Spreadsheet function to Double, and it did fine.  Is there a particular caveat of the string polymorphic instance that concatenates cells instead of reading them separately?

Thanks.

[RavensFan]

My guess is that the separators you have between columns are not being used consistently.

But that is only a guess because you haven't attached a VI or an example of the file that is giving you problems.

[Kyle97330]

 Can you post the actual VI?  Also maybe a sample data file?

The most likely problem is the "Delimiter" value.  By default it's set to "\t" (Tab) but it sounds like you need to set it to a space or a comma or something to that effect.  Using floating points as the input automatically skips the bits that are non-numeric, but a string can be interpreted as literally anything other than the delimiter value or a newline, so it doesn't filter anything.

What generates the "spreadsheet" file in the first place?

[altenbach]

---

@RavensFan wrote:

My guess is that the separators you have between columns are not being used consistently.

---

My guess too.

Please attach a typical file and a simplified version of your code. Sometimes, users manually edit these files and e.g. replace tabs with spaces, or even multiple spaces. Where is the file coming from?

[Dhouston]

Ok, attached is the file and a snippet of the problematic portion of the program.

Kyle97330

-We created the spreadsheet file ourselves using OpenOffice.  The program reads from it.  Our program will be an executable, by the way.  The intent is that if the program is shut down, or default values need to be changed, we can change the values in the spreadsheet instead of having to redo the program to change items.

[altenbach]

There are no commas in your file, so why are you defining a comma as delimiter? Just leave that unwired.

(... and don't call the file *.csv if it isn't 🐵

[altenbach · Accepted solution]

After removing the delimiter input (reverting to the default tab character), things seem to work just fine.

(Also, use "index array" to get the second column, no need for reshaping and subsetting :D. Why are your numbers floating point? The all seem to be integers.)

[Dhouston]

Yes, that did solve the problem. 

In answer to some of your other questions:

There are no commas in your file, so why are you defining a comma as delimiter?  Just leave that unwired

-We have several labview programs that use the csv type of file.  It always worked for us, especially since different PCs with different spreadsheet programs (e.g. Excel) access this same file at times.  This was the first time we dealt with the String Polymorphic instance, as we usually use Double since we deal with numbers much more often.  The comma delimiter was always needed to make the cell values line up correctly.  Anything else either merged cell values or distorted them in some way.  This was the first time that the comma delimiter gave us an issue.

(... and don't call the file *.csv if it isn't )

-We always had to put the .csv on the file so the programs could read it.  If we left it off, the file turned into a file type that was unreadable.   The file type would just be File instead of .csv, .odt, etc.  Labview would always vomit with an error if we didn't have an extension in the name.

Why are your numbers floating point? The all seem to be integers.

-Our numbers are floating point because other parts of the program having floating point values that compare to these values, and those values come from DAQ modules where we need the decimal precision.