RatOS Adaptive Mesh requires manually editing bed_mesh horizontal_move_z

Not sure if this is know to be required, but when adaptive meshing with a euclid probe (just installed), the bed was not moving down enough with the horizontal_move_z of 5. This was causing the probe to continue to be triggered as the toolhead moved over to probe the priming location, which caused RatOS to think the probe was stowed instead of deployed. Specifically, these are the klipper logs when it happens during the "CALIBRATE_ADAPTIVE_MESH" and nested "PROBE_FOR_PRIMING" macros (newest msg first). 9:16 PM Error evaluating 'gcode_macro _ASSERT_PROBE_STATE:gcode': gcode.CommandError: expected probe state to be deployed but is stowed (1) 9:16 PM probe: TRIGGERED 9:16 PM echo: PROBE_FOR_PRIMING: Probing the prime location at X: 292.942 Y: 36.75 9:16 PM echo: Probing the prime location.. 9:16 PM echo: CALIBRATE_ADAPTIVE_MESH: Recieved coordinates X0=64.0715 Y0=77.0533 X1=235.931 Y1=225.53 Looking at the "PROBE_FOR_PRIMING" macro, it takes the z_hop value from: z=printer.configfile.settings.bed_mesh.horizontal_move_z Where it is then used here in the "PROBE_FOR_PRIMING" macro, and where I believe my issue appeared: Lift to horizontal_move_z G0 Z{z} F{z_speed} Once I edited the bed_mesh horizontal_move_z value from 5 to 15, I no longer saw this issue. Is this expected behavior, in that the user should update the horizontal_move_z value to support the probe they're using? I would have thought it would either use the "z_hop" value overridden in the euclid.cfg config (below), or would define its own bed_mesh horizontal_move_z in the probe configs to compensate. [ratos_homing] z_hop: 25
9 Replies
miklschmidt
miklschmidt•13mo ago
That is indeed required. 10 should be enough however. [bed_mesh] is it's own config section in klipper. It requires explicit configuration. I guess it could override it in the probe includes. I didn't add it because i didn't want the probe includes to force bed mesh definitions.
absent-sapphire
absent-sapphire•13mo ago
Got it, that makes sense - ya I can see both sides, it's an attribute of bed_mesh, but it's also directly related to the probe you're using. Just brainstorming, if 5 is the default, is there some way you could create a "probe_horizontal_move_z_offset" variable that you add to the bed_mesh horizontal_move_z value? That way the definitions stay separate, but are logically combined That, or just a note in the stowable probes ratos docs that you'll have to edit the above 🙂
miklschmidt
miklschmidt•13mo ago
Unfortunately not, variables can only be used in gcode macros Yep, i'll just need to decide which is better 🙂
absent-sapphire
absent-sapphire•13mo ago
Awesome, thanks for your help and clarification!
exotic-emerald
exotic-emerald•6mo ago
I need to do the same as my probe once upgraded to the EVA 3 sometimes starts already touching the bed throwing off the calibration, I can't seem to locate the horizontal_move_z value. Or should I be editing simply the z-hop?
miklschmidt
miklschmidt•6mo ago
Which probe?
exotic-emerald
exotic-emerald•6mo ago
Bl touch
miklschmidt
miklschmidt•6mo ago
I see.. Well
[bed_mesh]
horizontal_move_z: 15
[bed_mesh]
horizontal_move_z: 15
Put that in user overrides Set it to however high you want it the default is 5
exotic-emerald
exotic-emerald•6mo ago
Oh just in the config, sorry I thought that would not work from how I read the post thank you.
Want results from more Discord servers?
Add your server
More Posts