Post-mesh move out of range error

[lincolnjohnson]

This was originally written as a bug report, but I don't think it's really a bug in anything that comes from this repo. But I solved it by adjusting the PRINT_START macro, so here it is.

Describe the bug
After a KAMP enabled bed_mesh_calibrate, before the purge_line macro, Klipper sometimes reports a "Move out of range error".

When the G1 X0 Y0 F{maxVelocityAdjusted} G-code is called in the PRINT_START macro, the error occurs.

It seems to occur only when the final probe point has an X value of -0.000.

To Reproduce
I've only observed this with my SV06 Plus printer and one specific sliced file, not on my SV06, so I'm not going to claim it's reproducible.

Modifying G1 X0 Y0 F{maxVelocityAdjusted} to G1 X0.01 Y0.01 F{maxVelocityAdjusted} fixes/bandaids it.

I have not updated the firmware on the printer MCU due to only having sovol SD cards that won't let me flash klipper, but the host klipper is fully updated. MCU version on my plus is 0.12.0-10, host is 0.12.0-289. I suspect that this may be a klipper firmware issue, but I'm reporting it here so anyone else who runs into the same might discover this as a solution/workaround.

What printer are you using?

• SV06 & SV06 Plus

What kind of device are you using to host Klipper?

• OS: Raspberry Pi 4B
• Version: fully updated

How did you install Klipper?

KIAUH

Is your local copy of this configuration up to date?

Yes

What slicer are you using?

• PrusaSlicer

Are you using the config bundles from this repo?

• Yes

Did you Adjust your slicer?

• Yes

[bassamanator]

Is this occurring on both printers? What are the microsteps for the steppers in the printer.cfg, and I'm assuming that the printer motherboards are stock.

Picture of the error message if possible.

[lincolnjohnson]

The errors are gone from the mainsail interface on my Plus, but here they are from the log of my plus (3 separate instances):

Move out of range: -0.000 68.369 5.028 [0.000]
Move out of range: -0.000 78.369 5.027 [0.000]
Move out of range: -0.000 83.369 5.026 [0.000]

Microsteps for all steppers is 128. Yes stock motherboards.

I determined that the issue was with the G1 command because the M109 S{hotendtemp} command wouldn't get triggered.

---

I was able to replicate the issue on my SV06 this morning, so it's obviously not only the firmware on the Plus.

Here's the complete list of entries in the mainsail log:

9:34 a.m.
Move out of range: -0.000 49.770 5.025 [0.000]
9:34 a.m.
Move out of range: -0.000 49.770 5.025 [0.000]
9:34 a.m.
Bed Mesh state has been saved to profile [default]
for the current session.  The SAVE_CONFIG command will
update the printer config file and restart the printer.
9:34 a.m.
Mesh Bed Leveling Complete
9:34 a.m.
probe at -0.000,159.770 is z=1.435312
9:34 a.m.
probe at -0.000,159.770 is z=1.435312
9:34 a.m.
probe at -0.000,159.770 is z=1.435781
9:34 a.m.
probe at 37.591,159.770 is z=1.466875
9:33 a.m.
probe at 37.591,159.770 is z=1.467344
9:33 a.m.
probe at 37.591,159.770 is z=1.467969
9:33 a.m.
probe at 75.180,159.770 is z=1.457344
9:33 a.m.
probe at 75.180,159.770 is z=1.457344
9:33 a.m.
probe at 75.180,159.770 is z=1.457031
9:33 a.m.
probe at 112.770,159.770 is z=1.457187
9:33 a.m.
probe at 112.770,159.770 is z=1.457344
9:33 a.m.
probe at 112.770,159.770 is z=1.457500
9:33 a.m.
probe at 112.770,115.180 is z=1.467031
9:33 a.m.
probe at 112.770,115.180 is z=1.466719
9:33 a.m.
probe at 112.770,115.180 is z=1.467344
9:33 a.m.
probe at 75.180,115.180 is z=1.451250
9:33 a.m.
probe at 75.180,115.180 is z=1.450781
9:33 a.m.
probe at 75.180,115.180 is z=1.451250
9:33 a.m.
probe at 37.591,115.180 is z=1.468906
9:33 a.m.
probe at 37.591,115.180 is z=1.469531
9:33 a.m.
probe at 37.591,115.180 is z=1.470469
9:33 a.m.
probe at -0.000,115.180 is z=1.435000
9:33 a.m.
probe at -0.000,115.180 is z=1.435312
9:33 a.m.
probe at -0.000,115.180 is z=1.435937
9:33 a.m.
probe at -0.000,70.591 is z=1.479531
9:33 a.m.
probe at -0.000,70.591 is z=1.479844
9:33 a.m.
probe at -0.000,70.591 is z=1.480781
9:33 a.m.
probe at 37.591,70.591 is z=1.509062
9:33 a.m.
probe at 37.591,70.591 is z=1.509531
9:33 a.m.
probe at 37.591,70.591 is z=1.510625
9:33 a.m.
probe at 75.180,70.591 is z=1.497187
9:33 a.m.
probe at 75.180,70.591 is z=1.497500
9:33 a.m.
probe at 75.180,70.591 is z=1.498437
9:33 a.m.
probe at 112.770,70.591 is z=1.500312
9:33 a.m.
probe at 112.770,70.591 is z=1.500625
9:33 a.m.
probe at 112.770,70.591 is z=1.501719
9:33 a.m.
probe at 112.770,26.000 is z=1.522812
9:33 a.m.
probe at 112.770,26.000 is z=1.522812
9:32 a.m.
probe at 112.770,26.000 is z=1.522812
9:32 a.m.
probe at 75.180,26.000 is z=1.531094
9:32 a.m.
probe at 75.180,26.000 is z=1.531094
9:32 a.m.
probe at 75.180,26.000 is z=1.530937
9:32 a.m.
probe at 37.591,26.000 is z=1.553594
9:32 a.m.
probe at 37.591,26.000 is z=1.554062
9:32 a.m.
probe at 37.591,26.000 is z=1.555000
9:32 a.m.
probe at -0.000,26.000 is z=1.537656
9:32 a.m.
probe at -0.000,26.000 is z=1.538281
9:32 a.m.
probe at -0.000,26.000 is z=1.537656
9:32 a.m.
15  | (0.0, 159.8)    | (27.0, 139.8)
9:32 a.m.
14  | (37.6, 159.8)   | (64.6, 139.8)
9:32 a.m.
13  | (75.2, 159.8)   | (102.2, 139.8)
9:32 a.m.
12  | (112.8, 159.8)  | (139.8, 139.8)
9:32 a.m.
11  | (112.8, 115.2)  | (139.8, 95.2)
9:32 a.m.
10  | (75.2, 115.2)   | (102.2, 95.2)
9:32 a.m.
9   | (37.6, 115.2)   | (64.6, 95.2)
9:32 a.m.
8   | (0.0, 115.2)    | (27.0, 95.2)
9:32 a.m.
7   | (0.0, 70.6)     | (27.0, 50.6)
9:32 a.m.
6   | (37.6, 70.6)    | (64.6, 50.6)
9:32 a.m.
5   | (75.2, 70.6)    | (102.2, 50.6)
9:32 a.m.
4   | (112.8, 70.6)   | (139.8, 50.6)
9:32 a.m.
3   | (112.8, 26.0)   | (139.8, 6.0)
9:32 a.m.
2   | (75.2, 26.0)    | (102.2, 6.0)
9:32 a.m.
1   | (37.6, 26.0)    | (64.6, 6.0)
9:32 a.m.
0   | (0.0, 26.0)     | (27.0, 6.0)
9:32 a.m.
bed_mesh: generated points
Index |  Tool Adjusted  |   Probe
9:32 a.m.
Generating new points...
9:32 a.m.
KAMP adjustments successful. Happy KAMPing!
9:32 a.m.
Adapted mesh bounds: (27.0, 6.0), (139.799, 139.787).
9:32 a.m.
Fuzz amount is 0, mesh points not fuzzed.
9:32 a.m.
Mesh margin is 0, margin not increased.
9:32 a.m.
Default mesh bounds: (27.0, 6.0), (222.0, 203.0).
9:32 a.m.
Adapted probe count: 4,4.
9:32 a.m.
Default probe count: 5,5.
9:32 a.m.
Algorithm: lagrange.
9:31 a.m.
File selected
9:31 a.m.
File opened

[lincolnjohnson]

Changing to G1 X0.01 Y0.01 F{maxVelocityAdjusted} on the SV06 also fixes it there.

[bassamanator]

Thanks for this. Any chance of getting the part you were printing, or about to print I should say? I'd like to see if I can reproduce when I have time.

I was going to say that this is a KAMP issue, but it looks like a Klipper issue.

I have compiled (and flashed onto my SV06) the latest klipper.bin, find it only on the master branch right now. Flash it and see if this issue is still there.

Another thing that might be worth looking into is whether speed is a factor. Adjust the line in misc-macros.cfg that says {% set maxVelocityAdjusted = (0.95 * maxVelocity * 60)|int %} and reduce the speed to 0.60 (60%) instead of 0.95. If you're going to test this, do it before you flash the new firmware so that the culprit can be discovered.

Considering how much work you've done on this already, you might want to post this issue on klipper discourse.

I'll be adding this issue to the Special Considerations section.

[lincolnjohnson]

The part is a prototype so I can't share it, but if you match the part size and position in your slicer I think you should get the same result. I'm using prusaslicer, though I don't have any reason to believe that that would matter.

Flashing new firmware is a pain as I presently only have Sovol-issued SD cards and I've never managed to get one of those to flash klipper - I've wasted something over 12 hours cumulatively trying to make that happen in the past. So that's not happening in the very short term.

I don't believe that speed is a factor, as I tried manually testing a number of G1 commands and speed didn't affect it. I believe I tested F100 and F1500 and probably F6000, though I didn't take notes while I was prodding at it.

The consistent factors are:

• a present X position of -0.00 after KAMP probing
• a commanded G1 move to X0

Y position and speed didn't affect it in my testing, though I suspect if it were possible to end up at 0 on the Y axis after KAMP probing that we could trigger the same thing.

Considering that we're trying to move from a reported position of -0.000 to X0, which is interpreted as -0.000, I'd be willing to bet that the culprit is a floating point math error, which could possibly be captured and mitigated in the cmd_G1 function or perhaps in the toolhead move function.

[lincolnjohnson]

I think this may be related to the note for 20210819 and this github issue from 2018.

Changing position_min on the X axis to -0.01 also resolves the issue.

[mratomicbomb]

I experienced the same issue as you, out of bounds error at X=-0.00 when the mesh completes. I was printing a first layer test, seems to be limited to large models when the toolpath during the KAMP mesh approaches the edge of the range.

Disabling KAMP fixes the issues, but I also noticed changing the mesh size affects the error. Odd square (7x7, 9x9), no error. Error only seems to happen for me on even grid sizes (6x6, 8x8). So maybe it depends on which side of the bed the extruder ends up on after the mesh completes?

Also I came across this thread seemingly trying to solve the same problem: https://www.reddit.com/r/crealityk1/comments/17ka5qg/fix_for_kamp_out_of_range_error/

[lincolnjohnson]

So maybe it depends on which side of the bed the extruder ends up on after the mesh completes?

That would make sense - if you're on the right side of the bed, you aren't going to end up below 0.

I recently saw another instance - not KAMP related - of someone getting an error with a commanded position just below zero, they fixed it by setting their minimum to -1.

I bet if you used an odd sized mesh and a KAMP grid that should put you on the right side, along with changing your G1 / X home position to XMax, you'd get the same error.

An ugly hack to mitigate this could look something like:

if (commanded_position < axis_min):
    if commanded_position > (axis_min - 0.0001):
        commanded_position = axis_min
elif (commanded_position > axis_max):
    if commanded_position < (axis_max + 0.0001):
        commanded_position = axis_max

The above assumes your maximum positional accuracy is something like 0.001. A slightly more elegant version might be based on the distance your system can travel in a single step or microstep. I'd probably drop that post-processor immediately before the "final" movement command generator/position system, which might be in the toolhead move function.