SD printing

[splitbrain]

As talked about on gTalk - prinitng via SD card would make things a bit more reliable with crappy USB connections.

As requested, here are some logs from the teminal when printing via SD:

Send: M20
Recv: Begin file list
Recv: OPEN_B~1.GCO
Recv: BOX1.GCO
Recv: BOX2.GCO
Recv: WAFFEL1.GCO
Recv: FANHOLD1.GCO
Recv: FANHOLD2.GCO
Recv: BUNNYS3.GCO
Recv: FANMOUNT.GCO
Recv: WAFFELEI.GCO
Recv: HUXLEY_F.GCO
Recv: COMPCUBE.GCO
Recv: BENDER.GCO
Recv: TRASH-~1/
Recv: CAGE1.GCO
Recv: CAGE2.GCO
Recv: RJFRAME.GCO
Recv: RLEDMT.GCO
Recv: TCUBE.GCO
Recv: ALIEND.GCO
Recv: ADRED3.GCO
Recv: HNDCG2.GCO
Recv: HNDCG1.GCO
Recv: BATTERY.GCO
Recv: End file list
Recv: ok

Send: M23 box1.gco
Recv: File opened:box1.gco Size:193158
Recv: File selected
Recv: ok

Send: M24
Recv: ok
Recv: Kp 2.00
Recv: Ki 0.01
Recv: Kd 20.00
Recv: PID_MAX 255
Recv: PID_I_MAX 125
Recv: NZONE 5

Send: M27
Recv: SD printing byte 534/193158
Recv: ok

[foosel]

Thanks again for the input.

Hm... This looks quite different from what's specified for M21 in the RepRap Wiki (http://reprap.org/wiki/G-code):

M20: List SD card
Example: M20
All files in the root folder of the SD card are listed to the serial port. This results in a line like:
ok Files: {SQUARE.G,SQCOM.G,}
The trailing comma is optional. Note that file names are returned in upper case, but - when sent to the M23 command > (below) they must be in lower case. This seems to be a function of the SD software. Go figure...

I have the feeling that the parser for this output might have to be quite flexible... ;)

[splitbrain]

I wouldn't even implement the listing mechanism. Instead I'd do it this way:

• have a checkbox to "enable sd buffering"
• when checked, all data is printed to a predefined name, eg. octoprnt.gco (8.3 filenames only)
• load the known name (no need for listing)
• issue the print from sd command
• monitor sd progress until finished

The next time you print, the file is overridden. No need for list parsing, the sd will never grow full, relatively easy and still has the benefit of secure printing.

[jkeegan]

Ehh, while I agree that the above "sd buffering" feature would be good, it'd still be nice to at least have a feature request logged that let you actually browse the contents of an SD card - perhaps split this issue into two separate issues?

The tricky part with files on the SD card is that you don't have them in octoprint to do gcode analysis on, and there doesn't seem to be a standard mcode to fetch the file from the SD card via the printer (at least that I can see). So there would be a disparity between files already on the printer and ones in OctoPrint. The thing is, it IS pretty damned handy to be able to put files onto the SD card from just anywhere (even with the file-upload feature in octoprint).

[foosel]

Don't worry, if anything I'll add SD buffering AND browsing and printing of existing SD content.

[foosel]

Implemented :)