Problem with generated g-code: Pre-mature Heatup g-code inserted before startup g-code

[reibuehl 42]

Hi all,

 

I have an issue with the g-code that Cura 4.11 generates for my Tinyboy Fabricator 1.5: I have a start g-code defined that first homes the axis and positions the nozzle and then heats up the hotend. But in the generated g-code, I get additional heat up gcode before my startup g-code. This results in problems with the print start as material already oozes out at the "wrong" place. How can this premature heat up be suppressed?

 

My startup g-code looks like this:

;Sliced at: {day} {date} {time}
;Basic settings: Layer height: {layer_height} Walls: {wall_thickness} Fill: {infill_sparse_density}
;Print time: {print_time}
;Filament used: {filament_amount}m {filament_weight}g
;Filament cost: {filament_cost}
G21        ;metric values
G90        ;absolute positioning
M82        ;set extruder to absolute mode
M107       ;start with the fan off
G28 X0 Y0  ;move X/Y to min endstops
G28 Z0     ;move Z to min endstops
G1 X0.0 Y0.0 Z15.0 F{travel_speed} ;move the printhead up 15mm
G92 E0                  ;zero the extruded length
M104 S{print_temperature} ;set extruder temperature
M105
M109 S{print_temperature} ;wait for extruder temperature
G1 F200 E30              ;extrude 30mm of feed stock
G92 E0                  ;zero the extruded length again
G1 F{travel_speed}
;Put printing message on LCD screen
M117 Printing...

 

The generated g-code however looks like this:

;FLAVOR:Marlin
;TIME:3570
;Filament used: 2.29132m
;Layer height: 0.2
;MINX:8.303
;MINY:8.315
;MINZ:0.2
;MAXX:71.698
;MAXY:71.687
;MAXZ:22
;Generated with Cura_SteamEngine 4.11.0
M104 S210
M105
M109 S210
M82 ;absolute extrusion mode
;Sliced at: Sat 04-12-2021 11:18:18
;Basic settings: Layer height: 0.2 Walls: 1.2 Fill: 20
;Print time: 00:59:31
;Filament used: [2.29]m [0.0]g
;Filament cost: [0.0]
G21        ;metric values
G90        ;absolute positioning
M82        ;set extruder to absolute mode
M107       ;start with the fan off
G28 X0 Y0  ;move X/Y to min endstops
G28 Z0     ;move Z to min endstops
G1 X0.0 Y0.0 Z15.0 F100 ;move the printhead up 15mm
G92 E0                  ;zero the extruded length
M104 S210 ;set extruder temperature
M105
M109 S210 ;wait for extruder temperature
G1 F200 E30              ;extrude 30mm of feed stock
G92 E0                  ;zero the extruded length again
G1 F100
;Put printing message on LCD screen
M117 Printing...

 

The lines 12-14 in the example above are the problem. They should not be there.

 

Any ideas?

 

Best regards,

Reiner

[GregValiant 1,354]

You have a couple of incorrect keywords in there.  Cura knows to add the numbers, but no longer understands what they mean.  This is from the LIST OF KEYWORDS put together by FieldOfView / @ahoeben.

{print_temperature}        Alias for material_print_temperature (deprecated, do not use)

{print_bed_temperature}        Alias for material_bed_temperature (deprecated, do not use)
{travel_speed}        Alias for speed_travel (deprecated, do not use)

 

So you need to make changes:

{print_temperature} should be {material_print_temperature_layer_0}

 

{travel_speed} (or now speed_travel) is in mm/sec and the gcode setting is mm/min so G1 F{travel_speed} comes out as G1 F100 instead of G1 F6000.  You will need to hard code that speed in because there are no keywords for speed in mm/min (although it has been asked for on Github).  Change that line to G1 F6000.

 

I am assuming you don't have a heated bed (Cura didn't add an M140 temperature setting) so making those changes should suffice.

[reibuehl 42]

{material_print_temperature_layer_0} does not work. If I use it, the result is a M104 S0 - in the Cura UI, the parameter "Printing Temperature Initial Layer" defaults to 0 which should mean "no special treatment of layer 0" according to https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json but that apparently doesn't work correctly.

With {material_print_temperature} however it seems to work. I will test it once more and then create a pull request for https://github.com/Ultimaker/Cura/blob/master/resources/definitions/tinyboy_fabrikator15.def.json as the start and end g-code comes from there.

[ahoeben 1,989]

1 hour ago, reibuehl said:

in the Cura UI, the parameter "Printing Temperature Initial Layer" defaults to 0 which should mean "no special treatment of layer 0"

 

What happens is that Cura just blindly fills in what the "Printing Temperature Initial Layer" is set to, which apparently is 0 in your case. The lemma "no special treatment" unfortunately only applies to how CuraEngine treats the value. In a way, because you reference {material_print_temperature_layer_0} in the start gcode, you are forcing the special treatment of layer 0.

 

The default behavior of the "Printing Temperature Initial Layer" is to default to the same value as the "Printing Temperature" setting: https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json#L2313

 

I personally dislike the use of an arbitrary value for special cases. Why does 0 mean not to use the value? What if I want the first layer to print at a temperature of 0 degrees celsius for my (hypothetical) ice printer?

 

So my advice is never use the 0-for-no-special-casing, and instead use the setting inheritance that Cura uses (where "Printing Temperature Initial Layer" inherits from "Printing Temperature" unless the user enters a specific value in "Printing Temperature Initial Layer").

[reibuehl 42]

18 minutes ago, ahoeben said:

 

What happens is that Cura just blindly fills in what the "Printing Temperature Initial Layer" is set to, which apparently is 0 in your case. The lemma "no special treatment" unfortunately only applies to how CuraEngine treats the value. In a way, because you reference {material_print_temperature_layer_0} in the start gcode, you are forcing the special treatment of layer 0.

 

The default behavior of the "Printing Temperature Initial Layer" is to default to the same value as the "Printing Temperature" setting: https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json#L2313

 

Then the fact that Cura is not using {material_print_temperature_layer_0} as documented in the UI and description of the parameter in the source is a bug in Cura?

[ahoeben 1,989]

Depends on your definition of a bug.

 

The default behavior is working correctly (inheriting the normal printing temperature if no specific temperature is specified), but there is also a problematic second mechanism that is poorly documented as a "good thing to do", when in fact it isn't.

[reibuehl 42]

18 hours ago, ahoeben said:

Depends on your definition of a bug.

 

The default behavior is working correctly (inheriting the normal printing temperature if no specific temperature is specified), but there is also a problematic second mechanism that is poorly documented as a "good thing to do", when in fact it isn't.

This is the default settings I see. If it would work correct, then {material_print_temperature_layer_0} should be evaluated to 210. But it is evaluated to 0. In my definition this is a bug. I am just not sure if it is a bug in the printer definition (then it would be my fault as I contributed the definition for that printer  😀 ) or if it is a bug in the engine itself.

[ahoeben 1,989]

I would say it is an "inconvenience" in the printer definition. I would advise against using the "0 for no effect" values. Just keep the value unset in your profiles if you don't want to special-case the initial layer, and you can safely use the {material_print_temperature_layer_0} value. Also note that Cura adds an "f(x)" hint in front of the value. Mouse over that for an explanation; click on it to restore the automatic inheritance (replacing the "0" in your profiles).

[ahoeben 1,989]

12 minutes ago, reibuehl said:

If it would work correct, then {material_print_temperature_layer_0} should be evaluated to 210.

I understand what you are saying, but it does in fact work "as intended" by replacing {mateiral_print_temperature_layer_0} by the value that you see in the sidebar: 0. In my opinion that bit of documentation to "Set at 0 to disable" should just be removed, exactly because of this confusion.

[reibuehl 42]

I created pull request https://github.com/Ultimaker/Cura/pull/11015 that should fix the start & end gcode and the temperature settings in all three profiles.