I tried to print different models over Octoprint and the printer starts stuttering, but only if there are very small movements like circles.
Just want to add I am an electronic engineer (so technical terms and discussions are appreciated) and tried a lot of different things to get it to work (f.e. safe mode - unfortunatly I lost the log file of that print)
...the only thing i can think of now is that the buffer of the actual motherboard can not handle the data stream from the usb connection (or it can not handle answering every single command) - would be great to know if this could be an issue and if not if there is any solution to fix that problem.
Sometimes the print even stops for around one second for no reason.
What did you already try to solve it?
Read different forum posts and checked the power supply (is working fine...5V-3A).
Newly installed Octopi and Octoprint (formated SD Card for it).
Tried safe mode and differnt prints and different slicers (seems slightly effected by slicers but not much).
Tried as well to slow down the print, did work to a certain extend but did not totally remove the problem.
Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)
GCode File of the latest prints: gcode will follow
Log File: octoprint.log (112.5 KB)
Serial File: serial.log (2.7 MB)
(Serial was not running all the time but when it was running it stuttered as well)
Pictures of the print, straight lines look good and than the circles look awfull...
Pictures will follow as well
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)
My Printer is and Ender 5 (with Marlin 1.1.0) which worked fine for 3 months and only has problems with octoprint. On the printer every electronics are stock, just added TL Smoothers for X and Y axis.
Having worked during the last days to fix the same issue: try to print from your printers sd card, it will likely work smoothly.
Furthermore you can try to increase buffering in your printers firmware.
For me the easiest approach was to connect my printers uart directly to the raspberry pi uart (gpio 14/15). This reduces latencies involved in uart communication.
I had to modify my marlins configuration*.h files for skr mini e3 a lot to have a second uart on the exp1 header available.
The issue is the communication scheme of Marlin. A different implementation on host side would be possible, e.g. Repetier gets a priori information of the printers buffer size to commit multiple g code lines in an asynchronous manner. Marlin has also a new scheme natively implemented informing the host about the printers free buffer size (advance_ok),but the error handling on the host side gets a lot more difficult, among other implementation problems. Somebody from the forum here has made an implementation of that one for Octoprint, but there seem to be some limitations, blocking the integration to Octopi.
As shortcut: if possible, try to find uart direct access of your printers board and hookup the PI there - using pin 8 and pin 10 of the 40 pin header + a solid common ground connection netween PI and your printer board (important, I killed a PI due to ground potential differences, while plugging the uarts together, when both biards were powered). You need to enable the uart first on your pi, but there are a lot of details available on the web.
Thanks a lot for the detailed infos. I have read that the buffer size can be increased but I wanted to look of there is a "vanilla" solution to this problem.
Update:
I increased the baudrate (according to the board specs it should support 250000 so I set it to 250000. It is a 16Mhz controller so it apparently works (my standard resolution is 0.2mm and most likely a higher resolution causes more data and therefore more lag...) at least for my configuration.
But thanks for the detailed answer, if I ever run again into this sort of problem it is worth considering using direct uart.
Thanks and cheers,
Elias
This is a solution for this problem as well but it maybe requires a specific setup so I do not mark it as solution.
I have been experiencing the same, this model really highlighted the issue for me, lots of curves, small movements and more commands being transacted.
I have a newer higher performing Pi but I have found if I pop the same GCODE on the SD Card and print directly without OctoPrint it prints beautifully, no stuttering and no zits as a result. It saddens me because I love OctoPrint. I'm going to look at alternative connections in order to reduce lag and speed things up.
I did pretty big tuning of the firmware together with increasing baud rate on my stock Ender 3 to 250000 and that helped really substantially, but on some high polygon circles it was still stuttering a bit.
The question is, how it will affect prints with tight tolerances...
Not much at all. I've been printing some snap fits and other low tolerance parts, and it works just fine. Make sure your slicer isn't reducing the resolution artificially, and if you need accuracy greater than +- 0.025mm (resolution=0.05mm) that you change the resolution in ArcWelder, though that should be extremely rare.
