Jump to content

Cura 5.2.1 GCODE macro/function not post processing correctly


itsMrJimbo

Recommended Posts

Posted (edited) · Cura 5.2.1 GCODE macro/function not post processing correctly

Good evening all, I'm trying to implement the new Input Shaping calculation test print using Marlin 2.1.2 - Marlin Source here: https://marlinfw.org/docs/gcode/M593.html

 

My question is around how Cura functions when trying to use a "Insert at layer change" post processing script, specifically 'after' as advised in the above marlin link, the function is just inserted, rather than calculated. Is it possible for Cura to view the function and enact it accordingly? I've tried slicing in Prusa Slicer which generates this for example:

 

"G1 Z42.000 F720
;AFTER_LAYER_CHANGE
;42.2
M593 F46.5152 ; Hz Input Shaping Test"

 

which shows that the function was calculated properly (based on layer number) and the line edited accordingly to change the F value, however in Cura, the function isn't calculated, so you get this:

 

;TIME_ELAPSED:3459.382106
M593 F{(layer < 2 ? 0 : 15 + 45.0 * (layer - 2) / 297)} ; Hz Input Shaping Test

 

Unfortunately, Prusa slicer isn't currently playing nicely with my machine, and I'd rather use Cura as I do for all my printing.

 

So really what I'd like to know, is this just an issue that the format for the macro/function is not correct for Cura, or is it not possible for functions/macros to be calculated by Cura? I have tried both the function examples given by Marlin, but get the same issue as above, it's just the raw function inserted into the Gcode. I'm not at all familiar with coding and naming terminology so I'm not sure if this is something that is at all possible using Cura or a fairly simple macro change.

 

Thanks in advance for the help!

James

Edited by itsMrJimbo
  • Link to post
    Share on other sites

    • itsMrJimbo changed the title to Cura 5.2.1 GCODE macro/function not post processing correctly
    Posted · Cura 5.2.1 GCODE macro/function not post processing correctly

    Hey @itsMrJimbo,

     

    Welcome to the Ultimaker Community 🎉

     

    I recognize your issue. 

    It's also been reported on our Github

     

    It seems to be related to the {},  we've added a ticket to the backlog with the intent to improve this. 

    What version of Cura are you running? Because it has been reported as working as expected on Cura 5.2.1

  • Link to post
    Share on other sites

    Posted · Cura 5.2.1 GCODE macro/function not post processing correctly

    @itsMrJimbo at this time the "replacement patterns" in the StartUp and Ending gcodes are only replacements.  There is no math or logic performed by Cura.  In your case the sequence "(layer < 2 ? 0 : 15 + 45.0 * (layer - 2) / 297)" within the curly brackets isn't recognized as a valid Replacement Pattern and so it is passed on verbatim to the gcode.

    What you are trying to do I think can be done in PrusaSlicer.  Cura does not (yet) have this capability.

  • Link to post
    Share on other sites

    Posted · Cura 5.2.1 GCODE macro/function not post processing correctly
    5 hours ago, MariMakes said:

    Hey @itsMrJimbo,

     

    Welcome to the Ultimaker Community 🎉

     

    I recognize your issue. 

    It's also been reported on our Github

     

    It seems to be related to the {},  we've added a ticket to the backlog with the intent to improve this. 

    What version of Cura are you running? Because it has been reported as working as expected on Cura 5.2.1

    Thanks for the help Mari, confirm I'm on 5.2.1

     

    Oddly enough the { and } work within my start Gcode just fine (e.g.:

    M140 S{material_bed_temperature_layer_0}

    M104 S{material_print_temperature_layer_0}

    as this was one of the first things that PrusaSlicer complained about when I tried to configure it using my existing start code. 

     

    4 hours ago, GregValiant said:

    @itsMrJimbo at this time the "replacement patterns" in the StartUp and Ending gcodes are only replacements.  There is no math or logic performed by Cura.  In your case the sequence "(layer < 2 ? 0 : 15 + 45.0 * (layer - 2) / 297)" within the curly brackets isn't recognized as a valid Replacement Pattern and so it is passed on verbatim to the gcode.

    What you are trying to do I think can be done in PrusaSlicer.  Cura does not (yet) have this capability.

     

    I was wondering if this might be the case. I can confirm it works in PrusaSlicer as my example above, the function generates an F value based on the calculations and inserts at each layer.

     

    As a work around I may try to slice it like a temperature tower just with a range of M593 F values rather than temperature changes.

  • Link to post
    Share on other sites

    Posted · Cura 5.2.1 GCODE macro/function not post processing correctly

    I think PrusaSlicer uses square brackets and Cura uses Curly brackets.  The Prusa keywords are different as well so you can't just copy and paste back and forth from Prusa StartUp to Cura StartUp.

  • Link to post
    Share on other sites

    Posted · Cura 5.2.1 GCODE macro/function not post processing correctly

    Quick update on our side.

    We might have a fix for gcode variables and math. 🎉

     

    It's a bit hard for us to test, but it should be available in the 5.6 Beta. 

    Can you please try it out and let us know if it resolves your issue?

    You can download the build here: https://github.com/Ultimaker/Cura/releases

  • Link to post
    Share on other sites

    Posted · Cura 5.2.1 GCODE macro/function not post processing correctly
    On 1/9/2023 at 5:21 AM, itsMrJimbo said:

    M593 F{(layer < 2 ? 0 : 15 + 45.0 * (layer - 2) / 297)}

    Hold on - were you trying to write that gcode using an f-string? Because that's what it looks (exactly) like to me... except that you're using a C-style syntax for your ternary and not doing it Python style which is like this:

    0 if layer < 2 else 15 + 45.0 * (layer - 2) / 297

    (and please remember to double check to make sure your order of operations on that equation is correct)

     

    I'm not sure what @MariMakes has been up to f-strings won't work in older versions of Cura because they use an older Python interpreter (and f-strings were added in Python 3.6). They work in 5.5, I haven't bothered to test how far back it goes.

     

    Post-processing scripts have already had access to a fair amount of the Python standard library, including the math module.

     

    @MariMakes please tell me you've done something about rounding, I'm sick of half my scripts having to start with

    from math import ceil, floor

    because the values I get are floats that are a tiny fraction below an integer.

    • Thanks 1
    Link to post
    Share on other sites

    Posted (edited) · Cura 5.2.1 GCODE macro/function not post processing correctly

    I had always installed different printers so I could have different speeds in the StartUp Gcode (TPU in particular needs to be much slower and with no retracts).  I'm old and remembering to pick the correct printer didn't always happen.  Trying to print TPU at PLA speeds was a disaster.

     

    I want the purge lines to go down at 2/3 print speed and I noticed that {speed_print*60*.66} doesn't work.  If I change it to

    {speed_print*60*2/3} it does work.  So it would appear that floats are not allowed in the math.

    Another example:

    G1 F{retraction_retract_speed*60} E-{retraction_amount/3} works but

    G1 F{retraction_retract_speed*60} E-{retraction_amount*.33} does not.

     

    I can't get any logic to work.  It might be a personal problem.  "round" does work.

     

    Edited by GregValiant
  • 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.8 beta released
        Another Cura release has arrived and in this 5.8 beta release, the focus is on improving Z seams, as well as completing support for the full Method series of printers by introducing a profile for the UltiMaker Method.
          • Like
        • 1 reply
      • Introducing the UltiMaker Factor 4
        We are happy to announce the next evolution in the UltiMaker 3D printer lineup: the UltiMaker Factor 4 industrial-grade 3D printer, designed to take manufacturing to new levels of efficiency and reliability. Factor 4 is an end-to-end 3D printing solution for light industrial applications
          • Thanks
          • Like
        • 3 replies
    ×
    ×
    • Create New...