-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cura Printer Settings Start G-code commands are overridden/preceded #12404
Comments
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. |
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
<#12404 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZNKCASLMI4MGRGSTKG4TNLVMZJHBANCNFSM5XNUJQ7Q>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
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. |
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. |
Wow, thanks for even reacting to this old and closed issues request. |
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. |
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.
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.
The text was updated successfully, but these errors were encountered: