Drill file with grbl postprocessor ignores rapid speed about freecad

[wolfgangr]

just found that the correct speed info is present in every line of internal FreeCAD gcode format

G0 F33.333333 X24.000000 Y10.000000
G81 F1.666667 R4.000000 X24.000000 Y10.000000 Z-1.000000

where the speed is given in mm/s;
33.33 *60 = 2000 mm/min
1.66 * 60 = 100 mm/min
which both values match my settings in the Path Plan.
So it's the postprocessors culprit to loose this information somewhere on the way.
Will try to figure this out...

[wolfgangr]

https://github.com/FreeCAD/FreeCAD/blob/2ebbd83268ffabf41ceaad802714a4ffd9214437/src/Mod/CAM/Path/Post/scripts/grbl_post.py#L499C1-L511C34

                    if param == "F":
                        if command not in RAPID_MOVES:
                            speed = Units.Quantity(
                                c.Parameters["F"], FreeCAD.Units.Velocity
                            )
                            if speed.getValueAs(UNIT_SPEED_FORMAT) > 0.0:
                                outstring.append(
                                    param
                                    + format(
                                        float(speed.getValueAs(UNIT_SPEED_FORMAT)),
                                        precision_string,
                                    )
                                )

PAPID_MOVES are G0 an G00 - so why is the F-clause omitted there?
If we simply keep it, have we done it?
may be, we make it dependent on a cmd line option and keep it of as default, not to break backwards compatibility?

[wolfgangr]

just hacked a simple skip of this condition

500c501
<                         if command not in RAPID_MOVES:
---
>                         if True:   #command not in RAPID_MOVES:

... and - tatarataaa - this is my output:

G0 X10.000 Y-1.000 F2000.000
(G81 X10.000 Y-1.000 Z-1.000 F100.000 R4.000)
G0 X10.000 Y-1.000
G0 Z4.000 F100.00
G1 Z-1.000 F100.00
G0 Z4.000
G0 X24.000 Y10.000 F2000.000
(G81 X24.000 Y10.000 Z-1.000 F100.000 R4.000)

The moves from the expansion of the G81 are correctly translated to slow F100.
The reposition of the drill - the line before the G81 dummy in parantheses - is done with F2000 - bingo.
Simulation speed of my test file in OpenBuildsControl is down from 11 min to 4m.

[wolfgangr]

may be, we make it dependent on a cmd line option and keep it of as default, not to break backwards compatibility?

propose a pair of arguments:

--rapidspeed
--no-rapidspeed

with the last one as default
hope I can figure it out... python is not really my favourite...

[wolfgangr]

ok - done - and tested - leave it to your discretion:

.../FreeCAD/gcode$ diff grbl_post_pristine.py grbl_post.py
56a57,58
> # wolfgangr 
> OUTPUT_RAPIDSPEED = False # default is the old behaviour - don't forward Fxxx speed to G0 and G00 commands
159a162,172
> # wolfgangr arguments for forwarding rapid speed in G0 operations
> parser.add_argument(
>     "--rapidspeed",
>     action="store_true",  # TBD: set default sw around ln 59, process sw around 266, and use it sw around ln 500
>     help="forward the settings of 'Rapid Speeds' in the Job tools default to G0 and G00 commands",
> )
> parser.add_argument(
>     "--no-rapidspeed", 
>     action="store_true", 
>     help="render G0 / G00 commands without any Fxxx speed (default, backwards compatibility)"
> )
207a221
>     global OUTPUT_RAPIDSPEED
253a268,272
>         # wolfgangr
>         if args.rapidspeed:
>             OUTPUT_RAPIDSPEED = True
>         if args.no_rapidspeed:
>             OUTPUT_RAPIDSPEED = False
283a303
>         gcode += linenumber() + "(wolfgangr test version 2 - 2024-03-23)\n"
441a462
>     global OUTPUT_RAPIDSPEED
500c521,522
<                         if command not in RAPID_MOVES:
---
>                         # if True:   #command not in RAPID_MOVES:
>                         if  OUTPUT_RAPIDSPEED  or (command not in RAPID_MOVES):