I have a few small "utility" gcode scripts that I keep on the printer's SD card. Occasionally, I'll update one of these scripts and rather than take the printer's SD card out, plug it into my desktop, update the file(s), and move it back to the printer I will just upload the script to the printer's SD card through OctoPrint. For small files, it's a little faster than the sneakernet approach. I would never upload actual print jobs to the printer's SD card this way.
So I had a question regarding the slow serial upload I couldn't seem to find an answer to elsewhere.
I plan on connecting my pi to my SKR 1.3 via the GPIO pins to clean up the printer a bit. Could this also positively affect the transfer rates to the printer's SD, or is there another bottleneck other than the cable/port itself?
Uploads to the printer's SD card are always going to be slow. The overhead of using a serial port for the connection is just too high.
I guess that's what I'm asking. if you're going from the GPIO pins on the pi to the TX/RX pins on the SKR, is it still a Serial connection? I'm showing a load of ignorance on the subject, but I guess what's considered a serial connection, and once you have a connection directly to the board rather than the USB port, could you up the baud rate to increase transfer speeds??
Yes, it is still a serial (RX/TX) connection.
1 Like
All you have to do is upload to sd and cancel after its done saving and starts streaming.. Then start your print. Less than a minute round trip and then you're not streaming the bits from pi. I've always had better results from sd than uploading to the pi but I'm using a zero-w. I don't know what its doing after uploading but if you're waiting for it to finish, quit doing that.
"Don't be afraid to break it! That's how you find out what it can do!" ~ me
So, sorry for jumping into the middle here, but I am very new to the RBPi/Octoprint lifestyle on my Ender3 and am interested in understanding the process. So when I click and select a .gcode file from my local machine, the file is uploaded to the RBPi (4B w/2GB in mysetup)? And then when I select [Load and Print], does that mean that the RBPi is send the code, command by command, to the Ender3? Is it expected and normal that printing this way takes longer than if I were to have the .gcode file on the Ender3 SD card and print from LCD? And btw, the reason I am even on this thread is because I was trying to find out what the [Upload to SD] function even does, because it is grayed out on mine.
Correct
Correct
Not really, but this can be the case with complex files since the Pi cannot push data into the printers command buffer quick enough. There are ways to increase the buffer size, involving flashing new firmware. If you are having issues with simple files, you may want to take a look at the terminal tab, it could be that there are a lot of resend requests which slow things down.
It will be greyed out because the printer doesn't say it has an SD card in, to OctoPrint. If you want help fixing that (if you do in fact have the SD card plugged in) I suggest opening a new thread as that's easier than this old thread.
Not quite. The problem is more that the regular 8 bit printer boards are overstrained by what they have to do. In addition to a SD card print: Recalculate the checksum, keep track of the line number, etc .
A Pi with four cores at 1400 MHz is way faster then an Arduino with one core at 24 MHz.
1 Like
@fyvstrang, How the Upload to SD option works has been detailed in the previous posts in this thread. I suggest you read through the entire post.
Most .gcode files are printed without issues over the USB serial connection. Files that contain a large number of very short commands (fine detail on the original object) can overwhelm the serial connection causing the printer to pause which can add blobs and other artifacts to the printed object. These files may produce a better quality print from the SD card but getting the file to the SD card should probably be done by physically moving the SD card between the system generating the .gcode and the printer.
Thanks! I will probably open another thread shortly.
@airscapes, So when you say "Upload goes to the pi" does it go the pi memory or the SD card in the pi running octoprint/octopi?
The RPi operating system is usually stored on the micro SD card which is often called the "boot device". It is possible on some RPi models to boot directly from a USB port instead which would then change the "boot device".
Many 3D printers also have an SD card (some micro, some full size) which is controlled by the firmware in the printer.
When uploading files via OctoPrint, the file will end up on the "boot device" if "Upload" is used and on the firmware controlled SD card if "Upload to SD" is used. Note that the "Upload to SD" option is often very slow because the file is transferred over the USB serial link, the same link that is used when you print a file from the RPi.
Hello,
Another usage (mine) . Sometimes the rasp meets some undervoltage (I tried multiple solutions to fix that without success, but it is not the topic of this question)
Then, when I upload directly into the SD card, octoprint is only used to "monitor" the print, in this case, no "data resent" and no error during print. Even with "undervoltage" issue.
I can't find if anyone here mentioned this reason, but in the case of the Prusa i3 Mk3 s+, the resume after failure function only works if the print is being run from the Prusa SD card. Apparently, it edits a temporary file as it goes so that even after power failure, a good record of exactly where it left off remains and it can be used to resume, or resume automatically. I had a recent case where a 56 hour print failed with 10 hours to go. It was heartbreaking. I managed to hack and slash a way through where I got something half-useable, but it would have been much easier if I had been running the job from the SD card. Hope this helps.
1 Like
This!
This is a very valid reason for you to push the gcode to the SD card instead of loading it on the fly from the pi.
The Prusa has a very sweet resume after failure support which you lose if you load the file directly from octopi instead of the SD card.
As others said, you will probably want to copy the file to the printer by moving the SD card to your PC, otherwise it will take ages to load to the file into the SD card if done via serial connection.
Quick back of the napkin math:
Assuming the serial streaming does not have any overhead (which I doubt but did not investigate), you would have (on a Prusa at least), 115200 baud, meaning 11520 bytes/sec
Even a rather simple 5MB gcode file would take, in the best possible scenario (and not accounting for any overhead of the copy process) around 7:30 minutes to stream from the pi to the printer's sd card.
The worst part being that you don't have any kind of progress indication on the UI for this process.
It's like the Internet in the 90's all over again 
So, you might want to get your ass out of the chair and go grab the sd card instead 
Edit: There's actually a pretty clear article about this in the FAQs:
and a thread showing that actually the effective bitrate is like 8 times slower than what my calculations above implied, due to the overhead:
I guess you don't realize that you have been printing from the Pi the whole time. When you upload to SD, it first saves the file to the pi, then streams it, actually copies it, to the SD card. If you cancel the streaming it has not copied the file to SD. So when you print you are printing from the Pi. Click the Wrench icon and tell it to show you only files stored on SD. Your cancelled streaming file will not be there.
interesting that is I chose upload to SD, it indeed takes too long to send the file somewhere, but SD card that is inside the printer does not have this file in the end.
anyone have seen this?
There is a good reason, at least on the Prusa XL 5T. I can't currently change which tool (i.e. color) to print with from the OctoPrint UI. I can do that from the LCD. Lot of times if I'm printing GEN2 storage or Gridfinity I like to vary the colors.
Also can just use PrusaConnect - it's very fast