@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.
Best posts made by jp.douarvil 0
-
RE: 3.5beta2 cold unload filament macro doesnt work
-
RE: G30: unexpected probe dive motion range
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
toZ = 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 inbed.g
,mesh.g
or any other configuration file for that matter.Thank you in advance for your help.
-
RE: G30: unexpected probe dive motion range
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
-
RE: G30: unexpected probe dive motion range
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.
-
RE: G30: unexpected probe dive motion range
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.
-
G30: unexpected probe dive motion range
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 expectedZ = triggerHeight + diveHeight
- probing stop height is somewhat in the ballpark of
Z = zMin - diveHeight - 2
rather than the expectedZ = triggerHeight - diveHeight
(according the documentation for the H parameter of the M558 command)
- probing starting height is
-
RE: G30: unexpected probe dive motion range
@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).