StartSliceJob.py regex - tweak to extruder_nr_expr capture group #20203
Conversation
github-actions
bot
added
the
PR: Community Contribution 👑
Test Results23 881 tests ±0 23 877 ✅ ±0 47s ⏱️ ±0s For more details on these failures, see this check. Results for commit 2c36184. ± Comparison against base commit 5afb380. ♻️ This comment has been updated with latest results. |
|
OK, so turns out when I was developing the regex I didn't realise the |
Previously, any expression in a G-code block that was to be evaluated at slicing time could not contain a comma, as the regex would treat everything before the first comma found as the "expression", and anything after it as the "extruder_nr_expr". This causes a problem when trying to evaluate an expression that takes multiple values; for example, one such as `{min(machine_max_feedrate_x, machine_max_feedrate_y)*60, -1}`, which calculates a feedrate for moving the toolhead as part of the preparation steps.
This change alters the selection of the "extruder_nr_expr" value to only find a string composed of numbers and the minus sign, in order to ensure this field only contains the extruder number in use, and thus allows the capture of the "expression" value to extend past the first comma, to take in the entire expression.
Since my first idea failed to pass testing (I didn't consider that people may want to also calculate the extruder number), here's a different approach by recursively capturing the contents of brackets to ensure matched pairs (necessary for a valid expression to be evaluated).
This time, I'm not trying to correct the regex, as it seems impossible without using recursion to ensure that all brackets are closed. Instead, I manually iterate over the `expression` capture group, and if it is misaligned in regards to brackets, continue reading into the `extruder_nr_expr` group until I find a comma outside of any brackets, and then modify the two fields accordingly (moving the same amount of data out of one and into the other) before sending them on to the expression parser.
DragRedSim
force-pushed
the
gcode-expressions-allow-comma
branch
from
d319cb2 to
bfb596f
Compare
Description
Previously, any expression in a G-code block that was to be evaluated at slicing time could not contain a comma, as the regex would treat everything before the first comma found as the "expression", and anything after it as the "extruder_nr_expr". This causes a problem when trying to evaluate an expression that takes multiple values; for example, one such as
{min(machine_max_feedrate_x, machine_max_feedrate_y)*60, -1}, which calculates a feedrate for moving the toolhead as part of the preparation steps. This change alters the selection of the "extruder_nr_expr" value to only find a string composed of numbers and the minus sign, in order to ensure this field only contains the extruder number in use, and thus allows the capture of the "expression" value to extend past the first comma, to take in the entire expression.This fixes any expressions being interpreted by the parser which involve the use of a function that takes more than one argument.
Type of change
How Has This Been Tested?
Test A - attempted slicing using a stock install of Cura 5.9.0, with the following line in the machine start G-code:
G0 X-2.1 Y20 F{min(machine_max_feedrate_x, machine_max_feedrate_y)*60, -1} ;Move to start position. This line was output in the sliced gcode asG0 X-2.1 Y20 FNone ;Move to start positionTest B - made change in the installed file StartSliceJob.py as documented in this pull request and restarted Cura, re-sliced the same file and checked the line in the start G-code, which now outputs
G0 X-2.1 Y20 F12000 ;Move to start positionTest Configuration:
Checklist: