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

omtek

init.g

if !exists(global.RunDaemon)
	global RunDaemon = true 

if !exists(global.BedPreheatTemp)  
	global BedPreheatTemp = 60
	
if !exists(global.Cancelled)  ; global variable for exiting out of loops
	global Cancelled = false 

if !exists(global.filamentDistance)
	global filamentDistance = 0

if !exists(global.filamentFeedSpeed)
	global filamentFeedSpeed = 180

if !exists(global.filamentRetractSpeed)
	global filamentRetractSpeed = 1800

It sets up some global variables I had hoped to use for universal filament load/unload but haven't fully implemented. I was planning on using them to make dropping a configuration for a ERCFv2 on top of everything a little more seamless.

I have another file of variables that gets loaded along with the ERCFv2 configuration. They were present in the OM during the first nozzle crash, but not during subsequent crashes.

ercf_init.g


;; global declarations for ERCF
;; some defaults established
;; and variables set and loaded

if !exists(global.ercf_settings_loaded)
	;=== configuration - general settings ===;
	global ercf_bowden_length = 630                              ;; distance until the filaent is at the end
	global ercf_extruder_load_length = 50                        ;; Orbiter 2.0 on EVA3 with E3D Revo Voron hotend
	;=== configuration - blinky pulse count ===;
	global ercf_pulse_count = 0
	global ercf_last_count = 0
	;=== configuration - selector ===;
	global ercf_selector_loaded = 0
	global ercf_selector_engaged = 0	
    ;global ercf_selector_array = {0,22,43,69.2,90.7,112,112,112}
	global ercf_selector_0 = 0
	global ercf_selector_1 = 24
	global ercf_selector_2 = 47
	global ercf_selector_3 = 70
	global ercf_selector_4 = 93
	global ercf_selector_5 = 116
	global ercf_selector_6 = 139
	global ercf_selector_7 = 162
	global ercf_selector_offset = 3.700

droftarts

@omtek It may be the stack space issue. @gloomyandy suggested @Nurgelrot rewrite his macro without so much nesting, which worked, so that may solve your problem. See their conversation on Discord here https://discord.com/channels/711873626080804914/930484450389786655/1229517039174025277
Or wait and see if the changes made post-rc4 (this one, I believe https://github.com/Duet3D/RepRapFirmware/commit/e7cc658546652d32756b1c5b05c1cf923f234edb) fix your problem when 3.5.0 stable is released (very soon!).

Sorry for the damage to your machine. We try very hard NOT to break things!

Ian

0

dc42 committed to Duet3D/RepRapFirmware

Reduce stack usage of ParseExpectKet when no array indices are used

omtek

@droftarts

I updated back to 3.5.0rc4 and tested the Z-motion again. Bed was able to move fully throughout it's range and I didn't observe any knocking or binding. DWC reported the speed capped out at 15mm/sec during the moves.

I double checked the original settings and my Z-axis jerk was a bit higher than the RatRig default (their M205 was Z0.1, mine was Z0.4). I've made the necessary change to my configuration.

Since I was back on 3.5.0rc4, I captured video of the occurrence, and the different behavior between H5 and H5:1.

This is with a single dive height specified in M558 (H5)

https://www.youtube.com/watch?v=SRwe0mazqtQ

This is with M558 H5:1. This is what bent the nozzle and scored the PEI.

https://www.youtube.com/watch?v=r0-zQG1yvtM

oliof

@omtek just to make sure, did you do true bed leveling before the mesh?

omtek

@oliof Correct, during these tests/videos I ran G32 followed by a G29.

During a print, my start.g contains the G32, while the G29 is handled by the slicer start g-code calling mesh.g directly and passing the parameters for mesh generation only where printing.

start.g

T0         ; ensure the tool is selected

M220 S100  ; set speed factor back to 100% in case it was changed
M221 S100  ; set extrusion factor back to 100% in case it was changed
M290 R0 S0 ; clear any baby-stepping
M106 P0 S0 ; turn layer fan off if it is on
M400       ; finish all moves, clear the buffer

M98 P"0:/sys/setBuildPlate.g" ; pull in build plate parameters 
							; heightmap, probe height, etc.

; chamber LEDs on
M98 P"0:/macros/LEDs/led_on.g"
		
G32		   ; 3-point bed leveling

;M501	   ; load config-override.g
M703	   ; load filament-specific config.g


M98 P"0:/sys/setInputShaping.g" ; pull in input shaping parameters

G90        ; absolute Positioning
M83        ; extruder relative mode

;=== DuetLapse3 control ===;
;M291 P"DuetLapse3.start" S2
;M292
;G4 S10
    
M98 P"0:/sys/setDefaultProbePoints.g" ; reset probe points, just in case

;=== slicer start code ===;

slicer start g-code

M98 P"0:/sys/mesh.g" A{first_layer_print_min[0]} B{first_layer_print_max[0]} C{first_layer_print_min[1]} D{first_layer_print_max[1]} N20 ; set N to your desired distance between points
G29 S1 ; load small mesh
M140 S[first_layer_bed_temperature] ; set bed temp
M104 S[first_layer_temperature] ; set extruder temp
G0 X30 Y30 Z0.2 F6000 ; move ahead of prime line position and wait for temp
G92 E0.0
M190 S[first_layer_bed_temperature] ; wait for bed temp
M109 S[first_layer_temperature] ; wait for extruder temp
G0 X5 E10.0 Z0.2 F6000 ; move to prime line position and advance filament 10mm to fill heat break
G1 X60.0 E9.0 F1000.0 ; intro line
G1 X140.0 E10 F1000.0 ; intro line
G92 E0.0
G0 Z1 F1000 ; dab
M106 S0

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.