Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue: My printer always moves head closer to bed by some mm before homing x. I’m not sure at this point if it’s a klipper issue or a prusaslicer issue. I’m hoping somebody can take a look at my logs and my gcode and sort out what’s going on here. The part I uploaded had that problem.
I highly recommend getting the code out of the slicer and into macros. If you had your “Machine End g-code” as a macro instead of embedded in the slicer, you could simply make the change I’m about to tell you and any future parts you print would follow the new code. Instead, you’re going to have to make the adjustment in your slicer and then re-slice. It’s not too late to copy all of your end code to a macro and then delete it from the slicer, replacing it with the name of the macro, most likely END_PRINT … but I do recommend starting by finding the examples codes and copying them, then copying the code block from the slicer into the example macro. It’s not necessary, just more convenient for making changes in the future. Anyway … Moving on to what the problem actually is:
It’s not your homing that’s the issue, so testing the homing isn’t going to help. It’s a code your slicer added at the very end of the print. I had this happen to me to when I was first setting up my END_PRINT macro and wasn’t entirely sure what I was doing, so I recognized it immediately from your description. In your end code there is a line that says “G1 Z5 F5000 ; lift nozzle” … except it’s actually NOT lifting the nozzle. It’s trying to move to (absolute value) Z5, because the part was printing using absolute movement settings and when the part ended nothing switched it into relative movement. You need to put a “G91 ; set movement to relative” (the comment is not needed, but I like to add it to keep everything organized) before the “G1 Z5” so it will actually move the Z axis +5mm (relative) from wherever it currently is when the part finishes, instead of trying to go to (absolute) Z5. G90 will put it back to absolute movement, but you don’t need it in this case because the G28 X will override it anyway.
Not part of the problem, but is there a reason you do not also move the Y, either to the maximum value if you have a bed-slinger or to the minimum value (aka home) if you have the kind that the gantry itself moves in the Y? It’s not truly necessary, but I find it convenient.
I thought I mentioned why immediately after suggesting it. OP needs to make a very minor change of adding a single line … and then re-slice every gcode he has that he plans to continue to use in the future. And then if he ever has to make another change, he’ll have to re-slice literally everything all over again. Believe it or not, there are people who print the same file more than once. If it was in a macro instead of the slicer, he could just make the change in the macro, and then the already-sliced file will call the macro without needing to be re-sliced for every little change. But it’s only a recommendation, you can take it or leave it as you wish.
As for the “advantage” of being able to cancel it … are you trying to say you can’t hit the Pause button in the middle of a macro? I haven’t had that problem, but maybe I just got lucky on my timing. I mean, how often are you in the middle of an end-of-print script and needing to cancel it?
I would consider it bad practice to create a macro to compensate for a problem with the gcode for two reasons:
@jonawald would have to keep track of when to execute the macro and when not to, adding a layer of complexity and the chance for a defective print.
Macros will become problematic if they are added willy-nilly to a system. People forget why they’re there and they may not work when transferring to another system.
I don’t know how long you’ve been here but often somebody will come in with a problem in their system, which is loaded with many macros, only to discover that when they remove the macros (for which they had no good reason for installing in the first place or haven’t been maintaining) everything runs fine.
Regardless, I would challenge the assertion that .gcode files are heirlooms, to be kept forever in their current state. I gave up on that idea years ago and instead keep the .stl and slice as needed, taking advantage of my latest settings as well as allowing me to select which printer I want to use (even if you have only two, this will be a consideration).
Finally, as @EddyMI3D indicated, a macro cannot be paused during execution - the only way to stop it is to hit the “Emergency Stop” button in the front end or KlipperScreen. For this reason, you should NEVER use a macro as a .gcode wrapper.
When I first started working as an engineer, on a large manufacturing test system which involved hardware and software, the hardware designers would often joke that if there was a problem in hardware, it could be compensated for in software. It was a joke because hardware problems could never be successful masked by software. Suggesting fixing the .gcode issue with a macro, smacks of this, largely imperfect, approach.
So the working workaround I’ve come up with is this in my custom Gcode.
G91; switch to relative mode
G1 Z5 F5000 ; lift nozzle
G90; switch to absolute mode
G1 X10 y10 F5000; get nozzle out of the way
M104 S0 ; turn off temperature
G28 X0 ; home X axis
M84 ; disable motors
Seems silly to have to do that. Can anybody figure out why this is happening?
With this gcode, the head moves to X10, Y10 then bed raises to Z25 before homing X. It works. I finally get a print without a dent or broken top.
I admit I don’t know everything, I’ve more or less been teaching myself over the past several months. Perhaps some of the things that I’ve picked up along the way from what I’ve seen other people discussing (like the END_PRINT macro) have been wrong this whole time. So you might want to have somebody else double check what I’m about to say before you begin making any changes.
So, here’s what I’m seeing in your log file. Your “safe_z” variable is getting set to 25 when the machine starts up. Later, there’s a “homing_override” macro which controls how a home works. When you tell it to home an axis (in this case, the “G28 X0” line at the end of the part), the “homing_override” macro is trying to tell it to make sure Z is safe first, by double checking the safe_z variable is set and then a “G0 Z{safe_z}” command. But it somehow never put in a line, which right now I can’t tell you the exact formatting, that says if the current Z is higher than “safe_z” but at least 5 less than the maximum Z, then set “safe_z” to current z + 5. That line, or more accurately probably 3 lines (it’ll need an if and endif), will need to be added to the “homing_override” for each type of home it does that calls the “safe_z” variable.
@BlaiddGwyn is right.
The unwanted behavior is somewhere hidden in the extensive macros and the easiest thing would be to contact the original author of them.
So here’s the code I have in my END_PRINT macro… there’s a section at the beginning (after the “gcode” line) that says “#### set definitions ####” followed by some other stuff, but this is the part you need. As far as I can tell, you can add it once to the beginning of the “homing_override” macro.
{% set max_z = printer.toolhead.axis_maximum.z|float %}
{% set act_z = printer.toolhead.position.z|float %}
{% if act_z < (max_z - 5.0) %}
{% set safe_z = 5.0 %}
{% else %}
{% set safe_z = max_z - act_z %}
{% endif %}
Then make sure when it’s calling “G0 Z{safe_z}” it’s doing so in relative mode (G91 somewhere before that line). This will basically tell it “if you’re more than 5mm away from maximum, move up 5mm, else move up to maximum”. This will ignore the safe_z=10 from the variables declaration at the beginning, while leaving it intact for other macros to still call if needed. Or you could even swap it out, maybe use “z_safe_lift” instead in this code block, and only this code block, remembering to also change it in the other spots in your homing_override macro.
But again, I’m still learning, so please make sure either you understand what the codes do or have somebody else inspect it before you start adding it and/or making changes to your macros.
It mentions things like “attachmove_x” that are specific to the Klicky Probe stuff, so I imagine it’s somewhere in the cfg files for that. The name of the macro is “[homing_override]” so you could probably just press CTRL-F and type that (without the quotes) in the search box to find it once you have the correct cfg file open.
variable_home_backoff_x: 10 # how many mm to move away from the X endstop after homing X
# this is useful for the voron v0 to enable the toolhead to move out of the way to allow an unstricted Y homing
variable_home_backoff_y: 10 # how many mm to move away from the Y endstop after homing Y
variable_override_homing: '' # configures what axis to home first
# '' = default klicky behavior (tries to avoid the hitting the dock)
# 'X' = forces X to home first
# 'Y' = forces Y to home first
This is my code. in homing override section. Does not make sense in relation to what you are telling me.