@Adrian52 just for info if that can help, you can use M302 P0 S0 R0 in the mean time.
@dc42 Thank you very much for the tremendous work.

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.

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

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.

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.

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)

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

Hi,

@Diamondback Does any of your tool change routine (tpre#.g, tfree#.g, tpost#.g) contains G92 command?

I am also fighting with similar Z axis drift issue. At this point of my investigations it seems like this issue is related to the use of the G92 command, with or without Z argument, in the RRF3.5.0rc1 firmware.

In my case, the issue occurs quasi-randomly whenever using the G92 command in either a gcode print file or a system macro.
I say "quasi-randomly" in the sense that not every execution of a G92 triggers the bug, but when the bug occurs printer coherently acts as if the last movement of the Z axis before the G92 command was properly executed but not being tracked ( @dc42 ms.coords[Z_AXIS] variable not updated at some point between the beta4 and rc1 ?), not as if one board had randomly hung, or executed some corrupted data. I say "coherently act" because:

• on system ①, I am using 2 separated 1HCL boards each controlling 1 of the 2 independent Z axis motors of the printer. From time to time I observed Z axis drift higher than 6mm upon executing a single system macro. Random data corruption or system interrupt on a single board would surely result in randomly tilting the bed left or right, which I do not observe at all
• on system ②, the 2 independent Z axis motors are controlled by the same 3HC board. "Expectedly" no bed tilt is observed here too. Meaning this issue is probably independent from the board use (i haven't tried to plug both Z motors on the 6HC main board though).
• both systems ① and ② exhibit the issue with RRF 3.5.0rc1, not with 3.5.0b4 or 3.4.xxx

@Diamondback Note that I have no intention on hijacking your thread, I am only providing additional info relevant to your problem which I suspect could help RRF developers to quickly find the origin of the problem and come with a solution.

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.

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

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

I don't know how to connect the second wire to the duet to take direction into account. A quick and dirty work-around might be to post-process your g-code so to deactivate filament tracking just before a retraction move and reactivate it immediately afterward.

@Tinchus
RRF is a multipurpose firmware, it is supposed to be very tunable. Hence, depending on your specific hardware, sending negative E value does not necessarily equate to a retraction move (it could be just for unjamming, for backlash compensation, for a special tool change move or who knows what). So, unless you specifically indicate the firmware to retract/unretract filament (G11 command) the firmware will not assume by default that negative E value means a retraction which tracking value mustn't be taken into account.

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.

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

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.

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.