Prusa-firmware: FW 3.8 Calibration broken

[HannahKiekens]

After upgrading to 3.8 none of the calibration menu items worked
Running the full calibration wizard failed on the X axis length check

Downgrading to 3.7.3 fixed all issues, my printer finished the calibration wizard without issues

[leptun]

I am assuming that you are using a MK3(S) because you mentioned the axis length measurement. Can you please be a bit more specific about “none of the calibration menu items work”? A video would be helpful. Also please connect with pronterface or octoprint (or anything else that allows you to see the serial stream, even arduino ide works) and connect over usb to the printer, start the selftest and report what the printer says on error in the log.

[dminuoso]

I have the same exact problem with an Mk3s, but it appears to be limited to the actual selftest.

When I run a selftest on an already calibrated printer, it completes the fan tests and on the X-axis test it starts to move the Z-axis a few centimeters to the top and then instantly aborts without ever moving the Y-axis.

This bug started appearing since 3.8.

The only fix to run a selftest is to do a factory reset, after which the selftest completes just fine.

This is the serial output:

Send: M105
Recv: ok T:21.1 /0.0 B:19.6 /0.0 T0:21.1 /0.0 @:0 B@:0 P:19.9 A:23.2
Recv: echo:busy: processing
Send: M105
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: Test 1:
Recv: Print fan speed: 0
Recv: Extr fan speed: 40
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: MMU not responding - DISABLED
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: Test 2:
Recv: Print fan speed: 79
Recv: Extr fan speed: 0
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x00
Recv: tmc2130_home_enter(axes_mask=0x04)
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x04
Recv: X AXIS SG1=0
Recv: Measured axis length:0.020
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
Recv: echo:busy: processing
....

[dminuoso]

The issue remains with 3.8.1, flashing back to 3.7.2 fixes the issue. This is some regression between 3.7.2 and 3.8.0.

[HannahKiekens]

Yes this is about a mk3s.
I first noticed the issue when i needed to redo the Z calibration. Printer works perfect on 3.7.x

[leptun]

What was the version the printer came with? I’m wondering since I want to reproduce the issue exactly. I’ll try to reproduce it with calibrated mk3s 3.7.2 updated to 3.8.0. Hopefully I can reproduce the issue. Out of curiosity, was the printer in stealth mode. Maybe that’s why it fails measuring the axis length. It should switch automatically, but maybe it didn’t. I’m just trying to rule out possibilities.

[HannahKiekens]

The printer came with 3.7.1 originaly. It was always updated when it asked for new firmware. I upgraded to 3.8 and changed the nozzle at the same time
It was indeed in stealthmode when I changed the nozzle. It kept failing to detect z home and failed the z calibration after that

[leptun]

How did the Z homing failure manifest? Did it trigger initially and then raise a bit instead of probing a second time?

[leptun]

This appears to be an issue from a looong time ago... #776

[dminuoso]

@leptun Im not entirely convinced that this is the same issue, since that issue was on 3.2.1 and the issue did not reproduce on 3.7.2.

I can reproduce this by having a factory reset 3.8.0 printer, calibrate it, power cycle and then run a selftest.

It's a regression at minimum, or a new bug.

[leptun]

This kind of regression shouldn’t happen between versions under normal circumstances. I’m just pointing out the fact that they’re very similar (the issues).

[leptun]

Are you saying 3.7.x is not needed for the bug to appear? Well that is interesting. I’ll look into what changed between 3.7.2 and 3.8.0 so that I can find what changed regarding the selftest.

[leptun]

I’ve also reported the issue further. Hopefully a fix will be available until 3.8.2 release.

[HannahKiekens]

How did the Z homing failure manifest? Did it trigger initially and then raise a bit instead of probing a second time?

I am not certain, I just assumed it was my own fault because I disassembled the hotend for maintenance and a new nozzle.

[leptun]

Ok. So it might be unrelated.

[maurosanjo]

Same issue here with MK3S, I tried to redo Z axis calibration it started moving up and after a few centimeters it stopped without reaching top and went to next step (9 mesurement points).
When trying whole calibration process it fails with same problem as @HannahKiekens

[leptun]

@DRracer I am suspecting that this issue is related to the fact that disable_force_z() sets the motors to silent mode automatically, hence why stallguard triggers instantly. I did not see it also disable Stealth mode somewhere else in the code. Maybe this is what’s been causing issues in 3.8.

Also it’s only been reported to happen on MK3S printers. PSU_DELTA could trigger the issue if that is true.

[leptun]

I looked into the code and it should switch back to normal mode correctly IF YOU ARE in normal mode. I was able to reproduce the problem simply by setting the printer to Stealth mode (very important) and then I reset the printer and start a Z calibration. It detects the Z tops instantly. I'll make the required changes and post a PR addressing the issues.

[DRracer]

@HannahKiekens thanks for reporting
@leptun thanks for tracking down the problem and for your PR, we'll push it into 3.8.1 ASAP