Frix-x / klippain

Generic Klipper configuration for 3D printers
GNU General Public License v3.0
901 stars 234 forks source link

Please implement conditional QGL #214

Closed rugolini closed 11 months ago

rugolini commented 1 year ago

Loving Klippain. But I'm still playing with the start sequence to have it right to my needs. I usually print repeated sets and have no need to QGL every time. Can you please add a variable "conditional_QGL" that allows the macro check if QGL is done and bypass it?

Surion79 commented 1 year ago

Isn't this already available with force_homing_in_start_print set to false?

rugolini commented 1 year ago

Hum.... good point. Maybe its not clear, at least for me, that this option is also for QGL... could not find it in the documentation or in the variables file as well.

rugolini commented 1 year ago

I just confirmed... it execute the QGL with the force_homing_in_start=false.

Surion79 commented 1 year ago

Can you identify at which point? Have you set the variable to not turn off motors at print end?

rugolini commented 1 year ago

Yes... its variable_disable_motors_in_end_print: False

Surion79 commented 1 year ago

What about my first question? :)

rugolini commented 1 year ago

"Can you identify at which point?" ... here it goes the console output for the 2nd print: 10:19 AM File selected 10:19 AM echo: Material 'ABS' is used 10:19 AM pressure_advance: 0.040000 pressure_advance_smooth_time: 0.040000 10:19 AM echo: Heating up bed... 10:23 AM echo: Heatsoak bed, 1mn left... 10:23 AM echo: Bed temperature OK 10:37 AM echo: Chamber temperature OK ! 10:37 AM echo: Nozzle cleaning... 10:38 AM Quad gantry leveling <=========

Surion79 commented 1 year ago

Do you have any output after the qgl line? Just one more line would most likely suffice

Frix-x commented 1 year ago

Currently there is no way to get "conditional QGL" in Klippain as it's not a really good practice. In fact bed corners are where the bed deflect the more due to temperature change and that will lead to different QGL positions as the machine is heating up (prints after prints).

However, if this is a thing wanted by the community, as I already have the conditional homing (less a problem since we always measure the Z offset before a print, it's only the first homing that is skipped), I see no reasons to block the addition of a variable to do a Force QGL like the Force homing and set this to true by default.

rugolini commented 1 year ago

Thanks Frix. Yeah, I think its important to have choice, after all each Voron is unique (examples: Kynematic vs standard mount, bed plate quality, Y backers, PLA vs ABS printing temperatures, etc.). Sorry, but I'm confused with your message: "as I already have the conditional homing .. I see no reason to add a variable to do a Force QGL" ... I think you meant "I see no reason to NOT add a variable, right"?

Frix-x commented 1 year ago

Sorry, but I'm confused with your message: "as I already have the conditional homing .. I see no reason to add a variable to do a Force QGL" ... I think you meant "I see no reason to NOT add a variable, right"?

Yeah sorry, I wrote it too fast without reading me back. I edited my message. Simple answer: let's add a conditionnal QGL as a possibility.

Frix-x commented 1 year ago

Ok, I'm back to this subject and looking more in details it seems that there is indeed a conditional QGL already implemented and also using the force_homing_in_start_print variable. I've done that long time ago and was not remembering doing it haha. See here:

https://github.com/Frix-x/klippain/blob/52632ec5cd482282c1319fd6d01a7499305d2a1e/macros/base/start_print.cfg#L264-L265

I just confirmed... it execute the QGL with the force_homing_in_start=false.

I think your mistake was to use false all in lower case as this is read as "true" by the Jinja interpreter. The correct way is variable_force_homing_in_start_print: False (note the uppercase F letter and the use of : instead of an equal sign).

I do confirm that there is already some documentation about it, but it could not be clear and I could modify it if needed (as that it can be done only if the motors were not shut off and that the machine is already homed or QGL was already done at least once after the homing). See here: https://github.com/Frix-x/klippain/blob/52632ec5cd482282c1319fd6d01a7499305d2a1e/user_templates/variables.cfg#L37-L38

rugolini commented 1 year ago

In my variables.cfg I read:

Force always a full homing and QGL/Z_TILT during the START_PRINT macro

variable_force_homing_in_start_print: False

Capital "F" and ":", not equal.

Frix-x commented 1 year ago

Ok, so this should work (ie conditionnal QGL when called during the START_PRINT routine) if the QGL is already applied and motors are not shutted down in between.

If it's not the case, I'll try to see and replicate it as it's very likely a bug

rugolini commented 1 year ago

I re-tested, no motor shutdown between prints and it re-do QGL (not full home).

Regards!

Frix-x commented 1 year ago

Hi, I tried to work on this subject but I can't reproduce: everything is working as it should and the QGL is indeed avoided when the conditions are met. Can you try again one last time on the last version of Klippain with:

Then start a print, let it finish. The motors should continue running and be able to move without a home. If you start a new print, it should avoid the home and QGL

emericklaw commented 1 year ago

I have been battling this and it appears to be down to how the FORCE parameter is handled. Most likely because parameters are treated as strings.

if FORCE_OPERATION vs if FORCE_OPERATION|lower == 'true'

Using the below macro which takes relevant parts from the _TILT_CALIBRATE macro I did some tests.

[gcode_macro _TILT_CALIBRATE_TEST]
gcode:
    {% set FORCE_OPERATION = params.FORCE|default(true) %}

    RESPOND MSG="==================================================="
    RESPOND MSG="= ORIGINAL"
    RESPOND MSG="==================================================="
    {% if printer.quad_gantry_level.applied|lower == 'false' or FORCE_OPERATION %}
        RESPOND MSG="Variable - FORCE_OPERATION = { FORCE_OPERATION }"
        {% if FORCE_OPERATION %}
            RESPOND MSG="Force is true"
        {% endif %}

        RESPOND MSG="Variable - printer.quad_gantry_level.applied|lower = { printer.quad_gantry_level.applied|lower }"
        {% if printer.quad_gantry_level.applied|lower == 'false' %}
            RESPOND MSG="qgl.applied is false"
        {% endif %}
    {% endif %}

    RESPOND MSG="==================================================="
    RESPOND MSG="= MODIFIED"
    RESPOND MSG="==================================================="
    {% if printer.quad_gantry_level.applied|lower == 'false' or FORCE_OPERATION|lower == 'true' %}
        RESPOND MSG="Variable - FORCE_OPERATION = { FORCE_OPERATION|lower }"
        {% if FORCE_OPERATION|lower == 'true' %}
            RESPOND MSG="Force is true"
        {% endif %}

        RESPOND MSG="Variable - printer.quad_gantry_level.applied|lower = { printer.quad_gantry_level.applied|lower }"
        {% if printer.quad_gantry_level.applied|lower == 'false' %}
            RESPOND MSG="qgl.applied is false"
        {% endif %}
    {% endif %}

First I ran the macro with no parameters straight after a klipper restart. The FORCE parameter is evaluating as true.

00:03 _TILT_CALIBRATE_TEST FORCE=False
00:03 echo: ===================================================
00:03 echo: = ORIGINAL
00:03 echo: ===================================================
00:03 echo: Variable - FORCE_OPERATION = False
00:03 echo: Force is true
00:03 echo: Variable - printer.quad_gantry_level.applied|lower = false
00:03 echo: qgl.applied is false
00:03 echo: ===================================================
00:03 echo: = MODIFIED
00:03 echo: ===================================================
00:03 echo: Variable - FORCE_OPERATION = false
00:03 echo: Variable - printer.quad_gantry_level.applied|lower = false
00:03 echo: qgl.applied is false

I now ran a QGL and ran the test macro. The original code thinks FORCE is true while the modified code does not get run.

00:08 _TILT_CALIBRATE_TEST FORCE=False
00:08 echo: ===================================================
00:08 echo: = ORIGINAL
00:08 echo: ===================================================
00:08 echo: Variable - FORCE_OPERATION = False
00:08 echo: Force is true
00:08 echo: Variable - printer.quad_gantry_level.applied|lower = true
00:08 echo: ===================================================
00:08 echo: = MODIFIED
00:08 echo: ===================================================

While testing this I also discovered that the _TILT_CALIBRATION macro uses verbose but does not include: {% set verbose = printer["gcode_macro _USER_VARIABLES"].verbose %}

Frix-x commented 1 year ago

Thank you very much for finding the issue. I've finally managed to work on this and pushed a fix (e37ce23a23c9329f05f3bf34cbd56df5ef14d184) that will be included in the next release :)