Heat bed and hotend temperature concurrently, not sequentially

[richfelker]

CuraEngine currently emits gcode to perform the initial bed and hotend heating sequentially, as a sequence (Marlin flavor gcode) of M140, M190, M104, M109 - set bed temp, wait for bed to reach temp, set hotend temp, wait for hotend to reach temp. This roughly doubles (depending on hardware and temps involved) the initial wait to start a print vs what it would take if the operations were performed concurrently, via a sequence like M140, M104, M190, M109.

Is there a reason it's done this way? Could it be changed or made optional?

[Ghostkeeper]

Uh, yeah, and thinking about it again, it's probably not good to have implemented it in this way.

The reason was that the Ultimaker 3 doesn't have enough power to heat up the bed at the same time as the nozzles. Trying to heat them both at the same time causes the printer to power cycle. In hindsight it would've been better to make that a specialisation of the Ultimaker 3 rather than making it the default.

It can be overridden by modifying the start g-code of your printer. If the start g-code contains the keys {material_bed_temperature_layer_0} and {material_print_temperature_layer_0} then Cura will recognise these and not put its own temperature commands in at the beginning.

[richfelker]

CuraEngine doesn't seem to be performing any such key replacement in custom start/end g-code. Is this something only done by gui frontend, or a setting that needs to be enabled somewhere?

[Ghostkeeper]

Ah, yes. Indeed the front-end does this part:

https://github.com/Ultimaker/Cura/blob/6ebc08420a9cedd437184806249880dd0595199e/plugins/CuraEngineBackend/StartSliceJob.py#L320-L364

The front-end then signals to CuraEngine whether or not it needs to insert its own temperature commands via these two settings: material_bed_temp_prepend and material_print_temp_prepend. If any temperature-related keys were replaced in the start g-code, those will be set to false.

[richfelker]

That seems like something of a bug in itself, since some of the existing machine definition files include keys to be expanded, and silently produce junk in the emitted gcode when used with CuraEngine directly.

[richfelker]

As a workaround for now, would it work to set material_bed_temp_wait and material_print_temp_wait to false and add the M109 and M190 commands (with no S argument) to the custom start gcode?

[Ghostkeeper]

Uh, yeah, and thinking about it again, it's probably not good to have implemented it in this way.

[Ghostkeeper]

As a workaround for now, would it work to set material_bed_temp_wait and material_print_temp_wait to false and add the M109 and M190 commands (with no S argument) to the custom start gcode?

Isn't there the M104 command and M140 command to heat without waiting? I'd use those, and then the M109 and M190 commands afterwards.

[richfelker]

The M104 and M140 commands have to be generated by CuraEngine as part of the normal prologue, since it doesn't support expanding the keys into the custom start gcode, and temperatures are material-dependent configuration (assuming you don't want a separate custom start gcode per material). But if CuraEngline also generates the waits, it puts them in an order that precludes concurrent heating. So my proposed workaround is to put the waits (without a specific temperature, indicating "wait for the current target temp") in the custom start gcode and just suppressing CuraEngine's generation of its own wait commands via changing the material_*_temp_wait settings to false.

[Ghostkeeper]

Yeah, that'd work.

[morganchristiansson]

Came here from https://3dprinting.stackexchange.com/a/12190

Is there an open PR to add this as an option? Adding start gcode for the machine works fine I guess but an option would be smooth.

[Ghostkeeper]

Not as far as I know. This has no real priority for Ultimaker since the command line interface is only there for debugging purposes. Using the front-end, it's simple enough to specialise the heat-up sequence in the start g-code.

[nberardi]

It looks like it has been over a year since this issue was raised. I am constantly having to hand edit my G-code to swap this around, and was hoping that we might have a path forward now.

It seems like this should be a printer setting, that allows the user to synchronously heat the bed and extruder or asynchronously heat them.

[richfelker]

Note that this workaround no longer works:

So my proposed workaround is to put the waits (without a specific temperature, indicating "wait for the current target temp") in the custom start gcode and just suppressing CuraEngine's generation of its own wait commands via changing the material_*_temp_wait settings to false.

As modern firmware does not support the M109 and M190 commands without a target temperature. So it would be really nice to have this fixed properly.

[nberardi]

Could you define a proper fix? As for my setup using Klipper. Rearranging the startup from:

M140 S70
M190 S70
M104 S210
M109 S210

To the following

M140 S70
M104 S210
M190 S70
M109 S210

Solves the problem for me an allows both of my units to warm simultaneously.

Also if we are solving this problem, I would love to see this warming value set to the initial bed temperature, instead of the printing bed temperature. As it causes the print to start before the bed has reached the desire temperature since I have my first layer temperature 10 degrees higher for the first layer.

[richfelker]

As far as I know, CuraEngine has no way to request generation of that sequence. You have to edit the resulting gcode or put temperatures in the start gcode (CuraEngine invoked directly doesn't do the Python substitutions in start gcode that the frontend can do).

[nberardi]

@richfelker That is what your issues was in regards to unless I misunderstood it, asking for the ability to heat both at the same time instead of sequentially. This seems like it would be an easy toggle to add to the printer configuration in the UX to adjust the way the gcode is generated.

[Ghostkeeper]

You can still set this via settings. You simply have to edit the start g-code. You can't make it automatically adjust with other settings such as the printing temperature, but that just means you have to adjust 2 settings instead of 1 when the printing temperature or build plate temperature is changed. Adjusting the start g-code is the preferred way to customise the start-up sequence. There are just too many different printers out there to add settings to automatically generate perfect start-up sequences for all of them.

CuraEngine inserting its own temperature commands can be disabled by setting the material_print_temp_prepend and material_bed_temp_prepend to false. You can then place your own commands in the start g-code. No g-code post-processing is required.

[nberardi]

CuraEngine inserting its own temperature commands can be disabled by setting the material_print_temp_prepend and material_bed_temp_prepend to false. You can then place your own commands in the start g-code. No g-code post-processing is required.

Where would I find these settings? I haven't come across them in the app.

[Ghostkeeper]

Those settings are made invisible in Cura's front-end. You can only set them if you call CuraEngine manually, which is the setting that Richfelker was describing. Cura's front-end sets these two settings automatically. They are set to false if there are any temperature settings in the start g-code (of either the nozzle or bed temperature).

So to reiterate:

• If you're using the front-end of Cura, you can simply edit the start g-code with M104 {material_print_temperature_layer_0} M140 {material_bed_temperature_layer_0} M109 {material_print_temperature_layer_0} M190 {material_bed_temperature_layer_0}. Cura sees these settings being used and will then no longer put its own commands in there. You can even use them in a comment to manually disable them, as in #{material_bed_temperature}.
• If calling CuraEngine via its command-line interface, you can't do this. Create the start g-code with correct temperatures manually, and set material_print_temp_prepend and material_bed_temp_prepend to false to tell CuraEngine to not put its own temperature commands before the start g-code.

The definitions for these settings can be found here (but they are machine settings, so not normally visible): https://github.com/Ultimaker/Cura/blob/cba956be193de02121159127a32095da27cb40b7/resources/definitions/fdmprinter.def.json#L117-L137