Cannot download files from SD card

[david-vo]

What were you doing?

I tried to download a file from the SD card, through the OctoPrint interface.

What did you expect to happen?

I expected my browser to download the (gcode) file

What happened instead?

Nothing happened. If I try to download a file that's stored in memory (ie updated to the Pi directly), it works. Could this possibly be due to SD card access issues on Flashforge (clones)?

Branch & Commit or Version of OctoPrint

v1.2.10 Master Branch

Printer model & used firmware incl. version

QIDI Tech (Flashforge Creator Pro clone)

Browser and Version of Browser, Operating System running Browser

Chrome browser on Mac OS X

Link to octoprint.log

[GitIssueBot]

Hi @david-vo,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Please take a look at the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2016-04-06 17:20) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[markwal]

Definitely sailfish doesn't support this. And even if it did, GPX does not. And lastly, you definitely wouldn't want to wait for a 10Mb file to download at 10K/sec even if we could figure out how to make the protocol deliver it batch mode.

It'll be better to figure out how to do this in a plugin that talks to a wifi enabled SD card or otherwise avoids the serial interface to the MCU. Plus, I'd argue upload would be way more useful.

[david-vo]

I definitely agree upload would be useful but download would be useful to (ie connected remotely and want to look at gcode on the SD card). Why is the transfer speed for SD card only 10K/s? You mean from the SD card via USB to the Pi is only 10K/sec? Feel free to close this and thanks for the explanation.

Edit: Actually, is there any way to put in some sort of warning or explicit message for Sailfish machines to say it doesn't support these types of SD operations? How would you detect it? Well maybe check firmware from OctoPrint if possible but a simple way is when the user chooses the machine, they can check a box that says Sailfish. If they are using Sailfish, then gray out or put a tool tip with info on why SD operations can't be done.

[markwal]

To be a bit more precise, 112,500 kbits (you might be able to get 250kbps, current firmware doesnt though) is as fast as that serial link to that 8-bit microcontroller can go. If you can saturate the channel (unlikely) you'd get about 14K bytes, but with a little packet overhead, parity, etc. 11K bytes per second is probably the theoretical maximum speed, but current protocol puts it waaay slower than that.

[david-vo]

Wow had no idea that there was some limitation in place, beyond USB speeds.

[foosel]

No GCODE based firmware I know of does support that either. Which is also the reason why there's nothing displayed in the GCODE viewer when printing from SD. Simply no way at all to access the contents of the printer's SD card besides getting a list of file names and maybe also file sizes.

Hence technically impossible to implement (unless you have wifi SD card in use, and that's way too uncommon to even consider this as a core feature).

[david-vo]

The limitations of accessing the SD card are explaining a lot of the issues I've been seeing. This probably also explains why I get no time estimates at all when printing from SD and why OctoPrint didn't know my file was done printing even 3 hours after completion. However, I am confused about something - if OctoPrint can't access anything from the SD card, how is it able to get the printer to print from the SD card? I confirmed this works (albeit in a "handicapped" way). Is it sending a command for the printer to do the print, in the exact same manner as a user selecting it from the printer's control panel/LCD, at which point it steps away and just streams the terminal output? Or is it somehow reading the GCODE off the SD card (not likely?) and sending the stream of commands (similar to a laptop and usb cable hooked up to the printer and using something like Cura to print directly to the printer)?

[markwal]

Yes, that's right, OctoPrint doesn't know how much has printed from the SD card. Most gcode based firmwares give progress in terms of bytes printed of total bytes from which an extrapolation can be made.

Actually, SailFish has that info internally as well as computes a time completion estimate. Unfortunately, the old RepRap protocol that MakerBot started from (s3g, later x3g) isn't very extensible in a backward compatible way so it doesn't have a way to pass the info back to the host. GPX always tells OctoPrint that the SD print is on byte 0 of 0 bytes, which is probably a mistake on my part since you could call that complete.

GPX should notice when the print is finished because it is polling by asking "are you still doing a build?" every time it also asks "what are your current temperatures?". However, the x3g protocol also doesn't have a notion of "are you still reading instructions from the SD card?" only, "are you between a StartBuild and EndBuild command?", so it only works if your end gcode has something in it that tells GPX to generate an EndBuild command: M73 100 should do it and also M137. If you have those and it doesn't recognize your build is over you should enter an issue on OctoPrint-GPX's issue tracker: https://github.com/markwal/OctoPrint-GPX

If you're curious about the x3g protocol, the documentation is here: https://github.com/makerbot/s3g/blob/master/doc/s3gProtocol.md. To print a particular x3g file from the SD card, the host issues command 16 followed by a filename in the current folder. The GPX plugin translates the sequence of GCODE commands M23 (select SD file) and M24 (start/resume SD print [aside: toggles in protocols are bad]) into a x3g 16. GCODE is human readable ASCII text originally intended to be a file format and x3g is a binary protocol with packet lengths and checksums originally intended to be over the wire, but eventually made into a file format as well.

[david-vo]

It seems like M137 is not being used or at least not being documented so M73 P100 seems like a much safer bet. My Simplify3D setup is on my home PC so I will make the change tonight and report back on the behavior. Would you recommend adding it to the very end of my end GCODE?

I assume GPX only comes into play when printing from x3g and not from gcode right? S3D saves both files so I have access to both when printing. Thanks for the explanation about using Octoprint to initiate an x3g print from the SD card. It works like I expected (sends command that says "print from SD". I assume this is effectively the same as manually choosing Print from SD from the machine's interface.

[markwal]

Whoops forgot the P: I have my M73 P100 as the first thing in my end g-code. It might be better at the end since the G1 Z155 F1100 can take a while. MakerBot Desktop uses M137 so a fair amount of the start/end gcodes that get passed around out there for our printer include it.

GPX comes into play either way. Something has to translate the gcode from the slicer to the x3g protocol. In the case of the SD card, it was Simplify3D calling GPX to make an x3g file. In the case of printing from OctoPrint's upload folder (gcode), it's the GPX embedded in the plugin.

Sending the command "print from SD" from the host is almost the same as manually choosing Print from SD from the interface. The one big difference is that if you do it from OctoPrint then OctoPrint knows it is supposed to take a timelapse, the GPX plugin knows it is supposed to ask "are you printing from SD" repeatedly until done, etc. If you do it from the LCD, OctoPrint is unaware that it happened. I may be able to do something about that by polling for state like that whenever OctoPrint sends an M105 through, but it may not be a good idea when printing from OctoPrint since it's one more Q&A that interrupts the firmware.

[david-vo]

I am fine with you not detecting prints from the LCD. The reason I switched to printing files on the SD, from OctoPrint, is you warned that it's potentially dangerous to print from OctoPrint (memory) in case there are communication issues. However, printing from the SD really sucks. There's no GCode preview, elapsed or remaining time, etc. The only positive part is it starts the timelapse, but as we discussed, it doesn't even know when the printing ends (at least until the user adds in the M73 line.

I think I am going to stick to uploading to OctoPrint and printing from there. Out of the three attempts, all three prints came out fine. And it means I don't have to walk between my garage and upstairs bedroom to load files on the SD card.

[markwal]

Yeah, that's what I do. I upload to OctoPrint and print from there and sometimes I slow it down when printing cylinders, but it's still easier than fiddling with the SD card (and as you point out, everything else works better too).

[david-vo]

Mark, I confirmed I already had M73 P100 in my end gcode but OctoPrint never realized the job ended. Going to file a bug in the GPX plugin repo like you suggested.