i have a fairly simple question. how does octoprint handle the gcode files? does it read the file and sends one command at a time or does it send the whole file in one go?
from what i have been reading it is the first one.
and if it is the first one, on the installation it has been stated that there can be printing artefacts on some of the slower rpi's? how does this happen? is it because the pi cannot keep up with the printer?
does it read the file and sends one command at a time or does it send the whole file in one go?
OctoPrint can do both, but the former way is the most common and the most supported.
how does this happen?
This happens because the protocol between the printer and the host (OctoPrint in this case) is very inefficient, and the printer often has a resource-limited microcontroller.
The communication between the printer and OctoPrint is serial with a fixed baud rate. If the gcode file has lots of very small extrude commands (G0 / G1) then they can be completed by the printer faster than the serial connection can transfer them resulting in pauses in nozzle movement which can cause blobs and artifacts. Slower RPi models may also have trouble keeping the serial interface busy with the same results.
One source of very small extrude commands are curves on the object being printed. Ideally, your slicer would generate gcode with G2 / G3 commands but very few slicers are capable of this.
However, if your printer firmware (Marlin) supports G2 / G3 commands, then the Arc Welder plugin may help.
1 Like
Thank you for the information, this now makes sense.
Thank you for the information, but another quick question, is some of the features limited if you where to send the whole gcode file? For example I Don't think octolapse would work.
Correct. Any plugin that relies on sending the gcode line by line does not work if you first send the whole file to the printer internal storage and print from there. And by and large, that is most of them.
That’s very interesting, may I add another question. Because of the serial, line by line feed from octoprint to the printer, I guess some features like power panic, filament sensor signal or crash detection by the printer wouldn’t work, right? And if so, would they work if the file was transferred completely first? And if so, how can I change the communication mode? Or is the latter the download to the printers SD card?
Thanks in advance
Print on!
Why do you think these features would not work because of the line by line serial feed?
There is really only one data mode with OctoPrint and that is the transfer of GCode data line by line over a serial connection. The normal use of that data is to drive the stepper motors, heaters, etc. that make the printer print.
As an option, you can tell OctoPrint to redirect that serial stream to the printer's SD card but in most cases this is slower than sneaker-net, i.e. moving the SD card to your desktop, writing the file on it, and moving it back to the printer.
OctoPrint can also start printing a file from the printer's SD card and monitor the state of the printer to a certian degree, but most people don't use it this way.
Hi, b-morgan! Thanks for your reply.
I did have a issue, where the filament run out on my Prusa Mk3s, but the print (with Octoprint, of course) didn't stop. So i thought it's because Octoprint didn't stop sending printing commands to my printer, as it didn't recognize the output from the sensor. You asking makes me think if it might be that the sensor didn't work correct, as i sometimes have issues with it... Furthermore i saw plugins for Octoprint to make a filament runout sensor work, so i guessed i need such a plugin for the whole shebang to work. Am i wrong?
What you need to do is create a small test, a cube or something, enable OctoPrint's serial.log (<- link to instructions), and then print the file. While printing, cut the filament just before the sensor and then let things happen. When the smoke clears (JK), upload the serial log file here (add octoprint.log just for completeness) and then we can decide if you need a plugin and if so, which one (or a new one).
Hi, I'm joining this conversation because Steve and Uwe have already asked some of the questions I had, and those have been kindly replied by fieldOfView and b-morgan 
I'm just in the investigation phase, and would like to add some questions for starters:
-
Regarding the filament runout sensors (and other issues that can stop the printing process) does octoprint have a 2-way communication with the printer in order to get notified of this events? Or does it just sends the gcode blindly without ever knowing what's happening?
-
I've already a rpi 4b on use with OpenMediaVault on it (plus transmission, radarr, sonarr, plex, docker, etc). I doesn't have intense usage and I could be careful to not print anything while I'm watching a movie), but the question is, can I install octopi as an application/service/daemon instead of running it as a whole OS? Also, is there a Docker version and do you recommend it instead of a running service?
-
Does octopi have a way of receiving commands trough any of the i/o pins of the board?
That's all (for now 
), thank you in advance!
Needs 'host action commands', but they must be enabled in the firmware build and most printer vendors do not.
Generally we don't recommend using OctoPrint alongside stuff like that, because you say you wouldn't use both at the same time but then there'll inevitably be a time when you want to do both. Prints take a long time. There is a docker version, but it is not the default way to run OctoPrint so it's not as easy as other things designed for docker. There is an official container distribution though. (octoprint/octoprint)
Add plugins and yes. There's 320+ plugins you can choose from and there's a number that let you add buttons to control stuff.
1 Like
@Charlie_Powell I understand the recommendation of NOT using OpenMediaVault and OctoPrint on one Raspberry Pi 4 since high load by other software may corrupt the print process. Still, my Pi 4 is idling most of the time (with at most 4 ftp uploads occurring at any given moment), so I would like to risk this anyway.
It is technically possible to install both programs at the same time without them interfering with each other with the exception of high load? E.g. no conflicts with regard to: - TCP or UDP ports, - applications (e.g. web servers), - Python installations, - you name it?
3D prints can often take hours (or even days) to complete. The printing process is very close to real-time and it doesn't take much to create an artifact on the print surface or at some critical times, a complete print failure. Raspberry Pi OS is not a real-time operating system but a Raspberry Pi running just OctoPrint (with a camera) acts close enough to real-time that it can be successful.
I recommend going to https://rpilocator.com/ and find yourself a Raspberry Pi Zero 2 W. For around $25 you can have an OctoPrint host that can be dedicated to 3D printing.
Is it technically possible to run multiple programs at the same time? Yes.
Will they interfere with each other? Possibly. If each program can tolerate the interference, then all is well. OctoPrint isn't very tolerant.
As for conflicts with ports, etc. those can be managed as the defaults can be changed in most applications including OctoPrint.
I can't guarantee it will work, but technically it should. Port conflicts can always be resolved - OctoPrint looks for port 5000 by default, but this is definitely configurable. I've not used OMV to know what it does or how easy it might be to mess stuff up.