3.5.0rc4 - G29 crashes nozzle into bed after first probe point

gloomyandy

@omtek I'm a bit confused both of those videos show the probe getting pretty mangled. I assume neither is correct? Are both of those with 3.5.0rc4?

omtek

@gloomyandy Both videos are taken with 3.5.0rc4.

The first video was taken with M558 H5 while the second video was taken with M558 H5:1.

The second video depicts the nozzle crash as I initially experienced it; after the second lower & slower probe point, the bed is driven into the nozzle instead of raising. Then it tries to move to the second point.

In the first video, I adjusted M558 so only one dive height (H5) is used. There you see the bed being driven into the probe, completely ignoring that the switch was triggered.

droftarts

@omtek can you try the 3.5.0 release? https://github.com/Duet3D/RepRapFirmware/releases/tag/3.5.0

Ian

omtek

@droftarts I can, however I should probably wait for Team Gloomy to finalize their 3.5.0 release for the RRF36 board before testing anything.

gloomyandy

@omtek In the above videos what did you do to run the G29? Was it simply G29 from the console or did you run the mesh.g with parameters?

I don't think there are any changes in the expansion board code so you should be fine to go ahead and use the rc.4 version of the RRF36 firmware for testing with 3.5.0. DWC will complain about mismatched versions but I think it should work fine.

It might be worth reducing the z motor current to try and avoid any further damage.

omtek

@gloomyandy Both videos I ran G29 from DWC (after homing XYZ, and running G32, also from the DWC).

G32 runs with out issue, too. Usually takes a few tries, though.

It might be worth reducing the z motor current to try and avoid any further damage.

An excellent idea. I've modified the M913 in my config accordingly.

Nurgelrot

I was just able to reproduce this issues using a detachable prob (Klicky) Homing works G32 works. manually running M401/402 to get and store the porbe works but when issuing G29 it error with 4/17/2024, 8:26:56 PM g29 Error: G1: Probe already triggered before probing move started and all hell breaks loose if you dont hit estop fast.

This was with 3.5.rc4 on an Octopusprov1.0 and a 1LC toolboard. So it dosen't seem to be port/board specific. Let me know what data you need. This is one of my best printing units so I'm loth to do too much damage to it testing but happy to help out as much as I can.

omtek

@gloomyandy I just finished updating what I could to 3.5.0. ~~(still need to compile firmware for the CannedERCF board, but I think it's ok doing CAN passthrough~~compiled tonight).

After making sure motors were running at 80%, homing XYZ, then ran G32 (almost got it in two passes) followed by G29 (using the buttons in DWC), the KlickyPCB is picked up and moved to the first probe point, and as soon as the Klicky is triggered the bed drives itself into the probe. I had my finger on the E-Stop this time so I wasn't able to see if it attempted to move to the second probe point.

gloomyandy

@omtek So basically it does the same thing with 3.5.0 as it was doing before?

droftarts

@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

mher

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

I 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

omtek

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

gloomyandy

@omtek I've been able to reproduce this problem on my test setup. We are currently investigating to understand exactly what is happening.

droftarts

@omtek We think the issue is the deployprobe.g file that controls the probe. If you have an M400 in there, change it to M400 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

omtek

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

droftarts

@omtek I'm asking the same questions! I'll let you know.

Ian

dc42

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

dc42 created this issue in Duet3D/RepRapFirmware

3.5.0rc4 - G29 crashes nozzle into bed after first probe point

closed Using M400 in deployprobe.g causes machine to try to move outside limits #978