Limiting path on 3D operations

[graemef]

Hi,

Is it possible in to limit the extents of 3D operations. i.e. to prevent cuts in areas that I don't want them?

Example, if I perform a 3D surface operation (OCL Dropcutter), then the path on top of the object is ok, but the path also goes down the side of the object. Is there a way I can constrain the path to the top surface?

OS: Linux Mint 18.3 Sylvia
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.13721 (Git)
Build type: None
Branch: master
Hash: afdd30b137cdfd096c61c4aee270025115d0f8d6
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.2.0
Locale: English/SouthAfrica (en_ZA)

Thanks

Graeme

[herbk]

It's not possible atm, but it's something what i would like very much to...

[chrisb]

Example, if I perform a 3D surface operation (OCL Dropcutter), then the path on top of the object is ok, but the path also goes down the side of the object. Is there a way I can constrain the path to the top surface?

The only thing you can do is to move your object (or a clone) towards Z-. 3D surface goes only down to 0 . which in fact is a problem in some other situations.

[chrisb]

I had hoped to be able to fool 3DSurface with negative borders for the stock, however, stock cant be made smaller than the object - which is natural.

[roivai]

Reviving and old'ish thread.. Yesterday I tried using the 3D Surface OP for the first time. After reading quite a few forum threads highlighting the problems with it, I was actually surprised that it worked almost out of the box. But I ran into exactly the problem described in the start of this thread, the operation is always performed on the whole base object + tool diameter offset. I changed it so that you can choose either the stock object or the bounding box of the body as the bounds of the operation. Additionally, I added possibility to generate additional offset (can be + or -) to the bounds. Seemed to work well.

I made some other things configurable as well. Currently, the drop cutter algorithm makes the lines always at Y direction. I made that configurable to X or Y. Also, the step over was fixed to 100% of tool diameter, I made that configurable..

There are lot of things to be done of course. Something I have in mind after one night of tinkering:
-Make possible to choose the faces of which are operated just like in other OPs. Currently uses the whole base obj.
-Possibility for roughing. This could probably be done just so that some Z offset would be applied to the roughing path? As a first step, roughing and finishing could be two different operations, so basically just adding the possibility of Z offset would do.
-Possibility to have multiple Z steps on drop cutter. Actually, even Path.Area could be used to generate the zig-zag pattern or whatever desired and then this would be run on OCL to get the 3D surface.
-I did not even try waterline. Or actually I tried once, but at least on the model I had (screenshot) the waterline algo just filled up both RAM and swap and crashed.. So probably lots to improve there.

I'll clean things up, hopefully tonight or tomorrow and publish a PR of the things I already did.. Any other ideas to consider?

Pekka

[GeneFC]

This is GREAT!

I hacked up some of those ideas a while ago. Glad to see that the improvements are becoming formalized.

One remaining issue that would greatly benefit surface profiling would be the ability to used non-cylindrical cutters, specifically ball-end cutters. I suspect this adds quite a bit of complexity to the drop cut process, but I believe that the original Anders Wallin OpenCamLib supports some non-cylindrical cutters.

Gene

[roivai]

One remaining issue that would greatly benefit surface profiling would be the ability to used non-cylindrical cutters, specifically ball-end cutters. I suspect this adds quite a bit of complexity to the drop cut process, but I believe that the original Anders Wallin OpenCamLib supports some non-cylindrical cutters.

Gene

Actually I already tried that as well - ball end cutters are supported by OCL. I will write support for them so that if the tool type in ToolController is BallEndMill it will use the BallCutter in OCL and CylCutter otherwise.

[chrisb]

Thanks for working on this!

[herbk]

Hi Pekka,

Thanks for working on this!

+1

-I did not even try waterline. Or actually I tried once, but at least on the model I had (screenshot) the waterline algo

It looks like 3D Pocket works allmost like Waterline. If there (at 3D Pocket) would be the possibility to get it work without encircling bottom it would be a good stepp for more usability to.

[roivai]

The PR is submitted. https://github.com/FreeCAD/FreeCAD/pull/1542

Repeating myself from yesterday, but here are the changes:
-The drop cutter operation respects FinalDepth parameter, i.e. never cuts below that. When the operation is created, the OpFinalDepth is guessed and I find that the guess is wrong most often, so probably you have to set the FinalDepth manually. I did not try to find out how the final depth is guessed.. sliptonic or mlampert: do you have nice way to set the default finish depth to be the minimum Z value of the body?

-Possibility to choose the bounding box of the drop cutter operation. (is there a better name to call it?) It can be either the stock of the Job or the bounding box of the object. Additionally, offset in X and Y direction can be added to that by parameter DropCutterExtraOffset. If that is set to 0, the first cut is made so that the path is exactly at the bounding box. If you want to limit it so that the tool does not go outside of the bound, set the offset to be -(tool diameter)/2

- Possibility to add Z axis offset. Mainly to make roughing somewhat possible. So if you set DepthOffset to say 2mm, the shape will be cut 2mm above the actual surface. The thing to notice is that if the model has vertical walls, this does not add any finishing clearance on the wall.

-Support for ball end mills. Just set the tool type in the tool controller to be 'BallEndMill' to enable this.

-Configurable step over percentage (1-100%), I set the default to be 50%

-Configurable direction of drop cutter algorithm. The lines can be cut X or Y direction. Previously this was hard coded to Y.

As always, the testing has been very limited, just two models so bugs are expected to be found. I noticed that the speed of the OCL algorithm has strange variance. That 500mm long airfoil shape I showed previously gets calculated in a few seconds, but a simple 50mm diameter sphere takes minutes..