Frix-x
Update start_print.cfg with FORCE_MESH
Can you elaborate the use case? Actually it is missing something. 1. I don't see the variable in variables.cfg. 2. is it an option for start_print as parameter within the slicer? That would be missing too
Can you elaborate the use case? Actually it is missing something. 1. I don't see the variable in variables.cfg. 2. is it an option for start_print as parameter within the slicer? That would be missing too
I think he must add {% set force_mesh = params.FORCE_MESH|default(False) %} in the param from the slicer?
He remarks an unknown user variable. So not sure of the integration. It would mean defaulting to the variable and not to a hard coded default.
?
{% set force_mesh = params.FORCE_MESH|default(False) %} in the param from the slicer? Is just set to a default variable?
?
{% set force_mesh = params.FORCE_MESH|default(False) %} in the param from the slicer? Is just set to a default variable?
no, that is setting to a default (hard coded) VALUE. not a default variable. Default variable is declared in his PR, but I was either blind or the variable is not available in variables.cfg
You are correct I didn't put it into variables.cfg. This PR is to give the user the option to force a bed mesh. Most of the code was already there it just defaulted to False and never actually read from the variables.cfg file (User variables) or gave the end user a way to enable it.
I will update with a default variables_force_mesh: False in variables.cfg
i would also like to have it as parameter in start_print available, if we are already integrating it
i would also like to have it as parameter in start_print available, if we are already integrating it
So that you could enable from the slicer?
yes. you can look the start_print macro with PARAMS. and adapt it accordingly for bed mesh. I expect some integration since the bed mesh module which is a starting module was modified.
I don't really see the real point of adding another user variable with all the problems that can cause (when upgrading Klippain) for a function that has limited interest. Why make a bed mesh when the printed part is very small? So in my opinion it could remain something marginal that the user would be able to pass into their slicer start g_code and which would be used here .
And in this case I don't see how replacing {% set force_mesh = printer["gcode_macro _USER_VARIABLES"].force_mesh %} by {% set force_mesh = params.FORCE_MESH|default(False) %} could cause a problem.
Finally, in the event that you absolutely want to add the new user variable entry in variables.cfg the description can easily lead to confusion: the way it is worded can make you think that there will be no bed mesh if you leave it on False...
the whole thing makes no sense since the addition is in the bed_mesh_module within the start print sequence. you either need to pass it through start_print params or through variables. if neither is done, the addition is plain never in use. Please look at the change. it is NOT done in the START_PRINT macro.
i took the liberty to correct it directly. Should be fine now, since it is 100% matching Module coding
i took the liberty to correct it directly. Should be fine now, since it is 100% matching Module coding
It seems perfect for me...
@Surion79 @Frix-x : Just for my knowledge... is there a difference if we use False instead of 0 as the default value in this case?
i took the liberty to correct it directly. Should be fine now, since it is 100% matching Module coding
It seems perfect for me... @Surion79 @Frix-x : Just for my knowledge... is there a difference if we use
Falseinstead of0as the default value in this case?
i made it int, 0/1 as frix stated it in an above comment
i took the liberty to correct it directly. Should be fine now, since it is 100% matching Module coding
It seems perfect for me... @Surion79 @Frix-x : Just for my knowledge... is there a difference if we use
Falseinstead of0as the default value in this case?i made it int, 0/1 as frix stated it in an above comment
Because in https://github.com/Frix-x/klippain/blob/a20763997ef134cb24b401cb071eac245126f724/macros/calibration/adaptive_bed_mesh.cfg#L67 it seems to be a boolean...
And maybe take the opportunity to include this function in configuration.md... https://github.com/Frix-x/klippain/blob/e1a6cba3f009e8248b473754599ea1ad2f7bf8c1/docs/configuration.md
i took the liberty to correct it directly. Should be fine now, since it is 100% matching Module coding
It seems perfect for me... @Surion79 @Frix-x : Just for my knowledge... is there a difference if we use
Falseinstead of0as the default value in this case?i made it int, 0/1 as frix stated it in an above comment
Because in
https://github.com/Frix-x/klippain/blob/a20763997ef134cb24b401cb071eac245126f724/macros/calibration/adaptive_bed_mesh.cfg#L67
it seems to be a boolean...
could you please comment the line directly in the PR? I don't see it in the current version of the PR
i took the liberty to correct it directly. Should be fine now, since it is 100% matching Module coding
It seems perfect for me... @Surion79 @Frix-x : Just for my knowledge... is there a difference if we use
Falseinstead of0as the default value in this case?i made it int, 0/1 as frix stated it in an above comment
Because in https://github.com/Frix-x/klippain/blob/a20763997ef134cb24b401cb071eac245126f724/macros/calibration/adaptive_bed_mesh.cfg#L67
it seems to be a boolean...
could you please comment the line directly in the PR? I don't see it in the current version of the PR
I don't see how to do this on mobile app... it's in macros/calibration/adaptive_bed_mesh.cfg -> Ligne67
oooh, you mean outside this PR. Silly me :D
@Frix-x regarding your statement of force_mesh being 0/1 and in bed mesh it was programmed true/false. Which way to go? Stay int, go boolean or switch from int to bool?
Ok, so now the PR is ready to be merged. I just want to test it thoroughly to make sure it's working before I merge it. So please give me some time to do that (currently batch printing Christmas decorations haha)
