Notifications
Clear all

X-Axis Calibration - Minimum X is never 0  

  RSS
Rezer
(@rezer)
Member
X-Axis Calibration - Minimum X is never 0

I've been running this printer for a while, but I recently noticed some strangeness when I print a part near the X origin.  It seems that when calibrating the X axis, it keeps whatever value is in the firmware for X_MAX (255 by default), and adjusts X_MIN to fit whatever the dimensions of your X axis may be.  I'm running a BNBSX extruder, so the X axis is slightly shorter at 252.6mm, which doesn't bother me a bit.  The part that does bother me is due to the firmware adjusting X_MIN after running the calibration routine, the home point will always be X=2.4, and any attempt to move below that is ignored (rightfully, since the axis is physically unable to travel beyond the homing point).

This seems like a strange design choice, since there's no way to get PrusaSlicer to respect these bed dimensions.  I can input a bed of size 252.6 in printer settings, but the gcode that's output will range in X from 0 to 252.6, not 2.4 to 255.  Fiddling with the origin doesn't seem to help matters, since it just applies an offset to the X values emitted but there's no way to ensure the print area never includes anything below X=2.4.

So far it seems like the only way around this is to either start every print with a G92 X0 or just hardcode the reduced axis length in the firmware, but both seem to kind of defeat the purpose of calibration to begin with.  Anybody happen to know the reasoning behind calibration working this way?  It's pretty much the opposite of what most people would expect, I'd imagine.  Maybe I'm crazy?

This topic was modified 9 months ago 3 times by Rezer
Posted : 06/02/2024 12:00 am
Rezer
(@rezer)
Member
Topic starter answered:
RE: X-Axis Calibration - Minimum X is never 0

Whoops it's not letting me edit anymore...  Apparently I screwed up when I was testing the X offset settings in PrusaSlicer, cause setting negative 2.4 for the X offset does seem to work for the bed dimensions (at least going by a quick scan of the g-code that it spits out).  Better than sending extra G92 commands I suppose.

Still though, this behavior is a bit odd.

Posted : 06/02/2024 12:35 am
Share: