OctoPrint
OctoPrint copied to clipboard
OctoPrint
Slow print speed with stuttering, random pauses (v1.5.2)
What were you doing?
Something really bad happens on latest Octoprint versions. I guess it started from 1.5.x. My prints take x2/x3 times longer than via sd card or via Octoprint v1.3.12 (which i currently use)
The printer head stutters and sometimes totally stops. I didn't notice any suspect things in the logs though. Tried 1.5.2 in safe mode with no any positive improvements.
Also tried several different usb cables.
I'm on Orange Pi Zero. First i thought my hardware is dying. I swapped sd card with no positive result. Then i found my old backup dump (v1.3.12). I gave it a chance and voila! It works like a charm with appropriate speed and no blobs and pauses.
What did you expect to happen?
Should print not slower than 15% from what sd card print gives. (My expirience from v1.3.12)
What happened instead?
It prints 2-3 times slower. Especially when model have lot of curves. Of course my prints were full of blobs due to constant stuttering.
Did the same happen when running OctoPrint in safe mode?
YES
Version of OctoPrint
1.5.2
Operating System running OctoPrint
Armbian on the Orange Pi Zero
Printer model & used firmware incl. version
Ender 3 Pro
Browser and version of browser, operating system running browser
Firefox on Win10
Link to octoprint.log
https://pastebin.com/HAKbdFkN
Link to contents of terminal tab or serial.log
https://pastebin.com/dgVA0180
I have read the FAQ.
I have the same issue, Octoprint running on Armbian, Banana Pi M2U. I tried in safe mode, reinstalled octoprint, without any plugins or only with OctoKlipper. Still always to CPU cores are at 100% and printing is so slow, it is not usable. It was fine last weekend. Not sure what changed since then.
edit: I downgraded with pip to 1.4.2 and the CPU usage is back to normal. Please let me know if i can do something to find the cause of the issue.
mine CPU load is within appropriate values though (5-10%). i suspect something wrong with serial port api
Having the same issue. Small prints, especially ones that have tight circular motions are jerky and jittery. When i print from the SD card, the printing is fairly smooth (a lot smoother than octoprint). On Anycubic Mega S, Marlin 2.0, Standard drivers, USB Baud at 250000.
@3dRikal Please confirm as the previous commenters have that this issue only impacts OctoPrint 1.5.x. This is not going to be yet another thread about stuttering printing via USB, those can be found here, here and all over the forums. If the stuttering goes away with OctoPrint 1.4.2 then come back here but if it remains the same then this is not the same issue.
I am new to octoprint and the only version I have used is 1.5.2. I was not in the loop for 1.4.x sorry. I will update to 1.5.3 today and am still conducting tests to eliminate some culprits. I am trying to determine if serial buffer from FW is at fault or usb cable is defective but so far, only prints from octoprint are failing (and only on tight circular prints)
As mentionned, via sd card, the same gcode prints fine.
Tested with 1.4.2 and jitter is reduced to almost nothing compared to 1.5.2.
In that case, test in safe mode, and if the issue persists please also fill out the ticket template.
edit that is for both @3dRikal & @gzahl
@deviant-studio that does not look like a full serial.log in your post.
For reference, the only thing change about the comm layer that I could see causing a bit more computational overhead is counting of resend requests vs total sent lines (see history). The ratio only gets calculated on resend requests however. I cannot reproduce a problem myself here so far, so whatever is happening might be very environment specific.
yes, the serial.log became really big, so my browser crashes when i copy/paste it into pastebin 🤷♂️ but nothing interesting there anyway. just repeating Recv: ok lines. no errors/warnings. is there any way to stress test the serial connection? maybe some integration test that benchmarks the throughput? also is it hard to build octoprint from the sources? i could check different branches and confirm if it's really due to last commits or some other (hardware specific) issue.
i'll have to revisit this over the weekend. Got an order I need to push through. SD card will have to work for now.
is there any way to stress test the serial connection? maybe some integration test that benchmarks the throughput?
If you have an SD card in your printer, yes, in a way. You can use src/octoprint/util/comm.py to stream a file to the printer's SD and benchmark the transmission speed. However, that is more for measuring the general throughput capabilities of the general serial implementation, as in SD streaming mode a lot of the plugin hooks and such are bypassed.
Still, if you want to play around with it:
python -m octoprint.util.comm <port> <baudrate> <local path> <remote path>
(in the OctoPrint venv, so on OctoPi that needs to be either ~/oprint/bin/python ... or you need to activate the venv first via source ~/oprint/bin/activate)
also is it hard to build octoprint from the sources? i could check different branches and confirm if it's really due to last commits or some other (hardware specific) issue.
Nope, not at all. There's no actually building involved really, just having a working Python install, checking out the sources, installing the dependencies and done. There's also a script on OctoPi to do all this for easy experimenting, see the README in ~/OctoPrint.
i made some additional research and wanted to add more details: i tried to upgrade 1.3.12 -> 1.5.2 (with web interface update) to see what happens. and again i got jerks. then i tried to downgrade to 1.4.2 with pip install = jerks then downgrade to 1.3.12 = jerks. so probably not an octoprint issue but some dependency that installs together with 1.5.x
also i tried the arc welder plugin. it helps to get rid of jerks, but random pauses still occur. so i'm going back to sd card printing at least until i get some more powerful hardware.
I have the same problem with an OrangePiZero and this apears after install Octoprint 1.5. It is visible when i make a refresh in chrome tab.... i have to go and print safe from sdcard ;(
Well i have updated the orangepi zero for Next (Armbian 21.02.2 Buster with Linux 5.10.16-sunxi) and change the cpu from ondemand to performance.
Also i have reinstall Octoprint now running with python3 and the problems off randam pauses disapear.
Does this still persist in 1.6.1? I have just made my first install with a RPi 3B+ and have issues. But I've not jet nailed it down, since I also used arc welder for the first time. There is a lot of stuttering in detailed areas. I'm printing with an Anycubis I3 Mega S.
I've also noticed this issue recently, jumped straight from an older release (probably skipped 1.5 entirely) and am now on 1.6.1
Lots of issues with short quick moves, can see the printer buffer down to single commands.
Nothing else about the setup has changed, though prints are obviously suffering artefacts & taking absolutely forever to complete.
Printer is a Wanhao i3 2.1 rebrand
From System Info: env.plugins.pi_support.model: Raspberry Pi 3 Model B Plus Rev 1.3 env.plugins.pi_support.octopi_version: 0.15.0 env.plugins.pi_support.throttle_state: 0x50005 env.python.pip: 10.0.1 env.python.version: 2.7.13 env.python.virtualenv: true octoprint.safe_mode: false octoprint.version: 1.6.1
env.plugins.pi_support.throttle_state: 0x50005
Fix this first. Your Pi is throttling due to undervoltage issues, it can't get enough power so it's limiting what it will do.
Thanks! Will check it out. Wasn't sure if that had much of an impact on prints - haven't changed a thing as far as powering the Pi in near 2 years without problems like this. Will run through a quick test with a beefier power supply and let you know
Will run through a quick test with a beefier power supply and let you know
@Shambler2 did anything ever come out of this test?
Apologies for the rather ridiculous delay - I've finally resolved the power problem and come back to this issue (to be honest it turned me off using the printer as I just couldn't resolve it at the time)
Unfortunately, its still happening. I've completely re-installed OctoPrint and am now running the latest release, and Python 3. When I did this however I DID export, then re-import my settings.
Happy to do some more troubleshooting on this now if anyone is able to help!
So after a lot of troubleshooting I've finally worked out that the issue was something in my Cura settings when slicing the STL - not sure what setting it was yet but I can see a 1MB file size difference in the gcode for the same object, I suspect I was just throwing too much detail into the file after all.
Heyho,
I have the same issue, so I filled out your form as best as I could.
What were you doing?
regular printing via OctoPrint
What did you expect to happen?
normal printing without stuttering and stops
What happened instead?
stuttering and stops (especially in curves with a lot of position data, see video below)
(Printing from SD-Card works fine)
Did the same happen when running OctoPrint in safe mode?
Yeah
Version of OctoPrint
See System Info Bundle
Printer model & used firmware incl. version
MK3S (FW3.11.0-4955) +MMU2 (FW: 1.0.6-372) (both should be latest at the time of post)
Browser and version of browser, operating system running browser
See System Info Bundle
System Info Bundle
browser.user_agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 connectivity.connection_check: 1.1.1.1:53 connectivity.connection_ok: true connectivity.enabled: true connectivity.online: true connectivity.resolution_check: octoprint.org connectivity.resolution_ok: true env.hardware.cores: 4 env.hardware.freq: 1200 env.hardware.ram: 914006016 env.os.bits: 32 env.os.id: linux env.os.platform: linux env.plugins.pi_support.model: Raspberry Pi 3 Model B Rev 1.2 env.plugins.pi_support.throttle_check_enabled: true env.plugins.pi_support.throttle_check_functional: true env.plugins.pi_support.throttle_state: 0x0 env.python.pip: 22.1.2 env.python.version: 3.7.3 env.python.virtualenv: true octoprint.last_safe_mode.date: unknown octoprint.last_safe_mode.reason: unknown octoprint.safe_mode: false octoprint.version: 1.8.1 printer.firmware: Prusa-Firmware 3.11.0 based on Marlin systeminfo.generated: 2022-07-16T21:42:45Z systeminfo.generator: systemapi
Link to contents of Javascript console in the browser
Screenshot(s)/video(s) showing the problem:
https://user-images.githubusercontent.com/89015665/179373563-f8b221c9-7b49-44ac-9335-5e05de003e96.mp4
Edit: Just saw, that it may corresponds also to https://github.com/OctoPrint/OctoPrint/issues/4376
Edit2: I forgot to mention, that I also thought, my pi or pi-sd is passing away, so I tried to completely install a fresh raspbian and make a clean install, which hasn't solved the problem.
Hope this helps a bit.
Kind regards, Deph
I had at least on outset similar looking situation with stuttering prints and octoprint starting from browser if at all. After much digging, I realized I had two mac addresses on orangepi pc one for eth and one for wifi. I disabled the wifi adapter on orangepi and wired eth to openwrt router. Then removed all dhcp static leases from openwrt that pointed to octoprint, reboot and assigned static dhcp lease to the eth. Finally reset cura octoprint plugin. Another thing that I suspected was unwanted process scheduling set by armbian-config cpu frequency and governor set too high of a setting.
For anyone finding this issue later... Upgrading python from 3.7 to 3.12 seems to help substantially.
It isn't easy to do though - I built 3.12 from source, and then had to mod this script to run python3.12 instead of python3: https://github.com/cp2004/OctoPrint-Upgrade-To-Py3
