Closed HitLuca closed 1 year ago
Actually, that last move is there only to make it easier to remove the print on bed slingers. It doesn't really make sense on corexy, etc. anyway.
How about I just put the printhead in the normal parking position, condition that final Y move on bed slinger kinematics, and stop 5mm shy of max?
I would do 10 (or better, configurable with 5 as default), your solution seems elegant :) In fact it works well on my other cartesian printer
I just physically tested out the positioning on a few printers and I think that for removing a print it's still preferable to always move the toolhead to the back (even if it's not a bed slinger). So, here's an alternative thought...
Looking at the config, I already have variable_print_max
, which sets the max printable bounds used for purge line layout (if unspecified it just defaults to the associated stepper's position_max
). So, I think I'll just use the Y coordinate from that, since it should account for the broader concern of printers where the kinematic limits may not accurately reflect the printable limits. And I'll look for other places in the code where I should be using printable limits in favor of kinematic limits.
I landed the change using print_max
in 8fded6d.
now the PARK
directive has become PARK Y={km.print_max[1]}
and the printer parks at max_y. This doesn't take into account a margin for sensorless homing tho
Yeah, I was suggesting you can just set the Y
coordinate in variable_print_max
to a value that has enough clearance, since it won't have any other practical effect and I'm a bit reticent to add another config variable for this case. However, after thinking about it for a bit I suppose I might as well just add one.
Okay, added a y parking position for PRINT_END
as variable_start_end_park_y
in 35fd436.
My Voron 0.2 uses sensorless homing, and for this to work the stepper needs to push the toolhead towards the frame until it touches it, resulting in the stepper driver understanding that it has reached its max position. The
PRINT_END
macro parks the toolhead at (park_x
,max_y
), which is fine if it wasn't for homing when a new print is triggered. The printer needs some buffer space when sensorless homing in order to "feel" the frame, but for y homing the toolhead is already at max_y, resulting in a audible bump into it. For now I just updated thePARK
macro call with{max_y - 10}
instead of{max_y}
, but it would be nice to be able to set the x and y positions for the final parking using a variable. the x parking position is fine, since one could define it inglobals.cfg