Ultimaker / Cura

3D printer / slicing GUI built on top of the Uranium framework
GNU Lesser General Public License v3.0
6.22k stars 2.08k forks source link

Cura Printer Settings Start G-code commands are overridden/preceded #12404

Closed ThomasHHolm closed 2 years ago

ThomasHHolm commented 2 years ago

Application Version

4.12.1

Platform

Windows 10 Pro 60 bit

Printer

Creality Ender 5 running Klipper / Mainsail

Reproduction steps

Setup: I'm running Klipper Mainsail on my Ender 5 pro and use the Moonraker plugin to send gcode files to it from Cura. In Cura I've specified my Cura Start G-code to execute a macro called PRINT_START and nothing else. Cura vs SS gcode example

Actual results

The exported gcode contains gcode commands preceeding the PRINT_START commands which instruct the bed and nozzle to begin heating up. This interferes w with the functionality of my macro and printer behavior. I have found no setting to prevent Cura from overriding my Start G-code instructions. Slicing/exporting the same file to a printer not using the Moonraker plugin produces identical results.

Expected results

The generated gcode file should ONLY contain instructions specified in the Start G-code window. Slicing/exporting the same file using eg. SuperSlicer produces the intended result ie. a gcode file which executes the instructions defined in the Start G-codes.

Checklist of files to include

Additional information & file uploads

Attached screenshot shows Start-gcode settings defined in Cura vs SuperSlicer and the resulting gcode files generated. Note the SuperSlicer gcode file was cleaned of information pertaining to thumbnail info embedded in the file.

GregValiant commented 2 years ago

If the StartUp Gcode does not contain heating commands that use Cura Keywords then Cura adds heating lines before the StartUp Gcode to prevent cold extrusions. If you were to add: M104 S{material_standby_temperature} to your startup gcode then that initial hot end temperature line would not be added. Adding M140 S{material_bed_temperature_layer_0} to the startup gcode would keep the initial bed temperature from showing up. You could do that and then in your macro you could shut them off again or do whatever you want to with the temperatures.

ThomasHHolm commented 2 years ago

Thank you - I just found the same info elsewhere and have implemented it and it seems to work. It would be helpful if this info was available in the printer settings window to reduce confusion for others.

On Tue, 31 May 2022, 20:14 GregValiant, @.***> wrote:

If the StartUp Gcode does not contain heating commands that use Cura Keywords then Cura adds heating lines before the StartUp Gcode to prevent cold extrusions. If you were to add: M104 S{material_standby_temperature} to your startup gcode then that initial hot end temperature line would not be added. Adding M140 S{material_bed_temperature_layer_0} to the startup gcode would keep the initial bed temperature from showing up. You could do that and then in your macro you could shut them off again or do whatever you want to with the temperatures.

— Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/12404#issuecomment-1142462870, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZNKCASLMI4MGRGSTKG4TNLVMZJHBANCNFSM5XNUJQ7Q . You are receiving this because you authored the thread.Message ID: @.***>

groomit commented 4 months ago

I don't know why, but this solution does not work anymore. Cura still throws a blocking M109 in the start gcode sequence prior to my START_PRINT macro. What I figured is, that Cura is using integers while the variables used translate to float values. Maybe Cura is expecting a different start variable now (Version 5.7.2)?

GregValiant commented 4 months ago

Please see #19204. About 1/2 way down the page I posted a post processor that addresses the bug. Unzip the file and put "CuraPrependBugFix.py" into your Configuration Folder and the "scripts" sub-folder. If you continue to have trouble please use the Save Project command and zip and post the 3mf file. This bug should be fixed in 5.8.0 which is do for release shortly.

groomit commented 4 months ago

Please see #19204. About 1/2 way down the page I posted a post processor that addresses the bug. Unzip the file and put "CuraPrependBugFix.py" into your Configuration Folder and the "scripts" sub-folder. If you continue to have trouble please use the Save Project command and zip and post the 3mf file. This bug should be fixed in 5.8.0 which is do for release shortly.

Wow, thanks for even reacting to this old and closed issues request. This clarifies a lot. I already started to doubt in my capabilities of applying clear instructions. Bummer this sort of bug is introduced out of nowhere. Thanks for your effort with the script. Can't wait to have a fixed 5.8 at hand

GregValiant commented 4 months ago

This bug affected a lot of people. The original implementation of "logic" into the Cura Startup Gcode required a fix (which I think went with 5.7.1) and when that fix was put in place this bug showed up. Unintended consequence. Too bad to. The slicing problems with 5.5 and 5.6 were fixed and then this had to show up.