[RRF3.3b2] Possibly incorrect behavior when homing Z

pkos

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.

This is a problem for me, since I often have prints running and the printer shuts itself off completely after it cools down.

So then, when I want to print again, the gantry is often quite high and it takes a long time to get it to home again.

fulg

@pkos My printer is down at the moment but as far as I remember this works for me? Granted I did not run 3.3b2 for long, but the first trigger of the probe should establish Z=0 (you should see the "Home Z" button turn blue in DWC as soon as the probe is triggered), then the gantry rises by the dive height and the 2nd probe occurs...

pkos

They say a picture tells a thousand words.

This is what I see.

https://www.youtube.com/watch?v=0EZ7CqDl-Io

The key to make this happen is set double speeds for probing.
So in my case it's F350:60

fulg

@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 of G1 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".

OwenD

@pkos said in [RRF3.3b2] Possibly incorrect behavior when homing Z:

@owend

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.

pkos

@phaedrux Just checking in - is this possibly something that can be checked seeing as how others are now confirming the issue?

Phaedrux

Yes I've asked @DC42 to comment when he gets a chance.

pkos

@phaedrux FYI - checked with 3.3b3 - behavior still there.

sebkritikel

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)

dc42

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?

pkos

@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.

dc42

@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.

pkos

@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 gcode

Awesome you found it.

dc42

The fix is working and will be in 3.3RC1.

pkos

@dc42 Awesome. Can't wait Thank you.

sebkritikel

@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