I've made some changes to my setup and retested printing a Benchy with Octoprint vs SD-card only. I didn't expect my changes to affect the print quality much, and they haven't. It's still as bad as before, I still can't use Octoprint.
Changes that were made:
- different USB-cable
- blocking off the 5V pin with tape to avoid power issues
- updated Octoprint and all plugins to their latest version (I previously tried printing in safe mode, without success, so it doesn't seem to be any plugin causing the issue)
- no webcam connected (already tried in previous tests)
- changed infill from 15 to 10% (irrelevant to the print but happened by accident)
Here's how the prints looked. Left = without Octoprint, right = with Octoprint. Not the crispest pictures but they get the point across:
I watched the print head as it was printing the hull, and while it's hard to be sure, I had the distinct feeling that without Octoprint the nozzle ran smooth and without any visible changes in speed/acceleration when doing 1 round of the hull, while with Octoprint the movement was a bit more jerky. No large jerks, just changes in acceleration while drawing one layer of the hull, coinciding with the spots where the quality is worse.
The logs from this last Octoprint-print can be found here
octoprint-logs.zip (2.8 MB).
The gcode for the benchy can be found here
CRE3V2-104.zip (1.6 MB)
I'm still at a loss of what causes this issue. Help and suggestions are most welcome.
In an attempt to further test and prevent my issue with poor print quality when using Octoprint, I've tried printing a file sliced with ArcWelder in Cura. Sadly the terminal quite quickly started spewing out 'unknown command' errors.
@FormerLurker Hopefully you don't mind me pinging you, but do you know what could be causing this issue? I was having quality issues when using Octoprint (see above), and from what I could gather, the only thing that might still help is reducing what is sent over the USB serial connection. So I tried to use your ArcWelder, which seemed to be designed to solve this issue.
-
I'm using Creality Slicer, with the ArcWelder plugin by fieldOfView (GitHub - FormerLurker/ArcWelderLib: A collection of projects used to convert G0/G1 commands to G2/G3 commands.)
-
The printer is an Ender 3 V2, running Marlin 2.0.1 (or better said Creality's version of it)
-
The settings I've used in the slicer are the following (all defaults except the bottom one):
I have checked the 'G90 influences extruder' checkbox since it's Marlin 2x
-
The errors look like this:
"2021-06-04 13:55:37,750 - Recv: echo:Unknown command: "G3 X82.180 Y100.759 I5.038 J2.404 E5.31580""
I've added the entire log of the print here:
octoprint-logs.zip (616.4 KB)
-
The print looks like this (benchy, bottom text layer):
Thanks in advance for your help!
If you don't have Arc Support enabled in the firmware, then you can't use arcs.
Ah. Rats, that means I'm all out of luck. I'm normally already running the latest firmware Creality has on their site for the stock Ender 3 V2 (no BLTouch).
As far as I know, Creality does not enable arcs in their builds, so yes no luck there.
You may find that building your own firmware helps, since you can do things like increasing the buffer size (V4 boards have plenty of space) and then you can enable arcs & other cool features that are more useful.
Thanks for the info. I'll have to dig around a bit for that, building my own firmware is out of my current level of knowledge.
I'm not sure what exactly is causing the quality issues; I read that it can be the USB-protocol, or perhaps the buffer size, but I've not been able to determine/know how to definitively determine that. I'm hoping that ArcWelder will solve it for all potential prints (complex or not) by reducing the amount of commands transferred over the USB.
There is an example config that will get you 90% there, with the latest version of Marlin:
Configurations/config/examples/Creality/Ender-3 V2 at release-2.0.8.2 · MarlinFirmware/Configurations (github.com)
That makes it slightly less painful, since you don't have to figure out all the parameters yourself, and can get on with the more interesting bits. Plenty of videos/tutorials about as well that would probably help.
Hey Errandir, this is my first time here! I have an Ender 5 PLUS and started using Octoprint and I'm having the exact same issues in quality that you mentioned. Have you manage to get a solution?
I have an SKR 1.3 and BIQU's TFT 3.0. Running my Octoprint on my Raspberry Pi 4 and using Marlin.
Any help would be great, I also don't know how to correctly edit and compile Marlin firmware.
Thanks in advance!
I recently purchased an Aquila S2 (Ender clone) for its ability to use a larger array of filaments. It has been doing a fantastic job. I hooked it up to a Rasperry Pi Zero 2 W and now I have the same issue as @Errandir . I can confirm that the prints are perfect from an SD card, and bumpy (only on curves) when using Octoprint. I also noticed popping during the prints as the pressure of the filament would build up. I have seen solutions involving modifying marlin firmware. I have also heard that this issue may be related to an underpowered Rasperry Pi. Is there anything that can be done, short of rewriting code in BIN files? I really want to use Octoprint!
I have an Ender 3 Max, and Octoprint running on a Pi 3b, have the same issue, bubbles shows up after a pause ( 1 sec pause ) on my prints, when printing from SDcard, there are no pauses or bubbles.
Hey, someone found the solution for this issue, check this out:
Apologies, didn't notice your message until now. I haven't been able to solve it, I just resorted back to printing from the SD. I am however planning to put the entire printer on Klipper, and run that via an Octoprint interface. That worked well on my E3v2, I'm hoping it will work well on the E5Pro as well. Klipper basically replaces the Marlin Firmware on the printer, so hopefully the buffering issues won't be a problem anymore that way.
1 Like
Hi Dave, sorry for the late reaction. See my reply above to TheGreatKahedin: running Klipper instead of Marlin and controlling that via Octoprint might be a solution. Klipper offers some advantages, like being able to tune linear advance etc. I can recommend it.
1 Like
I put my T-Rex 3 also on Klipper and it runs fine.
So, did anyone find the fix? I'm having the same issue: OG Ender 3, RPi 3B, Creality Slicer. Prints awesome if I use the Ender's onboard SD. Looks diseased if I print from OctoPrint (anything with curves, mind you).
Hello, I had similar issue using Octoprint with my Artillery Genius (8bits motherboard). During print, the extruder was making micro pauses and this generated blobs. To solve this, I had to adjust 2 parameters in my FW. They are situated in Configuration_adv.h and I updated as follow:
BLOCK_BUFFER_SIZE from 16 to 32
TX_BUFFER_SIZE from 0 to 32
You may not need to modify the FW but we won't know for sure unless you take the time to fill out the template that appears when you open a new, Get Help, issue. This topic is over a year old so I strongly suggest that you start a new one.
Of particular interest is the serial Resend ratio. You will have to provide the log files generated from a failing print probably including a serial.log which you should enable before printing the failing part.
@rumancz thanks again for the direction. Getting closer.
@b-morgan makes more sense to leave the problem/solution set here.
I looked at the logs and there were no errors. No weird messages/codes, either, when it would pause (usually lasting anywhere from .5-1.25 seconds).
My primary question, at this point, is why is this issue happening? Changing the buffer sizes, if truly the issue here, after ~3 years of a known issue, should have made it into the 2.0.x version of Marlin, should it not?
Anyways, learning my way around VS so I can change Configuration.h and Configuration_adv.h as needed. Will update this message after uploading the recompiled code.
But first, printing a slightly diseased Dalek after upgrading the board to 4.2.7. 
Well that was just a HOOT!
VS/Platformio was actually easier than I thought it would be. Got a single compile error because the .pio folder gets created AFTER the first attempt to compile. That was fun. After that it was smooth sailing.
Reprinting a round-ish part to see if the new buffer sizes cure my ails.
