3.5.0rc4 - G29 crashes nozzle into bed after first probe point
-
@omtek does it report an error in the console when it crashes? I noticed a small difference between the videos: when M558 H5 is set, the crash happens immediately the probe is triggered. With M558 H5:1, it completes the first probe, backs off (I can’t tell if it’s 5mm or 1mm) then probes again. When this second probe is triggered, it then crashes.
Also, you don’t need to test this on the bed. If you lower the bed say 100mm, you can trigger the probe manually, to see where it’s actually trying to go. But keep that finger over the emergency stop, too!
Ian
-
@omtek
I've some macro going on for my klicky to unload/load it. I'll post the macro's maybe they can help you out to atleast prevent the crashes from happening.I must admit I didn't read through all your macro files and I'm not on 3.5 yet so not sure if it will be of any help or not but still figured I'd post them in an attempt to help out.
All of these files are in their own directory called
ZProbe
initialize.g
if global.probe_type == 0 ; Set config values for the BLTouch M98 P"/macros/ZProbe/BLTouch/initialize.g" elif global.probe_type == 1 ; Set the config values for the Klicky probe M98 P"/macros/ZProbe/Klicky/initialize.g"
deploy_probe.g
; Command to deploy the probe for Z moves that require probing if global.probe_type == 0 ; Deploy probe for BLTouch M98 P"/macros/ZProbe/BLTouch/deployprobe.g" if global.probe_type == 1 ; Deploy probe for Klicky M98 P"/macros/ZProbe/Klicky/deployprobe.g"
retract_probe.g
; Command to retract the probe if global.probe_type == 0 ; Retract the probe for the BLTouch M98 P"/macros/ZProbe/BLTouch/retractprobe.g" if global.probe_type == 1 ; Retract the probe for Klicky M98 P"/macros/ZProbe/Klicky/retractprobe.g"
as you can see I use this to be able to switch between probes (I once had the idea to create RatRepFirmware but due to time constraints and to many projects I haven't really continued on it)
The specific klicky files:
initialize.g
; Setup the probe details for the Klicky probe M558 P8 C"121.io0.in" I1 H2 R0.1 F240:60 T8000 A5 S0.01 ; set Z probe type to unmodulated and the dive height + speeds G31 P25 X-24.526 Y-20.725 Z3.29 ; set Z probe trigger value, offset and trigger height, more Z means closer to the bed
deployprobe.g
; The deploy command for Z when using a dockable probe if sensors.probes[0].value[0] != 0 var originX = {move.axes[0].machinePosition} ; Store the X position before grabbing the probe. var originY = {move.axes[1].machinePosition} ; Store the Y position before grabbing the probe. G1 X60 Y11.5 F9000 ; Move tool in front of dock G1 X7.30000 Y11.5 F9000 ; Move tool in position where probe is mounted G1 X60 Y11.5 F9000 ; Move tool in front of dock if var.originX > 60 || var.originY > 11.5 ; Move the toolhead back to the position we came from G1 X{var.originX} Y{var.originY} F9000 M400 if sensors.probes[0].value[0] != 0 abort "Error probe not attached - aborting"
retractprobe.g
; The retract command for Z when using a dockable probe if sensors.probes[0].value[0] != 1000 G90 G1 X60 Y11.5 F9000 ; Move tool in front of dock M400 G1 X7.30000 Y11.5 F9000 ; Move tool in position where probe is mounted G1 X7.30000 Y42 F9000 ; Move tool to detach probe G1 X60 Y11.5 F9000 ; Move tool in front of dock M400 if sensors.probes[0].value[0] != 1000 abort "Error probe not docked - aborting"
TLDR;
I'm manually taking care of the mounting/docking and make sure to check the state of the probe before continuing any movementsI also posted this macro to help determine the dock details and it'll generate most files for you afterwards
https://forum.duet3d.com/topic/30495/dockable-probe-configurator-macro?_=1713439239779 -
@gloomyandy Correct. G29 behavior is unchanged between 3.5.0rc4 and 3.5.0.
@droftarts No errors in the console. And the behavior is definitely different when using M558 H5 and M558 H5:1.
I tried lowering the bed, setting the dive height to H20 (so I would have time to get something under the switch). I was able to manually trigger the klicky at which point the bed would lift back to dive height and attempt to probe again. Could do this 5 times before the probe would dock and G29 would be canceled. Presumably I was unable to trigger within the necessary deviation, which is why I didn't get the crash I've been observing.
During this process, the two times I did get an error (
Error: M400: Probe already triggered before probing move started
), it was when I manually triggered the probe, but the bed was still moving to dive height. -
@omtek I've been able to reproduce this problem on my test setup. We are currently investigating to understand exactly what is happening.
-
@omtek We think the issue is the deployprobe.g file that controls the probe. If you have an
M400
in there, change it toM400 S1
. I think this change has been brought about by some tweaking to the multiple motion system code. @Nurgelrot and @gloomyandy have been investigating this today, tip-o-the-hat to them!Ian
-
@droftarts I've updated the
M400
line in my deployprobe.g,but haven't had a chance to test yet.and can confirm G29 is working as expected now.I didn't see anything mentioning a change to how M400 functions in the release notes, nor was anything flagged in ReleaseMgr. Was this an intended change to the default behavior of M400? This was very expensive to resolve and I'd like to avoid further damage in the future.
-
@omtek I'm asking the same questions! I'll let you know.
Ian
-
@omtek thanks for reporting this, and I'm sorry that you suffered a broken nozzle.
I have created issue https://github.com/Duet3D/RepRapFirmware/issues/978 to be resolved in RRF 3.5.1. Meanwhile I have added a new entry in the Upgrade Notes for RRF 3.5.0 to say that any use of M400 in deployprobe.g or retractprobe.g or macros that they call need to have the S1 parameter added.
-