Homing calibration fails when using a blanket
Yes, this is weirdly titled.
When printing engineering filament that require a warm chamber, I throw a blanket on top of the printer as a type of insulation. It weighs maybe a kg or two. When I do this I've noticed that occasionally printer homing fails and requests calibration. It performs this calibration and then fails. When I remove the blanket it succeeds. I'm wondering if the blanket is dampening the frame and throwing off load cell measurements? Or I'm imagining this and it's just a coincidence.
Of course I've loosened the belts, checked gantry alignment and everything is fine. X and Y calibrations and homing calibration pass. If there is this heavy blanket on top then I start seeing these intermitant/random failures.
RE: Homing calibration fails when using a blanket
The top of my Core One moves by a significant amount. The base is on a solid counter and doesn't move at all. I have to believe the motion was accounted for in the setup, and you should use the accelerometer to redo the numbers if you use a blanket. Probably true for Sorbothane feet as well. This is armchair speculation, as I've yet to even plug in my accelerometer.
RE: Homing calibration fails when using a blanket
The top of my Core One moves by a significant amount. The base is on a solid counter and doesn't move at all. I have to believe the motion was accounted for in the setup, and you should use the accelerometer to redo the numbers if you use a blanket. Probably true for Sorbothane feet as well. This is armchair speculation, as I've yet to even plug in my accelerometer.
The accelerometer is only needed/used for input shaping and motor micro-phase stepping calibration. Not for homing.
RE: Homing calibration fails when using a blanket
I struggle to imagine how mechanical damping of the frame/enclosure would affect the Z homing. We are talking about really slow movement here, just the bed creeping upwards towards the load cell, right?
No, not Z homing. The headbanging it does when homing in X and Y
RE: Homing calibration fails when using a blanket
No, not Z homing. The headbanging it does when homing in X and Y
Ah, ok, Then your reference to the load cell was a bit of a red herring. A damping effect on the head banging (which detects motor stall currents and has nothing to do with the load cell to my knowledge) is slightly more conceivable, but would still be surprising.
RE: Homing calibration fails when using a blanket
No, not Z homing. The headbanging it does when homing in X and Y
Ah, ok, Then your reference to the load cell was a bit of a red herring. A damping effect on the head banging (which detects motor stall currents and has nothing to do with the load cell to my knowledge) is slightly more conceivable, but would still be surprising.
Not being a trained engineer, I'm just speculating. Anyway, it happens more often (vs not at all) with a heavy blanket on top. Interesting observation but only a minor annoyance.
RE: Homing calibration fails when using a blanket
OK, makes sense. Q- do we actually know just how homing works? It's amazing to me that motor current could be detected as fast as the "gentle bumps" occur. Pulses from the strain gauge seem just as likely in one plane, but less so in the other. I assume the source code isn't open.
RE: Homing calibration fails when using a blanket
OK, makes sense. Q- do we actually know just how homing works? It's amazing to me that motor current could be detected as fast as the "gentle bumps" occur. Pulses from the strain gauge seem just as likely in one plane, but less so in the other. I assume the source code isn't open.
It's open source. You can find it here: https://github.com/prusa3d/Prusa-Firmware-Buddy
Maybe later I'll have Claude AI summarize it for me. I code 9hrs/5days/week so on my off-time I don't want to look at code.
RE:
OK, makes sense. Q- do we actually know just how homing works? It's amazing to me that motor current could be detected as fast as the "gentle bumps" occur. Pulses from the strain gauge seem just as likely in one plane, but less so in the other. I assume the source code isn't open.
The Trinamic motor control chips have a dedicated hardware function for that, branded "StallGuard". It must be integrated directly with the chopper-based current control that drives the micro-stepping. The firmware is all open source, https://github.com/prusa3d/Prusa-Firmware-Buddy. But it's not trivial at all to get your bearings...
Edit: Aha, hyiger beat me to it...
RE: Homing calibration fails when using a blanket
I don't think it's the weight alone. I often have 20 kg of floor tiles piled on top of the printer, it makes no difference to homing.
But I use the original (hard) rubber feet. Is there a chance one of the legs is floating, the weight isn't evenly distributed? If the printer shell warps - and it doesn't seem that stiff, at least without solid support from below - homing failure wouldn't surprise.
RE: Homing calibration fails when using a blanket
I don't think it's the weight alone. I often have 20 kg of floor tiles piled on top of the printer, it makes no difference to homing.
But I use the original (hard) rubber feet. Is there a chance one of the legs is floating, the weight isn't evenly distributed? If the printer shell warps - and it doesn't seem that stiff, at least without solid support from below - homing failure wouldn't surprise.
I'm using PEBA feet on a very rigid 40kg shop table. There is no wobble. I've only seen this occur 3 times and all 3 occasions there was a blanket on top. It's probably just a coincidence. However I'm curious.
RE: Homing calibration fails when using a blanket
Not sure if this would help, but if you can't figure out the blanket mystery, you could make a removable "box" out of some 1" polystyrene sheets. Will insulate better than a blanket and would put the weight on the surface, not the C1 itself - and you could lift it on or off easily?
I don't think it's the weight alone. I often have 20 kg of floor tiles piled on top of the printer, it makes no difference to homing.
But I use the original (hard) rubber feet. Is there a chance one of the legs is floating, the weight isn't evenly distributed? If the printer shell warps - and it doesn't seem that stiff, at least without solid support from below - homing failure wouldn't surprise.
I'm using PEBA feet on a very rigid 40kg shop table. There is no wobble. I've only seen this occur 3 times and all 3 occasions there was a blanket on top. It's probably just a coincidence. However I'm curious.
RE:
It happened again with the blanket off. So much for that theory. To be honest it was a stupid theory but the my brain is always mixing up causation and correlation. My initial thought was: "Never saw this until I threw a blanket on top" == "Must be the blanket" but then I forgot Occam's Razor.
I did tighten the belts, they were loose but not obscenely loose (in the mid 80's). I manually ran the homing calibration and it consistently passed. So... IDK...
RE: Homing calibration fails when using a blanket
I had Claude AI chomp on the Prusa-Firmware-Buddy repo and asked: "I want to know how the Core One X and Y homing calibration works"
Stage 1: Initial Rough Home
G28 first does a conventional homeaxis(Y_AXIS) then homeaxis(X_AXIS) — both use TMC stallguard (sensorless homing), driving each motor until stall is detected. This gives an approximate position only, because:
In CoreXY, the A and B motor step positions don't directly map to clean X/Y coordinates.Stallguard detection can vary by a microstep or two depending on motor phase.
Stage 2: Phase Alignment
After the rough home, corexy_rehome_and_phase() (homing_corexy.cpp:653) moves both motors to a precise phase boundary:
Backs off to XY_HOMING_ORIGIN_OFFSET from the corner.Calls phase_backoff_steps() — calculates how many steps to nudge each motor to land on the nearest full TMC microstep phase boundary.
This is critical: stallguard readings are most consistent when the rotor is at a known phase. Without this, repeat homing would be noisy.
Stage 3: Precise Refinement / Calibration
corexy_home_refine() (homing_corexy.cpp:888) checks whether a calibration exists in the config store:
If calibrated: validates the current position against the stored origin grid.If not calibrated (or forced): runs measure_origin_multipoint().The 9-point grid sweep
measure_origin_multipoint() (homing_corexy.cpp:500) probes a 3×3 grid in A/B motor phase space around the home corner:
(1,0), (-1,0), (0,1), (0,-1), (-1,-1), (1,1), (1,-1), (-1,1), (0,0)
At each grid point it calls measure_phase_cycles(), which:
Drives toward the endstop (stallguard fires on stall).Measures the step distance to the endstop.Repeats in both approach directions and averages the two readings.Validates consistency — retries if the two measurements differ by more than XY_HOMING_ORIGIN_BUMP_MAX_ERR.
This gives a map of how far the endstop is from each grid position in AB space, pinning down the true home corner.
Stability filter
Grid points that fall within ±¼ of a phase unit from the grid midpoint are flagged as unstable (small position errors could flip which grid cell you're in). These are tracked in a rotating 16-bit history bitmask stored in the config store. If ≥6 of the last 10 refinements are unstable, automatic recalibration is triggered.
RE: Homing calibration fails when using a blanket
Thanks, that's more or less understandable, whereas looking at the code (for me), it would probably look like Klingon.
RE: Homing calibration fails when using a blanket
I’d say that the never ending joys of owning a Prusa printer can’t compare to anything else. 😋
Guys don’t forget that Prague is the hometown of Franz Kakfka. Odd things just happen with Prusa printers but don’t expect logical explanations. You have to lìve with that or else get a boring Bambulabs machine. 🙄