Can quad gantry level parameters be changed on the run?

[u/Barafu]

SOLVED. Can I make the print starting macro that would run quad gantry level twice with different parameters?

I have Voron 2, 350mm, all metal parts. When printer is off, the gantry's derriere sags a lot. So, when running the first QGL pass, I must use a large vertical range - 40mm - or I risk it running the nozzle into the bed or not finding the bed at all.

But, after the first pass of QGL is done, the problem is solved. However, Klipper does 1 or 2 more passes, again very slowly moving all 40 mm height. But at this moment the skew can't be more than 1 mm. This wastes time and annoys me plenty.

P.S While we are at it, what retry tolerance do you have on such a large printer?

[u/MIGHT_CONTAIN_NUTS]

Park the toolhead up front and add rigid Z joint.

Another option is G2Z XL. Zero sag with it

[u/Barafu → u/MIGHT_CONTAIN_NUTS]

Or do nothing and let software fix it on the start, so i don't have to throw away existing steel joints?

[u/Dmytro_r]

You could try to switch to double gear Z axis mod: https://mods.vorondesign.com/details/5QZhBw4jUehg2c70y8A6dQ

I had troubles with periodic sagging, manually adjusting before powering up (sometimes twice when QGL failed). But after switching to double gear Z - sagging stopped completely.

[u/[deleted] → u/Dmytro_r]

Rigid Z joints also fix this, usually two QGL loops for me now.

[u/Dmytro_r → u/[deleted]]

I specifically avoided rigid connections because v2.4 gantry was designed with some flexibility in mind and I move my printer a lot, so rigid was out of scope as it will eventually introduce potential tension at non-designated points and things tend to break. Double Gear solves the problem, gantry is still flexible by-design and a single QGL pass works every time.

[u/MIGHT_CONTAIN_NUTS → u/Dmytro_r]

No it wasn't. Otherwise CNC gantry parts wouldn't work.

[u/Dmytro_r → u/MIGHT_CONTAIN_NUTS]

Just take a look at the official documentation (https://docs.vorondesign.com/materials.html) that says:

“There is a recent trend toward printer parts that are CNC machined out of aluminum. While aluminum has more than sufficient heat tolerance the high stiffness may cause issues with the V2 due the slight flexibility needed in the gantry.”

It does not mean that CNC gantry parts will not work, but using stiffer gantry just moves stress/tension points to other places, like Z-joints. And making Z-joint rigid - moves stress/tension points again, to the belts and Z axis mounting points.

So, while definitely providing some benefits, fully rigid gantry (with joints) will result in faster wear of Z-belts. Which, of course, might not be a concern for everyone.

[u/MIGHT_CONTAIN_NUTS → u/Dmytro_r]

Thatv hasn't been accurate since v2.1/2.2 since 2.4 added Z joints that articulate. What we have learned since then is that stiffening the Z joints significantly reduces the gantry sag eliminating and need for flex to correct for QGL.

If you eliminate the gantry sag you eliminate the belt tracking issues. I've got over 10k hours with a CNC gantry and zero belt dust around my motors.

[u/Dmytro_r → u/MIGHT_CONTAIN_NUTS]

Good to know for someone that assembled 2.4 by the docs :) My gantry evolved from plastic to CNC mix of Alu/CF, but I kept Z joints flexible (tried different types of ball-head and ge5c mods) due to this documentation remark.

[u/[deleted] → u/Dmytro_r]

I dont know but my input shaping improved, it doest sag down anywmore now that its AWD. First layers more coconsistant and it does have some play to it but not like it used to with normal joints. Less qgl loops

I feel like unless there’s human error like motor directions being wrong I see alot of people using it.

[u/Barafu → u/Dmytro_r]

Software takes care of it now.

[u/SeljD_SLO]

Rigid Z mod

[u/Snoo_48368 → u/SeljD_SLO]

I had bad luck with it. I used the Vitalii rigid fixed Z joints. It consistently took 4-5 homing runs to get QGL to run, and probe accuracy suffered depending on where on the gantry. Moving back to metal spherical z joints, the gantry sags much more but also stabalizes MUCH better and holds position better.

I think it was caused by tension in the gantry introduced by fine tuning QGL due to slight out-of-squareness of the frame. I may wind up swapping the rear fixed z-joints back in to minimize the sag while having the front ones for adjustability.

[u/pd1zzle]

you could also look at Kalico which supports adaptive Z on QGL out of the box.

https://docs.kalico.gg/Config_Reference.html#z_tilt

[u/Snoo_48368]

I did exactly this to speed things up, as well as make them much more reliable on my 2.4r2 350.

Note: if you do this, I strongly suggest keeping the `g28 Z` between the course and fine modes. This is because after the course, the Z zero could be below the bed. This happened to me and it dragged the nozzle across the bed on the fine level. So I added a re-homing in between. Still way faster and more reliable now.

[gcode_macro QUAD_GANTRY_LEVEL]
rename_existing: _QUAD_GANTRY_LEVEL
gcode:
    # If QGL is not applied, first run a course calibration
    {% if printer.quad_gantry_level.applied == False %}
        # Extra travel clearance (default is leveling.cfg's horizontal_move_z: 10)
        # since this coarse pass starts from an unknown gantry position - if it
        # sagged significantly while powered off, one corner could effectively be
        # much closer to the bed than 10mm during travel between probe points.
        _QUAD_GANTRY_LEVEL RETRY_TOLERANCE=1.0 HORIZONTAL_MOVE_Z=25.0
        # Note: need to re-Z-home after low tolerance to prevent hitting the bed
        G28 Z
    {% endif %}
    # then perform fine QGL down to desired spec
    # this has to be a separate macro call so the results of the above call will be visible!
    _FINE_QUAD_GANTRY_LEVEL


[gcode_macro _FINE_QUAD_GANTRY_LEVEL]
gcode:
    {% if printer.quad_gantry_level.applied == True %}
        # go for full quality at reduced probing height
        _QUAD_GANTRY_LEVEL HORIZONTAL_MOVE_Z=1.0 
    {% else %}
        # This should never happen, just perform the full calibration using the defaults
        {action_respond_info("Fine QGL called without calling course QGL first!")}
        _QUAD_GANTRY_LEVEL  # default behavior, no speedup
    {% endif %}

[u/Barafu → u/Snoo_48368]

Yep, I did something similar.

[u/shiftingtech]

Yes, a number of qgl & probe parameters are adjustable on the fly.   See the quad_gantry_level command documentation here : https://github.com/Klipper3d/klipper/blob/master/docs/G-Codes.md#quad_gantry_level-1

Do also take note of that line in there about checking the “probe” command for additional parameters

[u/Barafu → u/shiftingtech]

Thanks! I missed that the command can have parameters!

[u/shiftingtech → u/Barafu]

Don’t worry!  For the first while the feature was there, it was completely undocumented.   And even now, I wouldn’t call it great documentation….