@CandL v1 of the rest machining feature is merged; check it out! This version is can only be applied on Pocket and Pocket3D operations and only considers paths from those types of operations. I haven’t found time to work on this lately, but the next iteration I have planned will consider paths from all types of operations. Stay tuned!
Ok maybe I am being stupid … or just can’t find the documentation on this.
I have:
OS: Windows 11 build 22631
Word size of FreeCAD: 64-bit
Version: 0.22.0dev.33909 (Git)
Build type: Release
Branch: master
Hash: afd06d09f796f0069971fb1d4a1bf60536595f2c
Python 3.10.12, Qt 5.15.8, Coin 4.0.0, Vtk 9.2.5, OCC 7.6.3
Locale: English/United States (en_US)
Installed mods:
* A2plus 0.4.60n
* A2plus.backup1667306205.6766858 0.4.54b (Disabled)
* better-tool-library 0.9.4
* BIM 2021.12.0
* Curves 0.6.13
* dodo 1.0.0
* ExplodedAssembly
* FeedsAndSpeeds 0.4.0
* Help 1.0.3
* lattice2 1.0.0
* Raytracing
* Woodworking 0.21.30486
I have a test model of a GottshallBlock, I have included the model. It has 2 tools load 1/4, and 1/8.
I did a pocket shape (1/4 tool), and looked for a “rest” option … could not find one, so I just made the tool path.
Then I looked for a way to use the previous tool path as a donor to make one for the 1/8 bit, … could not find it either.
I then looked for an addon with the word “rest” in it … nothing.
Can you point me in the right direction?.
The commit that added this function was 33934.
Your version does not include that addition.
Gene
Ok so that should be the weekly build from github. Where should I get it, or do I need to build it?
The latest weekly appears to be 33909 at this moment.
If you are really desperate you will need to build. 
Gene
I certainly have built it before, but for four days I think I am gonna wait. Thanks.
Still looking for doc though.
Being patient paid off … now onto build 33981. (Ok I am a lazy engineer, Could I have built FreeCad sure, but longer time between builds.. well for me stuff seems to get out of whack and you spend a while resyncing the build process)
Yes I now see rest machining! I will start kicking the tires.
Quick question, does the pocket “pattern” need to match the previously used pattern? When I switch patterns it does not give what I expected.
Is there a limit on how deep you can nest these operations? i.e. 3/4" to 1/2 to 1/4 to 1/8 … you get the picture?
Is it possible to display the toolpath name that you are using as your donor?
Is this the correct forum for this discussion or is it better on github? What do you prefer?
Lest I forget… nicely done. I will use this.
For those who might not know this link:
https://github.com/FreeCAD/FreeCAD-Bundle/releases/tag/weekly-builds
Warning this is a BETA build is not earlier than that, which means crashes maybe in your future.
question from translator who is not from the CNC field at all, why is it call ‘rest machining’? ‘rest’ make me think about to be on pause and my understanding with this thread, we are more talking about finishing. Am I wrong?
It simply is established terminology in the world of CAM. It machines away the rest material (which is the remnant from previous operations).
Rest comes from Latin restō (maybe there’a an even older origin) and means „to remain“ or „to stay back, to stay behind“ (according to wiktionary).
As a native german speaker „rest machining“ makes a lot of sense to me, though I can understand why it sounds confusing to english speakers as the term changed its main meaning.
thank you for these explanations. In French, we say ‘I will die less stupid tonight’.
it gives me ideas how to translate.
edit: i’ve put on Crowdin your explanation, they can be helpful for other translators. https://crowdin.com/translate/freecad/32154/en-fr#6625355
But there would be some work for Adaptive operations as well, yep? 
Yes! Unfortunately I am way behind on implementing my personal wishlist for freecad cam features, but I do still have plans for that. I’ll post when I have a PR ready!
Here’s hoping you’ll have time to continue your much appreciated contributions to FreeCAD CAM.
I have reimplemented rest machining to take input from the gcode of earlier operations (instead of using internals of Area operations). This enables support for rest machining in Area operations (Pocket, Pocket3D, Profile) after non-Area operations, most notably Adaptive operations. Adaptive operations still cannot benefit from rest machining yet – that will be phase 3 of my project .
I have opened a PR on github; see the description for more details: https://github.com/FreeCAD/FreeCAD/pull/11939
sliptonic, could you review it for me?
Demo image:
20240108_20h56m51s_grim.png
Wow, sounds pretty nice!! 
hope it gets merged soon, cant wait to test this feature! 
Great job.
But please pay attention to the rules for comparing floating point numbers:
and, i.e.,
ccw = vstep.x * vdirect.y - vstep.y * vdirect.x > 0;
will not become cw suddenly.
(you will be a pioneer, but what if this leads to the start of refactoring existing code?)
Since double appears to be the only used FP type, it is sufficient to overload the comparison operators only for this type.
I’m not a pythonyst and don’t know what to do with python code.
@xemul thanks for the code review. I’m going to reply here, but afterwards could we move the discussion to my github PR?
ccw = vstep.x * vdirect.y - vstep.y * vdirect.x > 0;
For this particular example, vdirect represents the segment of an arc and vstep is a (non-zero, non-one) interpolation of that arc, so I am guaranteed that the perfect-precision result of this computation is not zero. I’d feel weird offsetting in either direction by opencascade’s Precision because I really am looking for the sign on a non-zero number here to back recompute the orientation of the arc. (Ideally I’d rather skip this computation entirely and use the cw/ccw information from where it is already known upstream, but I didn’t think it was worth changing the interface of the gcode walker to support this since recomputing is straight forward.)
I’ve updated one hard-coded precision check that I forgot about in my cleanup pass https://github.com/FreeCAD/FreeCAD/pull/11939/commits/dd5bb66cb96a044015a98b2d34e81e2a1650d841. Did you see any other precision issues?
I’m sorry to be late with the reply. Since English is not my native language it take a time.
My bad, I have no github account.
Did you see any other precision issues?
ClearedAreaSegmentVisitor::point()
{
Base::BoundBox3d bbox;
void point(const Base::Vector3d &p)
{
if (p.z <= maxZ) {
if (bbox.MinX <= p.x && p.x <= bbox.MaxX && bbox.MinY <= p.y && p.y <= bbox.MaxY) {
As existing solution you could use BoundBox::SetGap(precision) before. It eliminates marginal effects with FP computations and translates all precision matters to OCC side.
Another approach is to create some classes for 1D, 2D, 3D, angular … objects with overloaded comparison operators. It will give a possibility to dynamically adjust precision regarding to object’s dimensions. (may be in next FC incarnation)
As you already in a battle with Area.cpp you could
1543 bounds.SetGap(myParams.SectionTolerance);
...
1550 double tolerance = myParams.SectionTolerance;
to avoid “hit bottom” messages. It also almost enough to exclude dancing with “bool retried, can_retry;”, but I can not remember what else required and need to recover data from home NAS first.
I’m sorry to be late with the reply. Since English is not my native language it take a time.
No problem; I appreciate your attention.
ClearedAreaSegmentVisitor::point()
{
Base::BoundBox3d bbox;
void point(const Base::Vector3d &p)
{
if (p.z <= maxZ) {
if (bbox.MinX <= p.x && p.x <= bbox.MaxX && bbox.MinY <= p.y && p.y <= bbox.MaxY) {
I don’t think this should be changed either. maxZ comes from Area.py’s invocation of getClearedArea and already incorporates an extra buffer of job.GeometryTolerance. The bounding box has been Enlarge()d by toolRadius + a carefully computed buffer representing the maximum tolerance stackup of the prior geometry operations (notably larger than Precision::Confusion(), for what it’s worth). I don’t think either of these requires further modification to handle floating point precision issues.
After several forward/backward translations I missed a gist.
I used this piece of your code not as issue, but as sample of use OCC’s built-ins to avoid FP uncertainties.
Use of SetGap() is conditional and relies on developer’s view (if he awared about subject), and it implies explicit and tedious calls of SetGap() for most BoundBox objects. As workaround with near zero refactoring (need check for all cases of explicit SetGap(0.0)) is overload of default Bnd_Box::Bnd_Box() : Gap(0.0) to Bnd_Box::Bnd_Box() : Gap(precision). But it includes only 1D properties.
An unconditional way is implementation of classes with overloaded comparision operators and built-in precision property.