Welcome to Synthiam!

Program robots using technologies created from industry experts. ARC is our free-to-use robot programming software that makes features like vision recognition, navigation and artificial intelligence easy.

Get Started
Asked — Edited

Filereadline Question

Recently I have been working with a text file from which I read a series of comma delimited lines. Each item represents a series of numbers, like this:
27,28,29,31,32,34,35,37,38,

The problem is that the FileReadLine function strips out the commas and reads the line as one huge number. It even adds exponent notation such as +E25 to the end, so I know it is interpreting it as a number. Worse yet, if the data is a line of zeros, like this:
0,0,0,0,0,0,0,0,0,

It will ignore it entirely and return a blank string. I even tried using the ToString Function wrapped around the FileReadLine function, but it still didn't work. I finally Tried using semi-colons in place of the commas, which worked. So I have a work-around for this particular file. Though now I seem to have a problem with the split function on the lines, but that's another issue. Comma delimited files are common. It would be helpful to be able to read them properly, regardless of content. (Except, of course, if they contain a left paren :) )

AI Support Bot
Related Content
Synthiam
#1  
Have you seen the Reading and Writing Files tutorial from the Tutorials area of the Learn Section? I think Step 7 would be helpful for reading file lines with comma delimited data.

If you are still having problems please share your code so we can review it.
PRO
USA
#2  
looking to the last WBS0001 script, i think is very familiar how it works Reading & Writing files.

To avoid rushing a conclusion (quotation marks in other thread), i did a test:

Code:


$filename = "C:\Users\ptp\Desktop\test1.csv"

if (FileExists($filename)=true)
FileDelete($filename)
endif

FileWriteLine($filename,"1,2,3,4,5,6,7,8,9,0")
FileWriteLine($filename,"1, 2, 3, 4, 5, 6, 7, 8, 9, 0")
FileWriteLine($filename,"a,b,c,d,e,f")
FileWriteLine($filename,"a, b, c, d, e, f")
FileWriteLine($filename,"1.2.3.4.5.6.7.8.9.0")
FileWriteLine($filename,"1. 2. 3. 4. 5. 6. 7. 8. 9. 0")
FileWriteLine($filename,"1;2;3;4;5;6;7;8;9;0")
FileWriteLine($filename,"1; 2; 3; 4; 5; 6; 7; 8; 9; 0")

Sleep(1000)

FileReadReset($filename)

$line_1 = FileReadLine($filename)
print($line_1) # => 1234567890
$line_2 = FileReadLine($filename)
print($line_2) # => 1, 2, 3, 4, 5, 6, 7, 8, 9, 0
$line_3 = FileReadLine($filename)
print($line_3) # => a,b,c,d,e,f
$line_4 = FileReadLine($filename)
print($line_4) # => a, b, c, d, e, f
$line_5 = FileReadLine($filename)
print($line_5) # => 1.2.3.4.5.6.7.8.9.0
$line_6 = FileReadLine($filename)
print($line_6) # => 1. 2. 3. 4. 5. 6. 7. 8. 9. 0
$line_7 = FileReadLine($filename)
print($line_7) # => 1;2;3;4;5;6;7;8;9;0
$line_8 = FileReadLine($filename)
print($line_8) # => 1; 2; 3; 4; 5; 6; 7; 8; 9; 0

FileReadClose($filename)


The file content is correct (FileWriteLine OK)

The problem is when you use FileReadLine to read a line with numbers and commas (line 1 content is NOT OK).

It seems a EZ-Script string bug.

a quick workaround, add a space after the comma (line 2 is OK)
#3  
Hummm, that is interesting. I suppose that workaround is not handy if the extra space causes an error if the data is read and reused.
#4  
@JustinRatliff and ptp

Thank you both for your comments.

It may be that adding the space works because doing so added an alpha character to each item. That changed the number to a string of a combination of a number and and an alpha character. Probably get the same results by adding a letter or symbol to each. The space, of course, is the best choice. Naturally that means you have to remove it as you rip off each value in the string (a simple thing to do). Still, it's also a good work around and maintains the comma as a valid delimiter. Thanks for the idea.
#5  
The fact that EZ-Script attempts to automatically determine the variable type is great for beginning programmers, but leads to this kind of issue. I wonder if the best way to solve this is to have an optional variable type declaration script statement that would override the automatic typing or if there is a better way to solve this.

Alan
PRO
USA
#6  
another workaround is to start a line with a non numeric character e.g:

x,1,3,5,7,9
x,2,4,6,8,0

when parsing the string ignore the first value e.g. x