fast ridge
So, I did a bed level and calibration and everything was fine. I went to bed. I got up, homed the print head, did another height map just to be sure, and told it to print an object.
"Move out of range: 180.200 340.000 12.560 [10793.724]"
Now, it seems like the Z axis (and possibly the probe) are acting up, but I'm not sure what's going on.
I can run a height map just fine, it' just when I try to print that things suddenly start going wrong.
old sandBOT
Ahoi @fast ridge!
It looks like you did not provide all the necessary information we need to help you.
Please upload your logfiles and a detailed description of your problem.
For further information see: https://docs.mainsail.xyz/faq/getting-help/discord#provide-information
Note: We only accept .log and .txt files as log files.
This is an automated message
fast ridge
winter estuary
your config:
[stepper_x]
position_endstop = 0
position_max = 235
[stepper_y]
position_endstop = 0
position_max = 235
[stepper_z]
position_min = -5
position_max = 250
[bed_mesh]
speed = 120
mesh_min = 30,30
mesh_max = 189,189
[bltouch]
x_offset = -45.0
y_offset = -10.0
z_offset = 1.395
error log:
Move out of range: 180.200 340.000 12.560 [10804.724]
it will move to position X:180, Y:340 and Z:12,5
so your problem is Y and not Z. pls upload your gcode also. your config itself looks ok, but it could just be a wrong gcode in your start gcode which move your toolhead to this position.
fast ridge
...I didn't change that. how the hell did that get changed?
and I tried 3 different models, all of which printed on this particular machine before, with the same error.
winter estuary
pls upload your gcode also. your config itself looks ok, but it could just be a wrong gcode in your start gcode which move your toolhead to this position.
fast ridge
that doesn't make any sense.
I mean, I'll do it, but it doesn't make any sense. failure mode is literally "ran prints, shut down for the day, started up next day, everything stopped working. " It's a file I've printed on this machine, like... ten times, maybe more.
stand by.
fast ridge
nope. I just logged in(I leave it running) and said "ok, buddy, print the thing you've printed before, second verse, same as the first."
winter estuary
if you prints 2 prints without a restart, is differnt to the first print after reboot.
but without any gcode file, i will not help here any more. this discussion is useless...
fast ridge
you want the gcode? no problem. I don't see how it will help, but sure.
I printed it on 2/9/2026 at 8:20PM, CST. Printed complete. I pulled up the file from history and told it to print again on 2/11/2026 at 7:34 PM CST, without making any changes, and the print failed.
as a test, I attempted to print this file
Which printed fine about 3 months ago, and it failed as well.
winter estuary
these are the first lines of your gcode file:
M140 S60
M105
M190 S60
M104 S200
M105
M109 S200
M82 ;absolute extrusion mode
G28 ;Home
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
you just move your toolhead, but dont set relative or absolute. so if it homes with g28 at position 160,120 and then it moves the toolhead relative X+10.1 and Y+20 and then again X+10.1 and Y+200, this is exactly:
Move out of range: 180.200 340.000 12.560 [10793.724]
so just set to absolute mode, before move to an absolute position...
fast ridge
Ok, thats what happened. WHY did it happen?
because, too my knowledge, I didn't change anything. I just ran the gcode file. having the machine suddenly change behavior without input from me is kind of a big problem.
winter estuary
to be honest, if you write some gcodes (macros or just start/end gcodes in your slicer), to make sure he doesn't cause any troubles, add the gcode for absolute/relative gcodes. then your printer is always in the right mode
fast ridge
That's not helpful.
a printer that works on monday, and without changes from the operator suddenly doesn't work on friday... that's not a workable printer.
winter estuary
to be honest. without a change (update, slicer update or something else) this would not happen...
fast ridge
I tell you, to my knowledge, I changed nothing.
winter estuary
and i tell you, there is nothing in klipper, moonraker or mainsail, which change something alone...
fast ridge
eh, moot point, I had to replace the board, because the usb port was damaged, and I replaced it with a stock board for the time being.
And yet, this is the 3rd time in six months I've had this exact problem.
winter estuary
then you had this issue the whole time, just move the toolhead or something else, which change the mode before the print
your start gcode is just wrong, so its your fault to use a wrong config. so you just had some luck with successful prints
just fix your start gcode and your printer will work!
there is no discussion about this anymore...
fast ridge
So, just to be clear, a file that prints on identical hardware, using creality firmware, or marlin firmware, with no issue. That works fine either through loading it via sd card, or using something like octoprint... a file that works literally everywhere else... But the problem is 'oh, your gcode is broken. ' Ok. got it.
winter estuary
So, just to be clear, a file that prints on identical hardware, using creality f...
maybe marlin use absolute mode per default. or this is just set in the firmware.
your gcode is just "trash" and it could work, when your printer is in the right mode before you start this file. nothing else...
just luck, at the start when you press start