Drill file with grbl postprocessor ignores rapid speed

[wolfgangr]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

drill code generated by the grbl postprocessor runs increadibly slow. Obviously, the G0 .. FXYZ rapid speed setting is overwritten by the postrpocessor after the first drill, leaving all subsequent G0 operations to run at (vertical) drill speed instead of rapid speed.

More details in this forum post:
https://forum.freecad.org/viewtopic.php?p=748812#p748812

Full version info

[code]
OS: Debian GNU/Linux 10 (buster) (LXDE/LXDE)
Word size of FreeCAD: 64-bit
Version: 0.21.2.33771 (Git) AppImage
Build type: Release
Branch: (HEAD detached at 0.21.2)
Hash: b9bfa5c5507506e4515816414cd27f4851d00489
Python 3.10.13, Qt 5.15.8, Coin 4.0.0, Vtk 9.2.6, OCC 7.6.3
Locale: German/Germany (de_DE)
Installed mods: 
  * fasteners 0.5.13
  * slic3r-tools
  * Pyramids-and-Polyhedrons
  * A2plus 0.4.64
  * Assembly3 0.12.2
  * Assembly4 0.50.9
  * FeedsAndSpeeds 0.5.0
  * dodo 1.0.1
  * frame 0.1.1
  * freecad.gears 1.2.0
  * Manipulator 1.5.7
  * MOOC 2022.4.21
  * Help 1.0.3
  * ose-piping
  * QuickMeasure 2022.10.28
  * sheetmetal 0.4.2
  * ThreadProfile 1.89.0
  * SteelColumn
  * Estimate 0.1.2
  * DynamicData 2.60.0
  * parts_library
  * btl 0.9.9
  * AnimationFreeCAD 1.0.0 (Disabled)
  * CurvedShapes 1.0.8
[/code]

Subproject(s) affected?

CAM/Path

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[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):

[wolfgangr]

said issue #13106 (comment) is a continuation of the work started here. I ended up in rewriting the whole section generation the canned drill cycles.

My test version is available here: https://forum.freecad.org/download/file.php?id=258735

Brave people may dare to throw that into their macro directory and look what happens. At their own risk, of course ;-)

---

"works for me"

The community may decide where to go from here