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
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.
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 🙂
Unfortunately not, variables can only be used in gcode macros
Yep, i'll just need to decide which is better 🙂
Awesome, thanks for your help and clarification!
correct-apricot•13mo 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?
Which probe?
correct-apricot•13mo ago
Bl touch
I see.. Well
Put that in user overrides
Set it to however high you want it
the default is 5
correct-apricot•13mo ago
Oh just in the config, sorry I thought that would not work from how I read the post thank you.