What is the problem?
Ever since using Octoprint to monitor and print on my Ender 3 V2, surface quality of my prints has gone down noticeably.
What did you already try to solve it?
Sadly I changed a lot of variables at the same time, but I've currently ruled out the others and pinned it down on Octoprint:
- I installed an all metal extruder, Capricorn Bowden tube, new nozzle and Octoprint (via Raspberry Pi4 4GB). Up until then, my Ender 3 V2 ran mostly stock, and had good quality prints.
- After the upgrade, my first regular print looked worse than usual (see picture of treetrunks below). So I printed a Benchy, and that too looked much worse. So I started troubleshooting.
- I've run esteps calibration, temperature calibration, retraction calibration, levelling the bed, ... several times. I've taken out the Capricorn tube and reinstalled the old one. I've replaced the metal extruder with the old plastic extruder. I've changed the nozzle again. (Running esteps calibration after every change). Currently it is running with the stock plastic extruder, and the only difference with the stock machine is a Capricorn tube and a new nozzle (in the same 0.4mm diameter).
- At that point I realised I had not ruled out one other variable: Octoprint. So I unplugged the RP4 and printed the gcode I used before for a Benchy, without reslicing it. Came out looking as it did before all the changes.
So it's the RPi4/Octoprint. I've read here and there online that people had issues, and that it is likely due to the buffer being full when printing lots of short segments (like the curved bow of a benchy...). I've equally read that those are ghost stories. But in that case I can tell you I've been seeing a ghost for the past 2 days. One that's driven me up the walls...
Question is: what is the best current solution to this? I've seen some suggestions spread around the internet, but those were often for older firmwares/older Octoprint versions/older RP versions, and not always as clear as I'd like as a newbie to FDM-printing. I'd really like to use Octoprint (on the RP4, I don't have other spare hardware laying around), for its monitoring, logging and spool management features.
Systeminfo Bundle
octoprint-systeminfo-20210503224130.zip (308.4 KB)
Additional information about your setup
Running Octoprint 1.6.0 on a Raspberry Pi 4 - 4GB. Ender 3 V2 is running Creality firmware v1.0.2. Octoprint has a webcam connected to it, and I've installed several plugins (mostly for logging/gui changes). The RP4 also controls two LED's on the frame of my Ender to provide light when I'm inspecting it through the webcam when it's dark. I'm not using any timelapses. Prints are just uploaded directly from Creality Slicer, or by dragging/dropping the gcode in Octoprint. I'm not running any specific (custom) code during the print, at least none that I introduced (not sure if plugins can do that).
Pictures (left = good, without Octoprint, right = bad, with Octoprint)
(I had more pictures but as a new user I'm limited)
If you're using an sd card in your printer - try it without one and vise versa.
There is a weird sd card related usb bug on some creality 32bit boards.
If that doesn't help enable serial logging, start a new print until you see some artifacts, stop the print and upload the serial.log or a new Systeminfo Bundle.
That should help us figure out what is causing your problems 
@Errandir I see you have PSUControl-TPLink installed. Looking at the logs it's spewing tons of errors and it appears that it's been mis-configured. Did you test to make sure it works?
2021-05-01 21:58:38,879 - octoprint.plugins.psucontrol_tplink - ERROR - Expecting get_sysinfo, got result={}
2021-05-01 21:58:43,897 - octoprint.plugins.psucontrol_tplink - ERROR - Unable to resolve hostname 1C-3B-F3-8D-14-02
I can run a test without again, although I believe my initial tests were without an SD card, and the latest with (without seeing much difference between them). Ever since I had to recalibrate the esteps, I needed an SD, because without it the terminal kept giving me errors when I tried saving the new esteps (it required Eeprom, which it saves on the SD).
Safest might be to run a test and stop it once I see the issues pop up and share a log, I'll do so tomorrow!
Yes, PSU Control and the TPLink plugin for it were installed, but have been disabled on my last several (bad) prints. I hadn't been able to properly configure it, since I lacked the appropriate TPLink power plug (I have a Tapo P200, while a Kasa-compatible one seems to be needed - it's on its way). I noticed it was spewing errors when they were enabled, so I disabled them before running the last... 3 prints I think.
Where you saw it in the logs, was that from more than a day ago? If so, that makes sense. During all tests from today it should have been disabled normally.
Ah okay. Just making sure
So have you tried printing in Safe Mode? It's always worth running against core to rule out any plugins.
What kind of webcam are you using? Is it in a USB2.0 or 3.0 port?
Is the printer plugged into USB 2.0 or 3.0?
1 Like
Both the Ender and the webcam are plugged into the USB 3 ports of the RP4.
I just ran another test print in safe mode, but that gave me the same result (stopped it early):
@PrintedWeezl After that failed print in Safe Mode, I downloaded the serial.log. I also made a new Systeminfo Bundle, but only after having rebooted Octoprint to regular mode. Here they are:
serial.log (148 Bytes)
octoprint-systeminfo-20210504084841.zip (325.7 KB)
I just noticed that.... the serial log is empty 
Apparently it's not activated. I'll see if I can activate it and print again (this time in regular mode).
UPDATE: here's the serial log after the latest failed print (in regular mode). I stopped it midway, about as far as the picture above is showing. Results were the same, the same kind of bad surface texture. I instantly downloaded the Systeminfo Bundle after stopping the print, including the serial.log, which this time is populated:
octoprint-systeminfo-20210504105407.zip (1023.8 KB)
During this last print the webcam was disconnected, but as you can see that made no difference in quality.
One thing that I forgot to mention is that I'm also hearing new 'noises' during the print, that I don't recall hearing when printing without Octoprint. Very often I seem to hear what are bubbles, bursting when extruding the filament (a small high frequency 'pop'). I'm certain it's not the filament, I've tried several, with the same noise, and I don't hear it when printing regularly with those same filaments. I presume it's when the printer is stopped for a split second (which also causes those blobs), and the hot filament oozes out in a different way than when being extruded, and it basically makes it blow a bubble.
@PrintedWeezl I've had a look at the serial.log and the octoprint.log myself. There's a lot of GCode being sent every few milliseconds, but they seem to be regular extrusion commands (I'm not the most experienced yet in reading GCode though). So I'm not sure what is causing the printer to be slowed down, resulting in that bad surface finish. What exactly should I be looking for in the logs?
I've done a few more 'regular' prints these past days, without the RP4 connected, and they continue to print normally with the expected good surface finish. I do still hear the little 'bubble blowing' sounds once in a while, must be something with my retraction settings (filament is kept dry, only 2 weeks old, humidity in the house overall is below 40% too currently, so I highly doubt it's humidity related).
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
