Move out of range

[c10l]

At the beginning of a print, just past the first curve of the brim and before it prints a long straight line, I get the error:

Move out of range: 163.143 61.316 -0.021 [295.519]

I don't understand why it thinks it's going to a negative Z if the move is horizontal.

klippy.log printer.cfg print.gcode

[c10l]

Turns out this was due to the bed leveling. Klipper is trying to compensate for the warpage but that means going negative.

I would think that negative vertical moves done automatically by Klipper should take into account the bed levelling data and offset it from the physical height it's trying to move to.

After a suggestion from Maász István on the Klipper Facebook group I worked around this issue by setting a negative position_min on the Z axis but that's clearly suboptimal.

[KevinOConnor]

This is by design - the position_min, position_max, and position_endstop define locations on the linear rail controlling the axis. Setting a position_min is setting a limit on the rail, not on the distance between nozzle and head. I understand that this can be confusing - in particular when using probe:z_virtual_endstop. I suspect better documentation would help.

-Kevin

[c10l]

@KevinOConnor I know where you're coming from, but this is not just about unclear documentation.

When I have a probe that I use to compensate for bed warpage or tilt, I want that data to be taken into account. It I set my position_min to say -1 in order for it to even work, that means I'm explicitly allowing the nozzle to hit the bed at points where it's higher than that. If my Z offset is correct, I want my position_min to always be 0, but still rest assured that my bed's shape is offset from that. The same goes for points where it might be higher. If Klipper is not taking it into account, it means it's more likely to hit the bed at those points.

[KevinOConnor]

Understood. The goal of the current boundary checks is to catch obviously incorrect requests. (Obvious, at least from the perspective of the linear rail.) If someone wishes to add additional code to perform other checks then that is fine. It's not something I plan to work on.

-Kevin

[c10l]

Fair enough! It seems unlikely at the moment but if I do get some time to study Klipper's code base I might have a stab.

[KevinOConnor]

Okay. Feel free to open a pull request if you have something.

[mtw3d]

I know this is a closed issue, but I was about to report the same error, and I feel it really should be revisited since it can result in dangerous behavior.

As it is designed now, ABL just changes the Gcode for the moves internally. That is simple and on the surface makes sense. Errors like this are just a minor annoyances that is easily fixed by setting a lower min position.

The problem is the easy fix has dangerous consequences. If your bed has a skew from -1 on the low end to +1 on the high end, you are allowing a move that could end up being 2mm below the build surface. Crashing that the Z there shouldn't cause mechanical issues on anything but the flimsiest printers, but could easily destroys a build surface like Buildtak if you crash a hot hotend, so that could easily be an expensive mistake.

It seems to me that the more sensible way to handle this would be to have the error handling routine aware of the bed mesh, and to consistently apply the bed mesh to all Z moves, so moving to Z0 would get you to z-1 on the extreme low end, and z1.0 on the extreme high end, with no risk of crashing or unnecessary errors.

Couldn't this be done just by changing the order of operations? It is already applying the ABL compensation and the error checking for these moves, so it would seem to be just a matter of changing when it does the various checks.

[libby2cm]

I know this is a closed issue, but I was about to report the same error, and I feel it really should be revisited since it can result in dangerous behavior.

As it is designed now, ABL just changes the Gcode for the moves internally. That is simple and on the surface makes sense. Errors like this are just a minor annoyances that is easily fixed by setting a lower min position.

The problem is the easy fix has dangerous consequences. If your bed has a skew from -1 on the low end to +1 on the high end, you are allowing a move that could end up being 2mm below the build surface. Crashing that the Z there shouldn't cause mechanical issues on anything but the flimsiest printers, but could easily destroys a build surface like Buildtak if you crash a hot hotend, so that could easily be an expensive mistake.

It seems to me that the more sensible way to handle this would be to have the error handling routine aware of the bed mesh, and to consistently apply the bed mesh to all Z moves, so moving to Z0 would get you to z-1 on the extreme low end, and z1.0 on the extreme high end, with no risk of crashing or unnecessary errors.

Couldn't this be done just by changing the order of operations? It is already applying the ABL compensation and the error checking for these moves, so it would seem to be just a matter of changing when it does the various checks.

In my case, I only had to set min to -1 and I can tighten it down even further from there. If you get your bed physically level as much as possible, -.3 or better should be enough to account for variance, and even if it bottoms out, nothing should be damaged. And, nozzles are cheap..