![Rat Rig Community [Unofficial]](https://cdn.discordapp.com/icons/582187371529764864/08375bea6b5b9088b6d4cfc2b6e25fba.webp?size=48){kind=icon}
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:
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
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
![Rat Rig Community [Unofficial] banner](https://cdn.discordapp.com/banners/582187371529764864/4ee3e42e227d6aac26f048a3e69d5924.webp?size=480)
The #1 unofficial Rat Rig Community on Discord!
14,070Members
Resources
Similar Threads
Was this page helpful?
![Rat Rig Community [Unofficial]](https://cdn.discordapp.com/icons/582187371529764864/08375bea6b5b9088b6d4cfc2b6e25fba.webp?size=16){kind=icon}