Jump to content

G-Code applied before custom startup


Limroto

Recommended Posts

Posted (edited) · G-Code applied before custom startup

When I generate my g-code, I can add some custom settings before all of it through the Printers -> Machine Settings -> Start G-Code.

This is nice, but I noticed some code is being added before my own - how can this be?

 

Take a look at line 12-14 on the attached image.

Apparently the Cura_SteamEngine decided to warm up my bed before I want to do it my self (which will do both the nozzle and the bed at the same time).

 

Can I disable these three lines?

Code.png

Edited by Limroto
  • Link to post
    Share on other sites

    Posted · G-Code applied before custom startup

    The cause of this issue is that in your start gcode you use the {print_bed_temperature} replacement pattern. Try replacing that with {material_bed_temperature}.

  • Link to post
    Share on other sites

    Posted · G-Code applied before custom startup

    Not so fast, I think this is a real issue. And you should not disable the flag "Heated bed", unless your printer really has no heated bed! If you do that Cura will not automatically insert any G-codes to control bed temperature.

     

    See my screenshot, Cura is inserting my "initial layer bed temperature" before my own start G-code settings, and since I use "material_bed_temperature" for automatic bed levelling, that "initial layer bed temperature" is effectively overridden. It correctly inserts "material bed temperature" after the initial layer further  down in the code, but since it insists on inserting code before my start g-code it really messes up the first layer bed temperature.

     

    Why is cura doing this, and can this be changed?

     

    IMHO it should not insert *anything* (except comments maybe) before my own "start G-code".

    I guess I could workaround this by using material_bed_temperature_layer_0 for my bed levelling, but I really think this behavior needs to be changed.


    1267106448_CurainsertscodebeforeStartG-Code.thumb.jpg.4e3379580ad6cd8f80a312bac8bed688.jpg

  • Link to post
    Share on other sites

    Posted · G-Code applied before custom startup
    34 minutes ago, chjohans said:

    Why is cura doing this, and can this be changed?

     

    Cura tries to protect your printer against cold extrusion.

     

    Cura tries to see if there is anything in your start gcode that heats up your extruder(s), and bed. If not, it will insert a heatup sequence on its own. 

  • Link to post
    Share on other sites

    Posted · G-Code applied before custom startup

    Thanks, but did you even look at my startup G-Code? I do have commands to heath up both my bed and my hotend there.

     

    And in any case,  IMHO Cura should not insert *anything* except comments before my Startup-Gcode as that has a high risk of messing something up. And it's no longer "Startup G-Code" when things are inserted in front of it.

  • Link to post
    Share on other sites

    Posted · G-Code applied before custom startup

    You should be using {material_bed_temperature} or {material_bed_temperature_layer_0} instead of {default_material_bed_temperature}.

  • Link to post
    Share on other sites

    Posted · G-Code applied before custom startup

    Really? I set default_material_bed_temperature in my material settings by using your plugin, but if I use one or the other is besides the point. This is not the issue at all.

     

    The issue is that Cura inserts Gcode before my Start G-code, that won't change if I use one or the other. Cura will still insert those G-Codes where it should not.

     

    Anyhow thanks for trying to help, I have registered this as an issue in GitHub.

  • Link to post
    Share on other sites

    Posted · G-Code applied before custom startup

    If you use {material_bed_temperature} or {material_bed_temperature_layer_0} in your start gcode snippet, then Cura won't insert gcode for heating the bed in front of the start gcode.

  • Link to post
    Share on other sites

    Posted · G-Code applied before custom startup

    Yes you are right about that, but I still think Cura should have inserted it's temp control G-Code *after* the Startup G-Code.

     

    Trying to understand the logic of what's going on: I assume that Cura looks for "M140 {material_bed_temperature_layer_0}" before layer 1, and if it can't find it it inserts it. Is that how it works?

     

    Also for my own understanding, how is the variable material_bed_temperature being set? Is it set depending on where in the code it is? So at the start of the code material_bed_temperature is set to material_bed_temperature_layer_0 and after the first layer it's set to default_material_bed_temperature?

     

    Unless it's otherwise overridden that is.

     

    Do you happen to know the logic here?

     

    As I'm sure you understand Cura is quite new to me so your input is highly appreciated. So are your very useful plugins for Cura, I especially find "Material Settings" useful when trying to set up profiles for different filaments.

     

    Thank you! 🙂

  • Link to post
    Share on other sites

    Posted · G-Code applied before custom startup

    The logic is here:

    https://github.com/Ultimaker/Cura/blob/4.4/plugins/CuraEngineBackend/StartSliceJob.py#L428


    Cura looks for the text "{material_print_temperature}", "{material_print_temperature_layer_0}", "{default_material_print_temperature}", "{material_initial_print_temperature}", "{material_final_print_temperature}" or "{material_standby_temperature}" in the start gcode to check if the start gcode contains extruder heating commands (so it does not actually care if you use M104 or M109 or not).

     

    Cura looks for the text "{material_bed_temperature}" or "{material_bed_temperature_layer_0}" in the start gcode to check if the start gcode contains bed heating command (so it does not actually care if you use M140 or M190 or not). I would argue that "{default_material_bed_temperature}" should be added to that list for consistency.

     

    Start gcode snippets often include priming commands. If Cura would insert its preheating before the start gcode snippet, that priming would not work.

     

    Unless it is overridden, the "material_print_temperature" setting is set to be equal to "default_material_print_temperature" here:

    https://github.com/Ultimaker/Cura/blob/4.4/resources/definitions/fdmprinter.def.json#L2141

    • Like 1
    Link to post
    Share on other sites

    Posted · G-Code applied before custom startup
    On 11/11/2019 at 1:39 PM, ahoeben said:

    The cause of this issue is that in your start gcode you use the {print_bed_temperature} replacement pattern. Try replacing that with {material_bed_temperature}.

     

    Yes, this appear to do it (see attached).

     

    There's still one line left (M82), but it's fine for my purpose, I guess.

    As Chjohans mentioned:

    On 11/11/2019 at 2:30 PM, chjohans said:

    IMHO it should not insert *anything* (except comments maybe) before my own "start G-code".

     

    I totally agree, though I think there might be reason to the madness. 

    Perhaps a small (i) could be added to the Start G-code box?

    newPng.PNG

  • Link to post
    Share on other sites

    Posted · G-Code applied before custom startup

    Thanks @ahoeben, the beauty of open source and you just reminded me that Cura is open source, so now I know where to look.

  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Our picks

      • UltiMaker Cura 5.7 stable released
        Cura 5.7 is here and it brings a handy new workflow improvement when using Thingiverse and Cura together, as well as additional capabilities for Method series printers, and a powerful way of sharing print settings using new printer-agnostic project files! Read on to find out about all of these improvements and more. 
         
          • Like
        • 18 replies
      • S-Line Firmware 8.3.0 was released Nov. 20th on the "Latest" firmware branch.
        (Sorry, was out of office when this released)

        This update is for...
        All UltiMaker S series  
        New features
         
        Temperature status. During print preparation, the temperatures of the print cores and build plate will be shown on the display. This gives a better indication of the progress and remaining wait time. Save log files in paused state. It is now possible to save the printer's log files to USB if the currently active print job is paused. Previously, the Dump logs to USB option was only enabled if the printer was in idle state. Confirm print removal via Digital Factory. If the printer is connected to the Digital Factory, it is now possible to confirm the removal of a previous print job via the Digital Factory interface. This is useful in situations where the build plate is clear, but the operator forgot to select Confirm removal on the printer’s display. Visit this page for more information about this feature.
          • Like
        • 0 replies
    ×
    ×
    • Create New...