G30: unexpected probe dive motion range

jp.douarvil 0

Hi everybody,

(sorry for the multiple posts, Akismet seems quite angry at long posts)

Upon migrating from RRF3.4.5 to RRF3.5.0B2 & B3 I started running into bed tilt correction (customized G32 using G30 single point probing) issues:

probing starting height is Z = diveHeight instead of the expected Z = triggerHeight + diveHeight
probing stop height is somewhat in the ballpark of Z = zMin - diveHeight - 2 rather than the expected Z = triggerHeight - diveHeight (according the documentation for the H parameter of the M558 command)

jp.douarvil 0

Further investigating, I realized that the odd probing stop height was already a thing, however that I hadn't noticed, on RRF3.4. I am fairly confident that this issue is indeed related to the herementioned unexpected behavior. Diving into the origin of the problem, it looks like the odd stop height for the G30 command when the Z axis is already homed is computed differently than for G29 moves.

jp.douarvil 0

Regarding the odd probing start height experienced with RRF3.5 however I haven't found the origin of the issue. But it seems like I am not the only one scratching my head on it. Using large dive height value is a good enough temporary band-aid but doesn't make for very robust/maintainable configuration files in my opinion.

jp.douarvil 0

Below is a bed.g configuration exhibiting the described behavior:

; bed.g
; called to perform automatic bed tilt correction via G32

M400    ; wait until end of motions

var probTrigHeight = 9.0
var hoverHeight = 4.0
var deltaZ = 0.0

M671 X-105:405 Y0:0 S1.5                      ; set position of Z leadscrews
G29 S2                                        ; disable mesh compensation
G31 Z{var.probTrigHeight}                     ; set trigger height
M558 K0 H{var.probTrigHeight-var.hoverHeight} ; set dive height so nozzle never dives below the "hover height" (nozzle crash prevention)

while true
    G30 P0 X10 Y5 Z-99999    ; probe near -X leadscrew
    set var.deltaZ = sensors.probes[0].lastStopHeight
    G30 P1 X290 Y5 Z-99999  ; probe near left leadscrew
    ;set var.deltaZ = {var.deltaZ - (var.deltaZ + sensors.probes[0].lastStopHeight)/2}
    set var.deltaZ = 0.5*(var.deltaZ - sensors.probes[0].lastStopHeight) ; edit: just simplified the assignment above
    
    if {(var.deltaZ < 0.1) || (iterations > 5)}
        break

    ; correct only the bed tilt
    G30 P0 X10.0 Y0.0 Z{var.deltaZ} H0.0
    G30 P1 X290.0 Y0.0 Z{-var.deltaZ} H0.0 S2

M400    ; wait until end of motions

jp.douarvil 0

Is the described unexpected behavior unintended or did I misunderstood something about the use of the G30 command.

I personally like the principle of probing the height range extending from Z = triggerHeight + diveHeight to Z = triggerHeight - diveHeight.
Given that both the trigger height and dive height are GCODE configurable floats (signed), it makes for very versatile and comprehensive implementation of custom probing moves in bed.g , mesh.g or any other configuration file for that matter.

Thank you in advance for your help.

Phaedrux

I think akismet didn't let all your embeded links.

jp.douarvil 0

@Phaedrux actually, I tried posting the same message without link at all to no avail. Limiting the length of each message was the only effective solution.

Below is my attempted workaround:

; bed.g
; called to perform automatic bed tilt correction via G32

M400    ; wait until end of motions

var probTrigHeight = 9.0
var hoverHeight = 4.0
var deltaZ = 0.0
var zMin = move.axes[2].min

M671 X-105:405 Y0:0 S1.5                      ; set position of Z leadscrews
G29 S2                                        ; disable mesh compensation
;G31 Z{var.probTrigHeight}                     ; set trigger height

; temporary workaround the dive range non-centered around the trigger height "bug"
;;
M400
G31 Z0	; reset probe trigger height
M208 Z0 S1
G92 Z{move.axes[2].machinePosition - var.probTrigHght}
;;
M558 K0 H{var.probTrigHeight-var.hoverHeight} ; set dive height so nozzle never dives below the "hover height" (nozzle crash prevention)


while true
    G30 P0 X10 Y5 Z-99999    ; probe near -X leadscrew
    set var.deltaZ = sensors.probes[0].lastStopHeight
    G30 P1 X290 Y5 Z-99999  ; probe near left leadscrew
    set var.deltaZ = 0.5*(var.deltaZ - sensors.probes[0].lastStopHeight)
    
    if {(var.deltaZ < 0.1) || (iterations > 5)}
        break

    ; correct only the bed tilt
    G30 P0 X10.0 Y0.0 Z{var.deltaZ} H0.0
    G30 P1 X290.0 Y0.0 Z{-var.deltaZ} H0.0 S2

; temporary workaround the dive range non-centered around the trigger height "bug"
;;
M400
G31 Z{var.probTrigHght}	; reset probe trigger height
M208 Z{var.zMin} S1
G92 Z{move.axes[2].machinePosition + var.probTrigHght}
;;
M400    ; wait until end of motions

It works as expected but as you can tell it makes the code a bit confusing and long (i.e. seed for a difficult to debug spaghetti-code).

dc42

@jp-douarvil-0 said in G30: unexpected probe dive motion range:

I personally like the principle of probing the height range extending from Z = triggerHeight + diveHeight to Z = triggerHeight - diveHeight.

That is the intention of the current code in RRF when the trigger height is not less than zero. Isn't it working that way?

jp.douarvil 0

@dc42 said in G30: unexpected probe dive motion range:

@jp-douarvil-0 said in G30: unexpected probe dive motion range:

I personally like the principle of probing the height range extending from Z = triggerHeight + diveHeight to Z = triggerHeight - diveHeight.

That is the intention of the current code in RRF when the trigger height is not less than zero. Isn't it working that way?

Thank you for the feedback.

I noticed that in practice the nozzle systematically dive below Z=0. Hence I assume the observed behavior to be a bug.

I proposed a patch but I haven't personally compiled and tested the patched firmware. Patch is based on the code for the G29 command.

Could this fix the issue? If so it might be nice to patch the 3.4 as well for non-beta testers.

dc42

@jp-douarvil-0 said in G30: unexpected probe dive motion range:

I noticed that in practice the nozzle systematically dive below Z=0.

It will do that if the probe is not triggered. If you set the dive height to some value H then that implies you are uncertain as to the exact height of the bed to within a distance +/-H. So the code starts the dive at (trigger_height + H) and ends it if the probe is not triggered first at (trigger_height - H); except that if the trigger height is negative then we just go from +H to -H.

jp.douarvil 0

My profuse apologies for:

my (very) late answer
digging up this old topic (Halloween trick or treat ?!)

but my answer is still relevant (based on the code base of the RRF 3.5.0 rc1 and 3.4.6).

@dc42 said in G30: unexpected probe dive motion range:

If you set the dive height to some value H [...] the code starts the dive at (trigger_height + H) and ends it if the probe is not triggered first at (trigger_height - H)

That is my expectation, but not what the G30 command currently does.

You will notice in the code of G30 command the mention of platform.AxisMinimum(Z_AXIS), variable which I can't make sense of:

ms.coords[Z_AXIS] = (IsAxisHomed(Z_AXIS)) ? ~~platform.AxisMinimum(Z_AXIS)~~ - zp->GetDiveHeight() + zp->GetActualTriggerHeight()

This is in contrast to the probing code of the G29 command, which works as you described without ever using platform.AxisMinimum(Z_AXIS):

ms.coords[Z_AXIS] = -zp->GetDiveHeight() + zp->GetActualTriggerHeight();

Hence my (old yet still relevant) pull request.

Hopefully this patch would not bring any regression, however it might save multiple RRF user from less than desirable unexpected nozzle crashes.