Only allow prepend settings to be disabled

[wawanbreton]

When the printer settings say they should be disabled, they could previously be enabled if the start GCode didn't contain temperature commands. Now we can only enable them if initially enabled.

This change is not actually required by the described bug, but it makes what users expect. We currently have printers definitions which override the default value of material_print_temp_prepend to False, and this was ignored. We now take care of it as described in the setting documentation.

Related to CURA-11967

[GregValiant]

This is the fix for #19204 ?

[wawanbreton]

This is the fix for #19204 ?

Not exactly, the actual fix is on the engine side: Ultimaker/CuraEngine#2116

This one is an added security to make sure that we will never enable material_print_temp_prepend when the printer description has it False.

[GregValiant]

@wawanbreton While fooling around with a One at a Time project I noted that the prepend temperatures were being inserted at the start of every model. The M109 would be a problem as it would cause an effective dwell of 10 seconds at the start of each model.
Do the fixes also take care of that situation?

[wawanbreton]

Hmm no, for the beginning we consider that the start G-Code is responsible for preparing the bed and/or nozzles, so we don't do anything more.
When switching to a model for a new sequence, the start G-Code is not re-inserted so this time we have to "re-configure" the temperatures, so they will always be added at this point.
If you don't want the M109 at this point, you can still set material_print_temp_wait to False, but this will work only for the non-active extruder(s). We will always wait for the active extruder to reach the temperature before starting.

Can you tell my:

1. Why this would result in a 10s wait ? Because of a higher initial layer temperature ?
2. How is this an issue ? Is the nozzle still on the model while waiting ?

[GregValiant]

Turning off "Wait for nozzle heatup" eliminates the M109. That works for me.

I saw it as a problem because the sequence is "lift - travel to next print - M109" so the nozzle would be hovering directly above the print location and oozing.
It appears that M109 doesn't make an instantaneous decision as to whether the temperature is at the set point. Whether there is a wait when there has not been a temperature change, seems dependent on exactly at what point in time M109 is activated.

Consider that the current temperature is 200 and then there is a line M109 S200. (That's what was happening.)
That will often (90% of the time?) cause a 10 second wait before acknowledging that the temperature is stable. Other times the gcode will continue to flow right through it with no pause at all. I have not figured out what criteria it uses but I suspect it is at least partially hardware related. Some sort of latency in the thermistor?...dunno.

I know that it happens because I always preheat my machine prior to printing and it is always up to temperature when it encounters the M109 in the startup. The 90% guestimate of a 10 second pause/dwell happening is pretty close. The print server I use shows me the countdown.
The printer was at 26 when I sent an M109 S27. The countdown started the moment the thermistor read over 26.
T:26.05 /27.00 B:22.46 /0.00 @:0 B@:0 W:?
T:26.14 /27.00 B:22.46 /0.00 @:13 B@:0 W:9
T:26.16 /27.00 B:22.42 /0.00 @:14 B@:0 W:8
T:26.36 /27.00 B:22.46 /0.00 @:11 B@:0 W:7
T:26.36 /27.00 B:22.38 /0.00 @:13 B@:0 W:6
T:26.70 /27.00 B:22.38 /0.00 @:7 B@:0 W:5
T:26.82 /27.00 B:22.50 /0.00 @:6 B@:0 W:4
T:27.24 /27.00 B:22.50 /0.00 @:0 B@:0 W:3
T:27.27 /27.00 B:22.42 /0.00 @:0 B@:0 W:2
T:27.59 /27.00 B:22.38 /0.00 @:0 B@:0 W:1
T:27.64 /27.00 B:22.42 /0.00 @:0 B@:0 W:0
ok
Sending additional M109 S27 will usually result in an additional countdown. The nozzle would be oozing during that time.

Here it is in Marlin:
#if HAS_E_TEMP_SENSOR
#define TEMP_RESIDENCY_TIME 10 // (seconds) Time to wait for hotend to "settle" in M109
#define TEMP_WINDOW 1 // (°C) Temperature proximity for the "temperature reached" timer
#define TEMP_HYSTERESIS 3 // (°C) Temperature proximity considered "close enough" to the target

Ya gotta love a "close enough" setting.

[wawanbreton]

Ok, thanks for the details.
So this is very firmware-dependant, but it also makes sense that it waits for the temperature to be established and stable before going further.

Turning off "Wait for nozzle heatup" eliminates the M109. That works for me

Did you try with 5.7.2 or with this PR applied ?

The oozing over the start position is indeed very annoying, but it will happen anyway if the temperature of the initial layer is different. We should make sure that it doesn't hurt any of the models though. I see that we make the skirt/brim individually, isn't it good enough to move the blotch away ?

[GregValiant]

It is firmware dependent. My guess would be that even in custom Marlin firmware, those parameters would rarely be changed.
I was fooling around some more with different models. The travel is different depending on whether there is supports or not, and where the Layer Start XY is. Sometimes the nozzle hovers over the "next to print" footprint and in those cases oozing would be a problem. At other times the travel is to a point away from the footprint. In those cases, other than dragging the string to the start point, there shouldn't be a blob dropping to the build plate.

I have convinced myself that there is no good answer to this. The M109 can be an issue but it depends on where the nozzle is and that is dependent on about 47 other things. Turning off "Wait for nozzle heatup" does mitigate any problem as it might take 5 seconds to adjust to "Initial Print Temperature" while it's printing so for myself that 5 seconds will probably be the skirt/brim so I don't really care. It's "Close Enough".

I print mostly PETG and it's always stringy so I may be more sensitive than most. I had never noticed that "Wait for nozzle heatup" affected One at a Time prints.

The tooltip for "Wait for nozzle heatup" could make mention of the fact that it affects each model start in a One at a Time project. Right now it's a bit cryptic and I took it to mean only the prepend gcode was affected.