FIRMWARE_NAME:Marlin Ver 1.0.2 SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Ender-3 V2 EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Might be worth trying Marlin 2.x?
I would be willing to bet that this is Creality Marlin version number, not stock marlin version number, and IIRC that is based on 2.0.6 or maybe 2.0.7.
Yeah, I believe @jneilliii is right. I tried installing the latest firmware when I got the printer, but I was having trouble, the printer wouldn't take it. So I ended up going for the last 'verified' version Creality has on their website, which is Marlin-2.0.1 – V1.0.2 in Creality-speak. For my motherboard that is one of the 'latest' Creality firmwares I believe (without BL touch or filament sensors), released on August 14 2020. All later official Creality firmwares for the Ender 2 are also based on Marlin 2.0.1.
I saw you said there where issues with saving esteps. You might be able to add an M92 command to your start code in the slicer if it is trying to save to the sd.
I noticed that even with the "Creality 2x temperature reporting fix", Octoprint still seems to be getting double numbers. From the terminal: "Recv: TT::199.60199.60 //200.00200.00 BB::39.7539.75 //0.000.00 @@::8888 BB@@::00".
I doubt that this is what causes the poor print quality when using octoprint though. But it seems to be yet another bug I run into.
Any suggestions to solve these?
The plugin just takes care that the temp graph is shown correctly
But you can try this as regular expression at
OctoPrint Settings -> Terminal Filters
1 Like
Thx, I'll give that a shot when I reconnect Octoprint to the machine!
Does the printer make a "knock" noise from time to time? Can be related to mainboard overheating if you have the 4.2.2 mainboard.
I solved this by installing a larger fan below the printer and letting it run all the time.
See also Ender V2 Layer Shift Problem Rectified With Cooling | Hackaday
I've not had any 'knock' noises, other than when on some prints the extruder skips a step. Without OctoPrint, running prints from the SD, I don't have any layer shift issues, and even with Octoprint it's not a real layer shift like what you see in that Hackaday link, it's just pour surface texture that seems to be caused by short momentary pauses in printing when running the print through Octoprint.
I tried setting that expression as a filter, and while it does work to have the temperature messages supressed (where the default expression didn't), it doesn't change the actual double output. Am I misunderstanding that thread wrong? I thought it would fix the double temp logging, not just allow for the hiding of the temp log lines in terminal?
This double logging is an issue with the printer firmware and can only be fixed with a new firmware.
1 Like
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!