Hi, I'm new to 3D printing,still waiting for my Prusa i3 Mk3S to arrive, but in mean time I am setting up a Rapsberry Pi 4 with SSD, usb camera and Octoprint (OctoPi distro).
What will happen with printing when OctoPrint will stop somehow, due to software problem, OS problem, or power failure on the Rapsberry?
Is there some documentation how Octoprint works internally, for this question: how communicates with the printer?
So with the Mk3S there are two ways you can connect, either direct to the printer's serial/uart port on the printer (well documented on Prusa's site) or via USB from the pi to the printer's control board. In either case, if there is any form of software failure or disconnection between the printer and OctoPrint then gcode commands just stop being sent to the printer. This is not necessarily the same if you are printing a file from the SD card and using OctoPrint to control/monitor. In that situation the print would just continue but OctoPrint will not be able to control/monitor.
Thank you,
So when using octoprint, it and the computer it runs on, becomes an integral part of your 3D print system.
And the advertised feature of the Prusa printer "can continue after power failure" only applies when printing from a SD in the Prusa controller.
Why does Octoprint have to spoon feed the code to the printer line-by-line. What does Octoprint do for the print process that would not happen if the same gcode was run directly off the SD card without Octoprint?
Is it not possible to send the whole file to the printer's SD card then use Octoprint to control the printer whilst the code runs off the SD card. Since the MK3 controller software CAN recover from a power failure would this remove the power failure issue? If Octoprint crashes or hiccups for whatever reason won't the printer soldier on without Octoprint.
Uploading a file to the printer would take almost as long as the print itself because the file is sent to the printer line by line. This is a thing of the firmware.
When printing from SD card, you do not have all the feature of OctoPrint by hand.
All these questions have been discussed on this board within various threads.
There are a few things that don't work, and the vast majority of it is in the plugins that you can install. In the stock OctoPrint system, the gcode viewer won't work, timelapse (layer change) and some of the gcode scripts stuff is affected. With plugins there is no longer the option to monitor the gcode sent to the printer to either manipulate it or react based on something happening. Something like OctoLapse would be impossible to do, as it has to inject commands to move the printer head out of the way.
Sending the code line by line is not what I was thinking. My thought was to write the file as would be done in any other file move/copy operation. Shouldn't it only take a second or two, the same as when I send a gcode file to OctoPrint from PRUSA Slicer. If that capability does not exist why not.
So it is not possible for OctoPrint to transfer or write the file to the printer's SD card as can be done if that same card is installed in your PC is what I take from your comment.
The printer's SD card is connected to the printer and is not directly accessible from the RPi. The printer's firmware can transfer data from the USB port to the SD card but it does so at the USB serial port speed (baud rate) and is, therefore, very slow.
Some of the newer 32 bit printer controller boards may have a different mechanism of transferring data to the SD card, but all the 8 bit printer controller boards use the above, slow, method.
There is the possibility of binary file transfer in Marlin, but I don't this the plugin that was made to use it is maintained or fully functional. It was definitely the most promising in getting around the slow upload speeds to SD card, even on 8 bit boards.