gcode Execution

Sorry if this is a dumb question.

I understand that gcode can come from the serial connection or the SD card. I also understand that there is anecdotal evidence that it is more reliable for the controller firmware to execute the gcode from the SD card.

Do any of the available firmware options support reading gcode in from the serial connection and writing it to the SD card and then execute it from the SD card once the transfer has finished? If not, why not?

Thanks, Andy

Yes Marlin can do that but it is a lot slower than writing to the card with a PC.

---

[www.hydraraptor.blogspot.com]

I think he's suggesting writing to the card and printing from the card simultaneously, kind of using the SDCard as a big buffer, which I don't think Marlin will do.
Repetier Host actually converts the g-code to native Repetier Firmware instructions during the copy to the SDCard, but again you can't print from the file while copying it.
Both Repetier and Marlin Firmwares are VERY slow writing to the SDCard, several orders of magnitude slower than doing it on a PC, I've seen a single GCode file take 30+minutes to write to SDCard using Marlin.

If writing to the card is very slow then I don't think the card can be used as a buffer.

Thanks for the explanations!

Andy

Writing to SD card should be pretty much exactly as fast as the serial line. At 115200 baud, this should be about 12800 characters per second. In 30 minutes, that's no less than 21 megabytes.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Should be but isn't. I think it is just sent as lines of G-code whereas it would need to be sent in binary with large packets and a sliding window protocol to get close to the raw comms speed.

Also I doubt the FAT library is optimum for write speed.

---

[www.hydraraptor.blogspot.com]

Using an external RAM device for buffering instead of an SD card would be quick enough...

Is sending gcode over USB really much of a problem? Or does only affect Windows-based PCs?

Andy

Serial over USB has latency so protocols that send small packets and wait for a response before sending the next one are slow.

---

[www.hydraraptor.blogspot.com]

USB 1.0 polls for data every 1ms, so you have to be sending enough data in a single transfer to offset the latency introduced.
In practice the host sends a lot of very small data packets, so the latency between sends dominates.
USB2.0 has a 125uS polling rate.

Firmwares that use SD cards utilize the SPI Bus interface, not the one or four bit SD Bus interfaces. This is a synchronous 1-bit interface that is accessed in the arduino by bit banging I/O pins, as far as I know. This makes I/O limited by the speed the microprocesor can generate the SCK clock pulses.

[en.wikipedia.org]

-Rob A>

My understanding was that the arduino uses the hardware spi pins (it does on my ramps), just that sd cards are really really slow via spi. It'd be interesting to know whether the bottleneck is serial rate/usb overhead/slow sd cards, so we could fix it.