GregValiant 1,276
@MariMakes are there plans to include math functions and if statements in StartUp gcode?
@MariMakes are there plans to include math functions and if statements in StartUp gcode?
Oh! I wasn't aware that that wasn't the case yet. 😦
I'll have to ask the team! 💪
@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.
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.
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.
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
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.
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
Recommended Posts
MariMakes 199
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