3 replies

Jinja Parsing Order Prevents Overriding RatOS Variables?

Hey guys,

I have written a variable heat soak macro to allow setting the

[gcode_macro RatOS]
variable_bed_heat_soak_time:
variable_hotend_heat_soak_time:

[gcode_macro RatOS]
variable_bed_heat_soak_time:
variable_hotend_heat_soak_time:

values dynamically based on certain print stats.

However I am having an issue with trying to integrate this into the RatOS

START_PRINT

START_PRINT

routine using the

_USER_HOOK

_USER_HOOK

macros, and I believe it may be because of how Klipper parses Jinja statements before gcode?

I can see the RatOS

START_PRINT

START_PRINT

macro fetches the

bed_heat_soak_time

bed_heat_soak_time

and

hotend_heat_soak_time

hotend_heat_soak_time

using Jinja set statements right at the top of the routine, and I had thought if I use the

_USER_START_PRINT

_USER_START_PRINT

hook then that should update the variables defined in

[gcode_macro RatOS]

[gcode_macro RatOS]

and allow me to reference them through the

START_PRINT

START_PRINT

macro. However this doesn't seem to be the case, despite my

_START_VARIABLE_HEATSOAK

_START_VARIABLE_HEATSOAK

macro correctly calculating and setting the variables the machine still falls back to the default values defined in

[gcode_macro RatOS]

[gcode_macro RatOS]

.

I have somewhat proved this theory by changing the Machine Start Gcode in my slicer to:

_START_VARIABLE_HEATSOAK EXTRUDER_TEMP={first_layer_temperature[0]},{first_layer_temperature[1]} BED_TEMP={bed_temperature_initial_layer_single} X0={adaptive_bed_mesh_min[0]} Y0={adaptive_bed_mesh_min[1]} X1={adaptive_bed_mesh_max[0]} Y1={adaptive_bed_mesh_max[1]}

START_PRINT EXTRUDER_TEMP={first_layer_temperature[0]},{first_layer_temperature[1]} EXTRUDER_OTHER_LAYER_TEMP={nozzle_temperature[0]},{nozzle_temperature[1]} BED_TEMP={bed_temperature_initial_layer_single} CHAMBER_TEMP={overall_chamber_temperature} INITIAL_TOOL={initial_tool} TOTAL_LAYER_COUNT={total_layer_count} X0={adaptive_bed_mesh_min[0]} Y0={adaptive_bed_mesh_min[1]} X1={adaptive_bed_mesh_max[0]} Y1={adaptive_bed_mesh_max[1]}

_START_VARIABLE_HEATSOAK EXTRUDER_TEMP={first_layer_temperature[0]},{first_layer_temperature[1]} BED_TEMP={bed_temperature_initial_layer_single} X0={adaptive_bed_mesh_min[0]} Y0={adaptive_bed_mesh_min[1]} X1={adaptive_bed_mesh_max[0]} Y1={adaptive_bed_mesh_max[1]}

START_PRINT EXTRUDER_TEMP={first_layer_temperature[0]},{first_layer_temperature[1]} EXTRUDER_OTHER_LAYER_TEMP={nozzle_temperature[0]},{nozzle_temperature[1]} BED_TEMP={bed_temperature_initial_layer_single} CHAMBER_TEMP={overall_chamber_temperature} INITIAL_TOOL={initial_tool} TOTAL_LAYER_COUNT={total_layer_count} X0={adaptive_bed_mesh_min[0]} Y0={adaptive_bed_mesh_min[1]} X1={adaptive_bed_mesh_max[0]} Y1={adaptive_bed_mesh_max[1]}

And this runs correctly using the dynamically set heatsoak variables from my macro. Is there another way around this? This solution makes the slicer start gcode feel messy and I don't love it.

variable_heatsoak_2.cfg5.2KB

Jinja Parsing Order Prevents Overriding RatOS Variables?

Hey guys,

I have written a variable heat soak macro to allow setting the

[gcode_macro RatOS]
variable_bed_heat_soak_time:
variable_hotend_heat_soak_time:

[gcode_macro RatOS]
variable_bed_heat_soak_time:
variable_hotend_heat_soak_time:

values dynamically based on certain print stats.

However I am having an issue with trying to integrate this into the RatOS

START_PRINT

START_PRINT

routine using the

_USER_HOOK

_USER_HOOK

macros, and I believe it may be because of how Klipper parses Jinja statements before gcode?

I can see the RatOS

START_PRINT

START_PRINT

macro fetches the

bed_heat_soak_time

bed_heat_soak_time

and

hotend_heat_soak_time

hotend_heat_soak_time

using Jinja set statements right at the top of the routine, and I had thought if I use the

_USER_START_PRINT

_USER_START_PRINT

hook then that should update the variables defined in

[gcode_macro RatOS]

[gcode_macro RatOS]

and allow me to reference them through the

START_PRINT

START_PRINT

macro. However this doesn't seem to be the case, despite my

_START_VARIABLE_HEATSOAK

_START_VARIABLE_HEATSOAK

macro correctly calculating and setting the variables the machine still falls back to the default values defined in

[gcode_macro RatOS]

[gcode_macro RatOS]

.

I have somewhat proved this theory by changing the Machine Start Gcode in my slicer to:

_START_VARIABLE_HEATSOAK EXTRUDER_TEMP={first_layer_temperature[0]},{first_layer_temperature[1]} BED_TEMP={bed_temperature_initial_layer_single} X0={adaptive_bed_mesh_min[0]} Y0={adaptive_bed_mesh_min[1]} X1={adaptive_bed_mesh_max[0]} Y1={adaptive_bed_mesh_max[1]}

START_PRINT EXTRUDER_TEMP={first_layer_temperature[0]},{first_layer_temperature[1]} EXTRUDER_OTHER_LAYER_TEMP={nozzle_temperature[0]},{nozzle_temperature[1]} BED_TEMP={bed_temperature_initial_layer_single} CHAMBER_TEMP={overall_chamber_temperature} INITIAL_TOOL={initial_tool} TOTAL_LAYER_COUNT={total_layer_count} X0={adaptive_bed_mesh_min[0]} Y0={adaptive_bed_mesh_min[1]} X1={adaptive_bed_mesh_max[0]} Y1={adaptive_bed_mesh_max[1]}

_START_VARIABLE_HEATSOAK EXTRUDER_TEMP={first_layer_temperature[0]},{first_layer_temperature[1]} BED_TEMP={bed_temperature_initial_layer_single} X0={adaptive_bed_mesh_min[0]} Y0={adaptive_bed_mesh_min[1]} X1={adaptive_bed_mesh_max[0]} Y1={adaptive_bed_mesh_max[1]}

START_PRINT EXTRUDER_TEMP={first_layer_temperature[0]},{first_layer_temperature[1]} EXTRUDER_OTHER_LAYER_TEMP={nozzle_temperature[0]},{nozzle_temperature[1]} BED_TEMP={bed_temperature_initial_layer_single} CHAMBER_TEMP={overall_chamber_temperature} INITIAL_TOOL={initial_tool} TOTAL_LAYER_COUNT={total_layer_count} X0={adaptive_bed_mesh_min[0]} Y0={adaptive_bed_mesh_min[1]} X1={adaptive_bed_mesh_max[0]} Y1={adaptive_bed_mesh_max[1]}

And this runs correctly using the dynamically set heatsoak variables from my macro. Is there another way around this? This solution makes the slicer start gcode feel messy and I don't love it.

variable_heatsoak_2.cfg5.2KB

Jinja Parsing Order Prevents Overriding RatOS Variables?

Jinja Parsing Order Prevents Overriding RatOS Variables?

Continue the conversation

Rat Rig Community [Unofficial]

Similar Threads

Similar Threads

Continue the conversation

Rat Rig Community [Unofficial]

Similar Threads