_RET_CALI_START Z-Offset

[rssw]

It appears that using the retraction site with this as the start g-code doesn't apply the Z Endstop Offset correctly. Normal prints work as expected, but these retraction prints print 0.5mm below my actual bed, damaging the surface. The gcode starts at z=0.2 as expected, so i'm expecting that the endstop position is not applied.

[3DPrintDemon]

Hi. I’m sorry you experienced that. However there’s no command in the retraction calibration start code that modifies the starting Z position of the test print at all, especially in a negative direction of that amount.

Even if that amount was set by the user to be auto applied the system in the macros would not allow that, any auto offset request of that amount would cause an error & an emergency stop.

The only thing the macro does is to level the printer, mesh the bed or load a default mesh profile if adaptive meshing is turned off. Then print a purge line & then start the test all at the normal & unmodified Z offset.

There is no auto Z offset adjustment applied anywhere.

I used this exact macro at least 2-3 times about a week or so ago without any issue when calibrating a new steel nozzle on a machine here.

However I will test it again on my system here for you to double check for any issue. In the meantime I have added an offset reset & bed mesh clear command to the very beginning of the macro to help not have any issue with any previously used/active settings.

Also please note the warning on the retraction calibration website. Just incase that was the problem.

[rssw]

Appreciate you looking into this. It didn't damage my bed at first, it was just really pressed up against it, and then I applied a Z offset in a panic and went the wrong way... So now there is a section in my bed without PEI. Aaarggh! My own stupid fault.

I did look at the macro, and also couldn't figure out where the offset should go. But I'm no expert in these macro's, hence me coming to the master. ;-) I copied your macro and added:

 ...
 {% if start_vars.neopixel_led == True %}
   STATUS_PRINTING
 {% endif %}

 # MINE Adjust offset to prevent scraping the bed
 SET_GCODE_OFFSET Z_ADJUST=0.518

 M117 Start Position
 ...

This works nicely. That Z_Adjust value is from

 [stepper_z]
 position_endstop = -0.518 # My endstop is 0.518mm below the bed surface

I just applied offset in the correct direction until it printed properly, and I arrived at 0.5mm. It could just be coincidence that the amount of offset I need to print properly is the same as the z-offset, but it seems unlikely.

Maybe your endstop is much closer to the bed height and you didn't notice if it's not applied?

It's just that normally sliced prints work perfectly, but this doesn't. Anyway, hope we can find a solution, maybe it saves someone's bed in future. Appreciate your time!

[3DPrintDemon]

Ahh ok. Yeah going the wrong way when panicked is always a risk. It’s normally far better to simply hit the emergency stop button in a situation like that.

I’m really not sure why your machine thinks z0.0 is 0.5mm below your bed surface. It really shouldn’t be.

Positions of z endstops is not really an issue here as the printer sets z0 when it homes the z axis. Same on your machine or mine. So this won’t be the problem.

The only thing I can think of is that maybe your machine isn’t loading a correct bed mesh or isn’t probing the bed or something, & it’s using the old legacy static purge line system or something.

For that system a correct & loaded mesh is vital. I’d recommend using the adaptive mesh & purge systems. Then you’ll get a fresh mesh & purge line set to it.

Good you got a workaround for your system though there for now.

I’ll have a look at the macro again to see what I can find.

[rssw]

Interesting. The Z endstop is 0.5mm below my bed because that's where the pin is that the voron homes to. So it needs to apply that configured offset after homing so that z=0.0 is the bed surface. But maybe we're just saying the same thing. Most Z endstops will have such an offset, except perhaps that tap?

But maybe what you're saying is that G28/G29 will apply that offset after homing as a built-in function, and since this macro calls that function, the offset should be applied. Yes, correct, which is where I got to while searching for the problem. However, the fact that using the normal start macro works when printing all normal prints, while printing the retraction has very different results, tells me that something somewhere is not the same. And I have no idea what.

In an effort to fix my hack, is there a way to reference my configured position_endstop value in the _RET_CALI_START macro? I've got it hardcoded at the moment, but eventually I'm going to update that position_enstop calibration and forget to come and fix this macro. I see that params is loaded at the start of the macro, but I'm not sure what the syntax is to find this value.

[3DPrintDemon]

Ok you have your Voron 2.4 switch below your bed height, that’s quite risky. The endstop pin is probably best to be above the bed height so as not to need to travel through the plane of the bed as it were to reach it.

Yes correct. The homing process should deal with applying any offset you have entered into the printer.cfg. Applying this offset during the homing process is 100% controlled by Klipper itself. My macros have nothing to do with that. They do not edit your switch endstop, they don’t alter it they do not change it in any way during either the normal print start macro or the calibration start one.

There is no command that can do that. Your endstop switch offset is your endstop switch offset period.

The calibration start macro doesn’t even apply any automatic g-code offset, which is a completely different thing btw to your z endstop switch offset which cannot be edited by a macro.

The only thing retraction calibration start macro will do now is reset your g-code offset & not your z endstop switch offset back to 0.0. Which it will be anyway tbh.

Also this 0.0 is NOT 0 but actually your stored offsets in your printer.cfg. So what that is doing is telling the printer to set your g-code offset to the stored value of your switch/probe offset.

Also it’s really odd you say normal printing works ok but this doesn’t as the commands called are the same & are used for both.

You shouldn’t need to edit the macro in this way as Klipper should know your offset & set it correctly. To me this points to a problem or conflict elsewhere in your machine &/or config.

I’d really recommend not having a z endstop switch below the surface of your print bed tbh. Especially if you’re using sensorless homing.

[rssw]

Makes sense. Something is not adding up. I'll make up a new pin and adjust the endstop slightly above the bed. My thinking originally was that I don't want the nozzle crashing into it, but I think that's unlikely, whereas the current setup has much more realistic hazards.

I'll do that and then print the retraction cube again without my modified macro and report back. If I'm printing in free air we can go back to troubleshooting.

[3DPrintDemon]

That’s probably a good plan tbh. I just tested the macro on my 2.4 with endstop switch, the probe/switch endstop height was found & set perfectly, I didn’t even have to Babystep the g-code offset.

I did modify it a bit & added some missing setup steps for bed fans & chamber heaters. I also added a M82 at the end to ensure the extruder is left in absolute mode ready for the calibration print.

[rssw]

You legend! As expected, with the end-stop above the bed, the print started in mid air. However, once I updated to the new macros (all of them), the print went down perfectly! I must have been the relative movement!

Thank you!! ;-)))

[3DPrintDemon]

Hi, that’s fantastic I’m glad that all worked out for you in the end. The added movement command was the extrusion mode only (M82), as the axis movement remained set as absolute (G90), the same as it always has. Either way, great news it’s working for you!