[RRF3.3b2] Possibly incorrect behavior when homing Z
-
@pkos Ok, I can reproduce this here on my VORON Zero if I replace the Z endstop with a Z probe connected to the same spot (so I can use
G30 Z-99999
in my homing sequence instead ofG1 H1 Z-125
).When using a single probing speed, Z=0 is established on the first probe, so the move to the dive height is small.
When using dual probing speeds, Z=0 is not established until after the second probe, so the move to the dive height is "power up position + dive height".
-
@pkos said in [RRF3.3b2] Possibly incorrect behavior when homing Z:
Just to be clear.
You take the gantry to 100.
You turn the printer off completely.
You turn the printer on and Home z - and then it also just raises a tiny bit even though the first probe needed a drop fo 100?The switched off printer is the key here. If it's already homed, the problem does not exist.
You could be right. I didn't turn the printer off.
-
@phaedrux Just checking in - is this possibly something that can be checked seeing as how others are now confirming the issue?
-
Yes I've asked @DC42 to comment when he gets a chance.
-
@phaedrux FYI - checked with 3.3b3 - behavior still there.
-
I can verify this behavior as well
Duet2 Wifi +Duex5
Duet Web Control 3.3.0-b3
RepRapFirmware for Duet 2 WiFi/Ethernet 3.3beta3 (2021-04-22) -
I've tried and failed to reproduce this behaviour. However, I have found a bug:
- If I set M558 F1000:300 A1 (or I don't specify the A parameter in the original M558 command), then homing Z using G30 probes just once and then reports "Homing failed".
- If I set M558 F1000:300 A2, then homing Z works. It probes once at the fast speed, moves up to the dive height (even if I started at a much greater height with Z not homed), then probes twice at the slow speed.
My G30 command to home Z has no parameters.
@pkps and @fulg, does the issue still occur if you remove the Z-99999 parameter from the G30 command?
@pkos and @sebkritikel, what A parameter are you using?
-
@dc42 I am using A10.
Just in case, my config is at the top.
I am not sure if you need the whole config.g or if the things up there are enough.
-
@pkos, I just found a way to reproduce the issue you saw:
- Send Z to +50
- Send G92 Z0
- Send M18 Z to flag Z as not homed
- Send G30 (after setting M558 A2 to avoid the other bug)
I am about to test the fix.
-
@dc42 Nice. I saw that M18 would also trigger this, but couldn't always reproduce it (so didn't want to waste your time with it).
For the time being, I just removed M18 from my end gcodeAwesome you found it.
-
The fix is working and will be in 3.3RC1.
-
@dc42 Awesome. Can't wait Thank you.
-
@dc42 said in [RRF3.3b2] Possibly incorrect behavior when homing Z:
@pkos and @sebkritikel, what A parameter are you using?
For posterity:
M558 P9 C"^zprobe.in" H5 F1000:200 A8 R0.75 T6000 S.02