> > If you were using ASCII G code you would have to read in a line
> > (some unknown number of bytes), parse out the command (figure
> > out it's a G102), find the parameters, convert them from strings
> > ("12.72") to numbers, then execute them. All that takes a lot of
> > time and memory for a small processor like an Arduino.

> Almost like I said, except for the "takes lots of time and memory." It
> doesn't really take noticeably more memory and it doesn't take that much
> extra time.

> > capable of 115 kiloBITs per second

> Not exactly but close.. 115200 baud is about 11k bytes/second but, anyway,
> lots of RAMPS (which runs an Arduino Mega) people are using 250,000 baud
> since it's less error prone than 115200 baud.. Text gcode tends to be about
> 30 bytes per line so that's well over 350 lines/second at 115200 and over
> 650 lines/second at 200k baud.

> How fast do you think machines consume gcode?

> > a normal speed to read a file off an SD card is 250 kiloBYTEs per
> second, which is ~16x faster

> Er... So? What if it could read a gigabyte per second? Would that be even
> better?

> I'm not arguing against binary or SD cards - I just don't think they're as
> much of an advantage as people seem to think. Once toys like TinyG get
> here, printers using that will probably need binary and/or SD but todays
> fastest machines can be perfectly happy with plain ol' ASCII gcode over
> USB..

> On Saturday, November 17, 2012 10:18:47 PM UTC-5, Michael Cook wrote:

>> I'm not sure that's entirely correct. Bytes is bytes, ASCII or not..

>> True, but binary can be more compact that ASCII, aside from other issues.

>> Everything Jetguy said makes sense to me. There is a document<https://github.com/makerbot/s3g/blob/master/doc/s3gProtocol.md>in the Makerbot GitHub repository that provides the specification for
>> exactly how s3g and x3g files work if anyone is interested.

>> From a quick skim it looks like s3g might be slightly lower level (i.e.
>> one G code may cause multiple s3g commands). The biggest gain I would
>> expect is that since you're using a binary file, you know that you need to
>> execute command 87 with numbers 7, 12, and 42 as parameters.

>> If you were using ASCII G code you would have to read in a line (some
>> unknown number of bytes), parse out the command (figure out it's a G102),
>> find the parameters, convert them from strings ("12.72") to numbers, then
>> execute them. All that takes a lot of time and memory for a small processor
>> like an Arduino. Binary is easier, faster, and more compact. From two
>> ulta-quick spot checks, it looks like s3g is ~20-30% smaller than the ASCII
>> gcode file.

>> As for USB, the Arduino Mega used in a Thing-o-Matic acts as an old
>> fashioned USB to serial adapter, capable of 115 kiloBITs per second.
>> According to a post on the Arduino forum<http://arduino.cc/forum/index.php?topic=66241.0>,
>> a normal speed to read a file off an SD card is 250 kiloBYTEs per second,
>> which is ~16x faster. I don't know if the Replicator boards can transfer
>> data faster over USB.