Closed rugolini closed 11 months ago
Isn't this already available with force_homing_in_start_print
set to false
?
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.
I just confirmed... it execute the QGL with the force_homing_in_start=false.
Can you identify at which point? Have you set the variable to not turn off motors at print end?
Yes... its variable_disable_motors_in_end_print: False
What about my first question? :)
"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 <=========
Do you have any output after the qgl line? Just one more line would most likely suffice
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.
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"?
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.
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:
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
In my variables.cfg I read:
variable_force_homing_in_start_print: False
Capital "F" and ":", not equal.
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
I re-tested, no motor shutdown between prints and it re-do QGL (not full home).
Regards!
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
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 %}
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 :)
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?