Ultimaker / Cura

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

CURA overides "start G-code" causing machine control issues. STILL not fixed! #17710

Open beebenutz opened 10 months ago

beebenutz commented 10 months ago

Cura Version

5.6.0

Operating System

ALL

Printer

ALL

Reproduction steps

1 - Enter the start G-code for your machine as the USER requires for proper operation of user's machine. 2 - Slice file. 3 - Find extra script inserted without the user's consent prefixing the user's required start script. (now machine does not work as required) 4 - Check for option to remove ability for CURA to prefix the start code. 5 - Find no option available. 6 - Contact developers to request that the broken slicer be fixed. 7 - Wait for changes to be implemented. 9 - Go back to alternate slicer AGAIN. PLEASE actually fix this!

Actual results

CURA overrides any "start G-code" by generating unsolicited start code prefixing the user's required start code. PLEASE actually fix this!

Expected results

User's "start G-code" should actually be the "start G-code". Why would users generate start code only to be overridden. This makes ZERO sense. PLEASE actually fix this!

Add your .zip and screenshots here ⬇️

web3-crying-child-boy-tears-sad-upset-tantrum-shutterstock_2023-12-19_20 50 09

Asterchades commented 10 months ago

What actual code is being generated that is causing you problems so severe you feel it necessary to liken yourself to a toddler?

beebenutz commented 10 months ago

What actual code is being generated that is causing you problems so severe you feel it necessary to liken yourself to a toddler?

The exact same code that was apparently written by toddlers.

Asterchades commented 10 months ago

That isn't in the least bit helpful. There are ways to override certain pieces of code being automatically generated, which I would be more than happy to share, but if you're unwilling or unable to actually provide an example of what's causing you grief then it simply isn't possible to assist you further and this may as well be closed.

So I will ask once more: what actual code is being generated that's causing you problems?

beebenutz commented 10 months ago

Cura is inserting the last three lines of code which is directly before my required start code:

;FLAVOR:Repetier ;TIME:1964 ;MINX:-21.2 ;MINY:-21.2 ;MINZ:0.2 ;MAXX:21.2 ;MAXY:21.2 ;MAXZ:20 ;TARGET_MACHINE.NAME:Unknown ;Generated with Cura_SteamEngine 5.6.0 M190 S70 M104 S200 M109 S200

There WAS a plugin to at least provide a work-around ("search and replace"), but the plugin seems to have been integrated into Cura. The integrated plugin omits the only function that actually provided the work-around (the option to only replace the first instance of found code). Now, it's just more useless code.

beebenutz commented 10 months ago

That isn't in the least bit helpful. There are ways to override certain pieces of code being automatically generated, which I would be more than happy to share, but if you're unwilling or unable to actually provide an example of what's causing you grief then it simply isn't possible to assist you further and this may as well be closed.

So I will ask once more: what actual code is being generated that's causing you problems?

Cura is inserting the last three lines of code which is directly before my required start code:

;FLAVOR:Repetier ;TIME:1964 ;MINX:-21.2 ;MINY:-21.2 ;MINZ:0.2 ;MAXX:21.2 ;MAXY:21.2 ;MAXZ:20 ;TARGET_MACHINE.NAME:Unknown ;Generated with Cura_SteamEngine 5.6.0 M190 S70 M104 S200 M109 S200

There WAS a plugin to at least provide a work-around ("search and replace"), but the plugin seems to have been integrated into Cura. The integrated plugin omits the only function that actually provided the work-around (the option to only replace the first instance of found code). Now, it's just more useless code.

Asterchades commented 10 months ago

Automatically generated temperature commands exist as a fail-safe. Older versions of Marlin do not incorporate minimum extrusion temperatures, and even current versions only support it optionally (though it defaults to on), meaning it is possible to tell the machine to attempt to feed filament through a cold tool. This can result in physical damage to the printer itself, even if it's unlikely. Failing to heat the bed probably won't do that, but if you're heating the tool then you may as well do the bed, too, else it could inadvertently result in failed prints.

You can override this automatic generation with the use of the appropriate placeholders. Specifically {material_bed_temperature_layer_0} and {material_print_temperature_layer_0}. The presence of each of these in your Start GCode will disable automatic generation of their corresponding temperature command - even if you don't actually use them to assign temperatures at all and just have them either commented out or as throw-away lines for the printer to dismiss.

Though I would recommend using these placeholders to set your temperatures anyway, even if using a Klipper macro. Hard-coding temperatures, aside from standby temperatures (for which there is also a placeholder - {material_standby_temperature}), is a pretty good way to accidentally use the wrong temperature for the wrong filament.

beebenutz commented 10 months ago

Automatically generated temperature commands exist as a fail-safe. Older versions of Marlin do not incorporate minimum extrusion temperatures, and even current versions only support it optionally (though it defaults to on), meaning it is possible to tell the machine to attempt to feed filament through a cold tool. This can result in physical damage to the printer itself, even if it's unlikely. Failing to heat the bed probably won't do that, but if you're heating the tool then you may as well do the bed, too, else it could inadvertently result in failed prints.

You can override this automatic generation with the use of the appropriate placeholders. Specifically {material_bed_temperature_layer_0} and {material_print_temperature_layer_0}. The presence of each of these in your Start GCode will disable automatic generation of their corresponding temperature command - even if you don't actually use them to assign temperatures at all and just have them either commented out or as throw-away lines for the printer to dismiss.

Though I would recommend using these placeholders to set your temperatures anyway, even if using a Klipper macro. Hard-coding temperatures, aside from standby temperatures (for which there is also a placeholder - {material_standby_temperature}), is a pretty good way to accidentally use the wrong temperature for the wrong filament.

I did find your work-around on a forum while waiting for a reply. Can we not provide a "tick box" or other means of disabling CURA from assuming we need extra code which was apparently derived due to some deprecated version of Marlin. Since we're running on assumptions, should we not also assume that adding this extra unsolicited code may also cause machine damage when nozzle park positions shall prohibit nozzle or bed heating? CURA program OR it's creators can't know what each machine and user require for each application.

Please work on a future feature which allows the disabling of this extra code from within each machine's settings menu. From all the reading I have done on this matter, there seems to be quite a lot of users who fight this issue unnecessarily. Many also have issues with this extra code generation when attempting to use multiple hot-ends. CURA is known for it's incredible amount of customization, but flops a bit due to this silly start code generation.

I hope you, or someone actually provides a straight forward implementation for this code generation to be clearly disabled.

Thanks!

Coninox commented 3 months ago

Automatically generated temperature commands exist as a fail-safe. [...], meaning it is possible to tell the machine to attempt to feed filament through a cold tool. This can result in physical damage to the printer itself, even if it's unlikely.

I use a creality CR6. The hotend have to touch the plate to do home. I use it with a PEI plate. I don't care if the previous behaviour may cause physical damae on potential other printers I don't own. What I know is If the nozzle is at the print temperature when the printer do the home, It will result in physical damage to my printer.

Since I've upgraded to Cura 5.7.2 (from 5.0.0), every time I start a print, I have to wait until the printing temperature has been reached. Then I have to wait for the temperature to drop to 120°C. Then I have to wait again until the printing temperature is reached.

every time I start a print, I look like this picture of a crying toddler.

You can override this automatic generation with the use of the appropriate placeholders. Specifically {material_bed_temperature_layer_0} and {material_print_temperature_layer_0}. The presence of each of these in your Start GCode will disable automatic generation of their corresponding temperature command - even if you don't actually use them to assign temperatures at all and just have them either commented out or as throw-away lines for the printer to dismiss.

I have tried to set the following Start G-code

{material_bed_temperature_layer_0}
{material_print_temperature_layer_0}

M140 S{material_bed_temperature_layer_0}
M109 R120

M140 S0
G28 ;Home
M104 S{material_print_temperature_layer_0}

there is the generated G-Code :

;Generated with Cura_SteamEngine 5.7.2
M104 S215
M105
M109 S215
M82 ;absolute extrusion mode
60
215.0

M140 S60

M109 R120

M140 S0
G28 ;Home
M104 S215.0

I still have to wait for the temperature to rise, then to drop, then to rise again. Every single time I print something.

Asterchades commented 3 months ago

5.7.2 unfortunately has a bug where even if the tokens are present it will still generate the temperature commands automatically. This was not present in 5.7.1 and earlier, and has since been corrected in the 5.8.0 beta released under an hour ago.

Apologies, @beebenutz, for not seeing your response earlier. I agree this potentially has some merit as a user-facing setting, but it's something best addressed in its own thread as a feature request (if you've not already done so) to keep it from getting lost.

beebenutz commented 3 months ago

This issue STILL exists and has not been addressed! A similar issue has been found when attempting to use the "pause at height" gcode post processor. The Pause at height extension has a box to enter your desired commands. If you enter exactly what is desired, CURA automatically adds more commands to the output gcode that was not desired, or even known to be happening. AND SOMEHOW NOBODY CARES TO ADDRESS THIS ISSUE AS IF IT ISN'T HAPPENING! How can you have software that explicitly asks for your desired commands, then ignores the request and comes up with it's own. This is beyond stupid!