Printer Model: ender 3v2
MCU / Printerboard: btt mini e3 v3
Host / SBC btt pi v 1.2
klippy.log
Hi so back in the forums after months of frustrations trying to figure out whats up.
So for awhile with the only machine i have now running klipper it seems every 3 to 4 weeks i have to reflash klipper as it seems to be the only way to fix issues.
Issues being:
Erratic bed probing, which leads into poor first layers then in to bad prints… each time things go bad i blame hardware etc, so i rush out and purchase new items… this time however after replacing the probe ( btt micro probe) 3 separate new ones along with new wiring, new nozzles the list goes on, but nothing worked so i pit all the old parts back on and went back to the usual and reflashed klipper, and wham what do you know printer went back to operating like nothing happened.
So my question is why is it that a constant reflash is being needed? Is there an issue with the sofware in general? Because with my basic knowledge if i was doing someting incorrect within the configs, even with a reflash i would experience the same issues but instead like noted it operates fine.
I would like to have this machine operate like my others that dont require much other then your typical maintenance, well and the difference being they are marlin or bambu based.
Any help would be appreciated
I’m not really sure what you are reporting here and if it is a real problem report or a general rant.
An Ender and your described hardware are standard, and probably thousands (if not tens of thousands) of such machines are running fine on Klipper.
Reflashing Klipper is typically not needed and only in very rare cases does it change anything. If “reflashing” Klipper was a cure of any sort, it would assume that flashed firmware is subject to some sort of aging or degeneration, which is not the case. At least not for hardware that is working within its expected functionality.
Without a precise issue description and respective logs showing this behavior, any further discussion is moot.
You are usually the first to respond Sineos, and i really appreciate your constant help.
I am glad to report the issue was found, and sadly i think this machine just has gremlins and wants to be a constant thorn in my butt, Turns out it was a single screw on my direct drive attching it to the linear rail, somehow this one screw/bolt was the cause of these issues this go around and not the software.
as i can agree with this, it is also known that there are thousands with issues.
again yes I agree but why in my case would it fix things on said occasions, Given that I have followed flashing instructions found on klipper documentation.
You asked for precise issues, which i covered in my original post… being erractic probe probing which leads into poor first layers and bed adhesion.
No for food for thought I have swapped that printer back to marlin, in 8 prints so far bed probing has not acted erractic, first layers are perfect… But even though i found said bolt was loose bed probing was still very off, first layers were beyond unusable, this was prior to switching back to marlin when i gave up. I have attached logs for your pleasure of disecting it and figuring out what may be the issues, like you said it is moot to carry any further discussion without, but wouldnt it be moot to assume the software is perfect without issues? every printer is unique in it s own way, which is covered in klipper documentation. klippy.log (6.0 MB) config-20250118-213634.zip (3.2 KB)
thanks again for your help
The majority of Klipper’s logic and functionality is in the host process, including the homing and probing logic.
If reflashing the board changes something (although I’m not sure what it should change for this kind of issue), it points to a fundamental problem with the board. Your log, however, gives no indication of this.
Reflashing might help if there is some erratic behavior due to a corrupted flashing attempt, but once flashed correctly, it will stop. Of course, this is under the assumption that the hardware is working properly and the firmware has been built correctly.
My personal advice and point of view: Only use the word “bug” or “software issue” if:
You have solid proof of one.
You are a well-known power user or even a coder.
In all other cases, it is prudent to ask where this or that unexpected behavior might come from.
Just for context: In about 6,000 individual topics here, maybe 30 (already optimistic) have been a bug.
Not following the instructions given when opening a new topic, particularly the klippy.log, is already a good start for a less enthusiastic answer, especially if someone very well knows the drill.