Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please implement conditional QGL #214

Closed
rugolini opened this issue May 26, 2023 · 18 comments
Closed

Please implement conditional QGL #214

rugolini opened this issue May 26, 2023 · 18 comments
Labels
bug Something isn't working done Issue is done but not merged on main next version This thing is already done or is planned in the next version in preparation

Comments

@rugolini
Copy link

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?

@Frix-x Frix-x added the enhancement New feature or request label May 27, 2023
@Surion79
Copy link
Collaborator

Surion79 commented May 28, 2023

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

@rugolini
Copy link
Author

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
Copy link
Author

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

@Surion79
Copy link
Collaborator

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

@rugolini
Copy link
Author

Yes... its variable_disable_motors_in_end_print: False

@Surion79
Copy link
Collaborator

What about my first question? :)

@rugolini
Copy link
Author

rugolini commented May 29, 2023

"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
Copy link
Collaborator

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

@Frix-x
Copy link
Owner

Frix-x commented May 30, 2023

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
Copy link
Author

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
Copy link
Owner

Frix-x commented May 31, 2023

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
Copy link
Owner

Frix-x commented Jun 5, 2023

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:

{% set force_homing_in_start_print = printer["gcode_macro _USER_VARIABLES"].force_homing_in_start_print %}
_TILT_CALIBRATE FORCE={force_homing_in_start_print}

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:

## Force always a full homing and QGL/Z_TILT during the START_PRINT macro
variable_force_homing_in_start_print: False

@Frix-x Frix-x added invalid This doesn't seem right Not an issue This is not an issue and removed enhancement New feature or request labels Jun 5, 2023
@rugolini
Copy link
Author

rugolini commented Jun 6, 2023

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
Copy link
Owner

Frix-x commented Jun 6, 2023

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
Copy link
Author

rugolini commented Jun 6, 2023

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

Regards!

@rugolini rugolini changed the title Please implement confitional QGL Please implement conditional QGL Jun 6, 2023
@Frix-x Frix-x added bug Something isn't working need to understand Bug look to be identified but more time need to be involved to understand and solve and removed invalid This doesn't seem right Not an issue This is not an issue labels Jun 8, 2023
@Frix-x
Copy link
Owner

Frix-x commented Jul 17, 2023

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:

  • variable_force_homing_in_start_print: False
  • variable_disable_motors_in_end_print: False

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
Copy link

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 Frix-x removed the need to understand Bug look to be identified but more time need to be involved to understand and solve label Oct 7, 2023
@Frix-x
Copy link
Owner

Frix-x commented Nov 6, 2023

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

@Frix-x Frix-x added the done Issue is done but not merged on main label Nov 6, 2023
@Frix-x Frix-x added the next version This thing is already done or is planned in the next version in preparation label Nov 8, 2023
@Frix-x Frix-x mentioned this issue Nov 17, 2023
@Frix-x Frix-x closed this as completed Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working done Issue is done but not merged on main next version This thing is already done or is planned in the next version in preparation
Projects
None yet
Development

No branches or pull requests

4 participants