Move out of range

[SanderRave]

This is a stupid help request.

My Ender3 was running like a charm, tuning and playing around, getting myself acquainted with Klipper in my preparation to build a Voron. After updating OctoKlipper V0.3.2 to V0.3.3 I have this Move out of range: 9.293 -21.000 0.385 [29.300] issue at the beginning of my print that I didn't have before. Everything is well within the bed boundaries, and offsets are filed correctly.

Miscalculating? I am sure it's my miss, but I can't figure it out. Debugging my own s*t is what I take for granted, but I'm out of clues. Cura slicer setup, calibrating, Klipper config, what am I overlooking? I would highly appreciate a fresh look at this.

octoprint.log Config.cfg.txt

env.hardware.cores: 4 env.hardware.freq: 1500 env.hardware.ram: 4041732096 env.os.bits: 32 env.os.id: linux env.os.platform: linux2 env.plugins.pi_support.model: Raspberry Pi 4 Model B Rev 1.2 env.plugins.pi_support.octopi_version: 0.17.0 env.plugins.pi_support.throttle_state: 0x0 env.python.pip: 19.3.1 env.python.version: 2.7.16 env.python.virtualenv: true octoprint.safe_mode: false octoprint.version: 1.5.3 printer.firmware: Klipper

[thelastWallE]

I am only on mobil at the moment but you may look into this part of your config file. Make sure the commented lines are all on a separate line.

I will revisit the "parsercheck changes" that someone posted here to check the file before saving and reseting the firmware.

[thelastWallE]

ok seems like my line got auto-broken in the editor. It's actually a long comment.

[SanderRave]

True, it was broken up and commented out. Not sure how that would influence the outcome. I'm wondering what the value represents, at first I expected the Z offset was out of par, but the ranges are just to wide spread. About the parsecheck changes comment, I couldn't follow you there?

[thelastWallE]

I was seeing you had this also on the x axis before. I had this only once and this was because the bedsize was greater in the slicer than in the firmware. Would help to see the start of your gcode.

edit: The changes for paraercheck. would be these: https://github.com/thelastWallE/OctoprintKlipperPlugin/pull/14

[thelastWallE]

on which side of the extruder is your bltouch? if it is on the left side your x-offset should be in the negative.

[thelastWallE]

This is from my file. I have the probe on the right side of the extruder. I need to set the mesh min to 48 on X. If i would set it lower the extruder would try to move into the negative for probing and would throw an error.

[bltouch]
sensor_pin: ^PC14
control_pin: PA1
x_offset: 48
y_offset: -2
z_offset: 1.23
pin_move_time: 0.75
speed: 1.0
lift_speed: 3.0
samples: 2
sample_retract_dist: 3

mesh_min: 48,8
mesh_max: 200,230

[SanderRave]

Start G-code G29 ;BLTouch mesh generation

G92 E0 ;Reset Extruder G1 Z2.0 F3000 ;Move Z Axis up G1 X10.1 Y20 Z0.28 F5000.0 ;Move to start position G1 X10.1 Y200.0 Z0.28 F1500.0 E15 ;Draw the first line G1 X10.4 Y200.0 Z0.28 F5000.0 ;Move to side a little G1 X10.4 Y20 Z0.28 F1500.0 E30 ;Draw the second line G92 E0 ;Reset Extruder G1 Z2.0 F3000 ;Move Z Axis up

My Probe is on the right of my print head (x_offset: 39.5 y_offset: -1.5), so your comment makes sense. However I have to mention it worked fine before with this setup, with and without start code. I will change my bed x coordinates 0 to 40 something:

[bed_mesh] min_point: 0, 30 max_point: 165.5, 205

I'll report out after, this could well be the thing I was overlooking.

[SanderRave]

Here are some findings: Changing the bed mesh didn't

1. To be clear, before the start G-code didn't generate an error
2. Without the start G-code the printer generates no error
3. The error is generated at finishing the 2nd 'ooze' line

   Send: N15 G0 F9000 X9.293 Y-21 Z0.4*34
   Recv: !! Move out of range: 9.293 -21.000 0.443 [-0.700]

   Recv: !! Move out of range: 9.293 -21.000 0.450 [-1.400]

   Send: N25 G0 F9000 X9.293 Y-21 Z0.4*33
   Recv: !! Move out of range: 9.293 -21.000 0.385 [29.300]

   Send: N24 G0 F9000 X9.293 Y-21 Z0.4*32 Recv: !! Move out of range: 9.293 -21.000 0.375 [29.300]

   Send: N25 G0 F9000 X9.293 Y-21 Z0.4*33
   Recv: !! Move out of range: 9.293 -21.000 0.380 [58.600]

   Send: N25 G0 F9000 X9.293 Y-21 Z0.4*33 Recv: !! Move out of range: 9.293 -21.000 0.375 [29.300]

   After changing [bed mesh] to X=40 and drawing the line at X=40, still the same: 
   Send: N25 G0 F9000 X-28.499 Y-2.641 Z0.4*31
   Recv: !! Move out of range: -28.499 -2.641 0.330 [45.051]

   Send: N25 G0 F9000 X-28.499 Y-2.641 Z0.4*31 Recv: !! Move out of range: -28.499 -2.641 0.410 [58.600]

I can't get my head around the seemingly randomness of the 'range' between brackets. The rule of insanity is doing the same thing and expecting different outcomes. ...In this case it does, although my last outcome was 29.3 again, but based on different coordinates:

Send: N24 G0 F9000 X-28.499 Y-2.641 Z0.4*30
Recv: !! Move out of range: -28.499 -2.641 0.320 [29.300]

So, by now I know my work around, ditch the Start G-code. But I'm afraid sooner or later I will run into issues not knowing what changed and caused the issue.

[thelastWallE]

if you want, there is also the klippy.log file that you can post. should be on path /tmp/ Make sure to pick the one with the error in it.

[SanderRave]

Thanks a million! Seems I'm back on track identifying where the problem emerges from. Seems it's outside the klipper config. This weekend I will take the time and finish this bugger. Will keep you posted...

[SanderRave]

Hi Sven, Gone through a lot of tests, trial and error. It appears the error is generated in Cura, as in the Prusa slicer everything works flawlessly. Suppose it was me that broke something, I just have to figure out what it was. Thanks for all your support, and keep up the good work! Regards,