Cura 5.2.1 GCODE macro/function not post processing correctly

[itsMrJimbo 0]

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 January 8, 2023 by itsMrJimbo

[MariMakes 198]

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

[GregValiant 1,240]

@MariMakes are there plans to include math functions and if statements in StartUp gcode?

[MariMakes 198]

Oh! I wasn't aware that that wasn't the case yet. 😦
I'll have to ask the team! 💪

[GregValiant 1,240]

@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.

[itsMrJimbo 0]

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.

[GregValiant 1,240]

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.

[MariMakes 198]

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

[Slashee_the_Cow 261]

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.

[GregValiant 1,240]

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 November 20, 2023 by GregValiant